Hello i catch warning on php 5.4

Warning: Illegal string offset 'data' in template_preprocess_calendar_month() (line 44 of /var/www/***/htdocs/sites/***/modules/contrib/calendar/theme/theme.inc).
Members fund testing for the Drupal project. Drupal Association Learn more


KarenS’s picture

Status: Active » Closed (cannot reproduce)

Can't reproduce this. Make sure you are testing the latest dev versions of both Date and Calendar and clear the caches.

dizarter’s picture

Version: 7.x-3.0 » 6.x-2.x-dev
Status: Closed (cannot reproduce) » Active

Same thing here, only in calendar Multiday. Latest versions of date and calendar modules.
On one test machine it doesn't show this error, while on the other (exact same drupal instance on both) it throws this

Illegal string offset 'data' in /web/com/drupal/htdocs/sites/all/modules/calendar/calendar_multiday/theme/theme.inc on line 199.

Seems to have something to do with PHP 5.4, since that is the version of PHP installed on the second machine (other then that, environment is the same)

dizarter’s picture

There are occasions when key index "data" doesn't exist for some rows in $vars['rows'].

This simple check fixed the things for now until I find more time to backtrace what's causing the key to sometimes not be set in the first place.

File "calendar/theme/theme.inc", "function template_preprocess_calendar_month", line 197 reads

$cell = $data['data'];

change to

      if (!isset($data['data'])) {
      $cell = $data['data'];  
dcoulombe’s picture

@dizarter, I think it would be better this:

benhelps’s picture

Yep #4 worked for me.

johnweston’s picture

I found this issue in php 5.4.4 MAMP latest date module, 7.x-2.6 latest calendar module, 7.x-3.4 but the error message was line 37 - used #3 -works ok now. Fantastic modules btw.

ksignorini’s picture

Me too. But I found it at line 38 I believe.


Sdhooge’s picture

I also have the issue with 7.3.4.

The template_preprocess_calendar_month function is called twice. The first time $rows contains an array of "cached values" of what will be created by the second call (I guess) -- this is at this time that the warnings are printed. The second call is provided with the expected structure of values.

First call:

array(5) {
  array(1) {
    string(3269) "<tr class="date-box">
  <td id="calendrier-2012-08-27-date-box" class="date-box past empty" colspan="1" rowspan="1" data-date="2012-08-27"  headers="Lundi"  data-day-of-month="27" >
  <div class="inner">
    <div class="month day"> 27 </div>  </div>

Second call:

array(5) {
  array(7) {
    array(3) {
      array(6) {
        string(0) ""
        string(0) ""
        string(41) "<div class="calendar-empty">&nbsp;</div>

My workaround is to put the following test before using the 'data' key.

    foreach ($row as $day => $data) {
      if( is_string($data) )
      $cell = $data['data'];

I can provide you with additional var_dumps if you want.

njogz’s picture

#3 worked like a charm. Thanks. Loving the drupal community!

ParisLiakos’s picture

Issue tags: +PHP 5.4

adding tag

zeineddin’s picture

#3 or #4 worked fine for me... thanks...

rickmanelius’s picture

Version: 6.x-2.x-dev » 7.x-3.4
Status: Active » Needs review
455 bytes

#3 and #4 in patch form... I just got snagged with this on D7 as well.

Setting to needs review...

clearviz’s picture

#3 worked for me as well!!!




IreneKraus’s picture

I was pointed over to this thread from: http://drupal.org/node/1591388#comment-6660914

So I see there is a patch up now, as I still can't see where to put these patches into the current release version. Now I have to remember how to install a patch.

fourhexagons’s picture

Status: Needs review » Reviewed & tested by the community

The patch worked for me. Thanks, rickmanelius.

Irene Kraus, here is some info on applying patches:


The video is nice to hear someone talk you through it. It helped to clarify for me to save the patch in the module dir. Basically, you need to use the command line and if you're:

  • on local
  • you've saved the patch in the module's dir
  • and you're in the module dir (cd module)

then just use patch -p1 < file.patch

IreneKraus’s picture

Patch in #12 worked perfectly! Thanks for pointing out how to install patch info too. Got Netbeans IDE re-installed here for that purpose and (I think) setup as outline here for use with Drupal:

That page probably needs an update as the template they mention for use inside Netbeans never made it out of development. In any case, once I did have Netbeans up and running, following the directions here did the job:

Thanks everyone! One more issue resolved and a few more to work out, like why Subscriptions suddenly stopped sending out notices like it should when it went from my test server over to the actual one... Never ends!

insignis’s picture

Got this on calendar month view only, lines 38 and 43, upgrading Drupal from 7.11 to 7.17 and the latest ubuntu-bitnami platform. #4 fixed me right up.

insignis’s picture

PhilY’s picture

#4 works for me with MAMP and PHP 5.4
Thank you

mindfullsilence’s picture

#4 worked for me. MAMP - PHP 5.4.4

phoohtoo’s picture

yes.. thanks.


is worked for me.

davidneedham’s picture

Patch in #12 works for me as well.

Zyfraglover’s picture

#12 worked like a charm, thx :-)

erifneerg’s picture

patch removed the error for me too. thanks alot!

rickmanelius’s picture

Hey KarenS! Any chance we can get this committed? It looks like we've had several successful reviews!

marcvangend’s picture

Version: 7.x-3.4 » 7.x-3.x-dev

I'm seeing the same error.

I haven't looked into the technical side of this problem, but I can understand that Karen did not commit this patch yet. A patch that gets rid of a warning does not necessarily fix the problem. If template_preprocess_calendar_month() is called twice (as said in #8), we need to know why. Maybe that function should not be called twice in the first place - I don't know.

Patched should always be rolled against the development branch, so I'm setting the version to 3.x-dev. The patch from #12 should still apply to that branch.

IreneKraus’s picture

Pardon my confusion as I ask for a bit of clarification! Although I've been using Drupal to run sites for more than 5 years, I'm still VERY new to the testing and committing of patches process. From what I gather, once the patch has been tested favorably by the community, then a change need to be made to suggest integration into the latest development version?
This does make sense as (I'm assuming) it means the patch is ready for review by the maintainer(s) to ensure it integrates smoothly into the next release. Assuming that aspect of things goes well, then the doubled errors should finally be resolved in the next release. Please forgive my belaboring what may seem an obvious point, but understanding how to organize contributions from so many great 'cooks' coordinating their additions to the 'stew (code)' in our pots that is a typical Drupal site is pretty amazing!

marcvangend’s picture

Irene, your understanding of the development process is mostly correct. Every project (like in this case "calendar") has one or more maintainers. The community can test and review patches, but the maintainer acts as gatekeeper, deciding if a patch proposed by the community is good enough to become a part of the code. There are several criteria to judge a patch. Of course it needs to solve the problem, but there's more. It needs to do so correctly, in readable code, without introducing new problems, respecting the coding standards, etc etc.

That's why I wrote my comment in #26: I can see that the patch removes the warning, but I cannot judge if it's good enough to be committed.

If you want to know more about this topic, let's not derail this issue but find me (or someone else) in the #drupal channel on IRC.

pingers’s picture

The issue seems to be that E.g. calendar_build_month() goes through and renders rows of the calendar, then at the end adds the headers.

// <snip>
    $rows = array_merge(array(calendar_week_header($this->view)), $rows);
    return $rows;

The headers are not rendered, so they're still a renderable array when template_preprocess_calendar_month() is called.

I agree with isset() solution in #4 - just skip already rendered items, which code just after attempts to do as well...

      // If this cell is already rendered, like the weekno column,
      // move to the next item.
      if (!is_array($cell)) {
        $month_rows[$weekno][$day]['data'] = $cell;

I don't know of the case when this logic would actually apply though - didn't get that far.

(closed a bunch of duplicate issues too)

fredfab’s picture

Patch #12 works like a charm!

jbrown’s picture

#12 works! please commit

mcnicholl’s picture

patch #12 worked for me too :-D

savithac’s picture

#4 worked for me. thank you so much.

fcedillo’s picture

#4 works for me
that is the solution in code

thanks dcoulombe

A-snowboard’s picture

#12 perfect.

Tank you.

thekevinday’s picture

Status: Reviewed & tested by the community » Needs work
1.67 KB

The above patch only hides the actual problem.

Here is part of what is happening:
- (somehow) the $rows data is being rendered/preprocessed before the template_preprocess_calendar_month() function is executed.
- during the template_preprocess_calendar_month(), the unprocessed and the processed versions of the same data get merged together.
- The foreach loop ends up trying to render the already rendered content, thus producing the described error message.

This can be easily be observed by simply deleting the entire foreach loop inside of the template_preprocess_calendar_month() function. You will notice that the month calendar still gets rendered despite the code removal!

After deleting the foreach array, I noticed that the "year" calendar view stopped functioning properly. The year view calls the month preprocess view, but for some reason, does not have the already processed rows.

As a workaround and a proof of problem, I created a patch that does the mentioned code removal from the month preprocess function and also adds the removed code to the year preprocess function.

This patch does not address the problem with the rows in the month view being pre-pre-processed. I am not sure what is going on there but it looks like it might be happening somewhere in the render() function of includes/calendar_plugin_style.inc

RoySegall’s picture

#12 didn't fix all of the problem - i had the same problem that @pingers(#29) complained about.

We can just use is array or something like this to solve this but i must say that @thekevinday also fix the errors problem. but it seem to be a big patch with to much logic (why use sizeof($rows)? you can use count($rows))

thekevinday’s picture

The nice thing about diff is that it uses the most efficient way to show the changes.
The bad thing about diff is that it uses the most efficient way to show the changes.

In this case, that patch in #36 does not show what is actually being done.
I did not add any new code, but instead used existing code and moved (or copied) it around between two distinct functions.
The chunk that has the sizeof() call is from the top of the function: template_preprocess_calendar_month().

Compare the functions template_preprocess_calendar_month() and template_preprocess_calendar_mini() both before and after my patch (from the file: theme/theme.inc).

I think that to properly solve this issue someone needs to figure out why template_preprocess_calendar_month() already has the calendar month data built before that function is even called to build the calendar month data.

fquran’s picture

Version: 7.x-3.x-dev » 7.x-3.4
Category: bug » support
Status: Needs work » Active

I added this instruction in function template_preprocess_calendar_month in theme.inc and fix all of the problem.

$month_rows = $rows;
foreach ($rows as $weekno => $row) {
foreach ($row as $day => $data) {
+ if (!is_array($data)) {
+ continue;
+ }

RoySegall’s picture

@fquran - Any patch?

ToRum’s picture

@RoySegall: look at #12 for an ignoring but working workaround.

Patch #36 works fine for me.

I think that to properly solve this issue someone needs to figure out why template_preprocess_calendar_month() already has the calendar month data built before that function is even called to build the calendar month data.

Think you're right but I'm not able to find the core reason.

RoySegall’s picture

@ToRum - #36 works for me, that's why i'm using him and #12.

Any way, i'll try to hit the debugger and see what's wrong.

bblancha’s picture

I don't know if this helps but maybe we are missing something else here. I have PHP 5.2 using calendar (latest versions of everything) on an active site and do not get the error on the Month page.

Changing to PHP 5.4 causes this problem to appear. I know there is a change in behavior between the two versions especially w.r.t. string array indexes. Is there something about the change in PHP that affects the intended logic?

csmcreative’s picture

Issue tags: -PHP 5.4

I apologize for posting too fast. I guess everything has been fixed because now there are no issues. I didn't have to do any fixes or edits to the code. I created a new view from the calendar template and it seems I am good to go. Thanks.

hmartens@gmail.com’s picture

Thank you, #12 worked for me...I wish this important module could be more actively maintained?

hmartens@gmail.com’s picture

BUT, kudos to the maintainers for building and maintaining this amazing powerful module!!!

bblancha’s picture

I have resorted to #4 with success. I still think it masks a couple of problems. First PHP 5.4 does not support the same behavior as PHP 5.2 when using object indexes [see PHP 5-4 release notes] so it I possible that PHP 5.2 behavior masked the second issue of rendering an already rendered object.

In anycase, I tried the latest Dev code without luck. Edited and checked all views date field settings etc.

No luck. So I reverted to released code 7.x-3.4 and edited the theme.inc file as in #4. OK for now.
I only wish I could help but it is daunting to try to figure out what is going on. Thanks to all for putting eyes on this.

yann64’s picture

Maybe some more information that could help trace pack the problem:
The same problem happened to me after upgrading the date_ical module to the7.x-2.8 version, not after upgrading the calendar module. Requirement for the date_ical module have PHP 5.3.16 so I upgraded my website to that version, and did the date_ical module upgrade at the same time, so I don't know what the source of the problem is (PHP version? date_ical 'interference'?).

sonicthoughts’s picture

Same issue on PHP 5.4 upgrade. Can't determine best course from this thread - will try several approaches.
--- Update. Applied seems to work!

ParisLiakos’s picture

Version: 7.x-3.4 » 7.x-3.x-dev
Category: support » bug
Status: Active » Needs work
ParisLiakos’s picture

Issue tags: +PHP 5.4

and the tag again

gaofeng’s picture

Using the latest version of Drupal, latest version of the Calendar module and using PHP 5.4.16.
Same problem here. Added the lines mentioned in #4, works like a charm now. Thanks dcoulombe.

sonicthoughts’s picture

Status: Needs work » Needs review

Hope @KarenS or another maintainer is looking at this thread. Seems like many of the patches will address the problem but hope it makes it into dev/release.

webengr’s picture

well, this problem is still around.. a year and half later ?

In the past I have manually created views and did the 'calendar' without "Add View from Template"
But I tried the template and got this error 8/27/2013 with stable, updated with the 2012 dev... still an issue.

SO like is this really not a problem so no need to fix or update the devel with #4 or #12 ?

Did this on the dev-

  foreach ($rows as $weekno => $row) {
    foreach ($row as $day => $data) {
      /* $cell = $data['data']; */
thekevinday’s picture

So far all we have are workarounds.

#12 is supposed to be #4.
#12 is considered to not work according to: #37
(and didn't work for me as well).

Don't forget #36.
All the patch does is relocate code.
There is actually no new code added, just existing code is relocated or removed.

madbull’s picture

Comment #4 worked for me in the month tab of the calendar.
However in the year tab I have the same error now. Any updates on this issue?

thekevinday’s picture

madbull, thats the issue mentioned and workaround in #36.

RoSk0’s picture

I think there is nothing wrong with logic of this file, at least there is nothing we can do right now, but there is what to do for major version change.
As for now to fix PHP 5.4 issue we just simply move data check just couple lines above and that's all.
Patch attached.

edvanleeuwen’s picture

Succesfully tested the patch with PHP 5.5.

RoySegall’s picture

@edvanleeuwen Did you apply any patch? If so, which one?

edvanleeuwen’s picture

Yes, I applied the patch of #58.

colan’s picture

Status: Needs review » Reviewed & tested by the community

The code looks good, and it works for me.

jlea9378’s picture

Worked for me also on PHP 5.4

idflood’s picture

Had the same issue and after applying the patch in #58 the problem was solved.

k.skarlatos’s picture

works for me as well, thanks!

gbirch’s picture

I can confirm this is a PHP 5.4 problem. I have the exact same site running on 2 boxes, one with 5.3, the other with 5.4. Errors appear only on the 5.4 box.
Patch from #58 works for me too. Thanks!

pingers’s picture

Please stop posting. The 40th confirmation was enough. Thanks.

mattsmith3’s picture

@pingers- can we get a commit?

rick3455’s picture

Thanks a lot guys...dcoulombe & dizarter

MXT’s picture

Patch in #58 works for me also.

Can this be committed please?

Thank you very much

fenstrat’s picture

Also confirming that #58 is RTBC.

ExTexan’s picture

Contrary to what @gbirch stated in #66, I got this error running PHP 5.3.27. Applying the patch in #58 fixed it.

Just in case someone else finds this thread who is *not* on 5.4.

steinmb’s picture

PHP 5.5.6
Drupal 7.24
Calendar 7.x-3.4

Confirm this patch remove the warnings and does not seems to break anything. RTBC from me though I did not try applying this on top on HEAD.

stephenebersole’s picture

Avoid "Notice: Array to String Conversion in calendar-mini.tpl.php

I am no PHP expert, but if it helps anybody else, I found that by applying patch #58 to calendar/theme/theme.inc I then got "Notice: Array to string conversion... in calendar-mini.tpl.php" on the page I had installed the calendar mini display in a block.

The code in #3 which was posted by @dizarter was the code that worked without any errors.

I tried #4 where @dcoulombe suggested the use of:


but I found that it still gave me the Notice.

it seems that if you are using the calendar-mini display you need to replace
$cell = $data['data'];


      if (!isset($data['data'])) {
      $cell = $data['data'];

as posted in #3.

kingfisher64’s picture

#3 worked. It's line 37 in the latest dev version dated 2013-Sep-30.

@KarenS - can the fix in #3 be committed to a new stable release please :). It was suggested almost 2 years ago in April 2012 (feels odd saying that).

crutch’s picture

A stable release would be great. I'm still on 7.x-3.4 for multiple sites with this error on month view. Calendar still works but just repeating errors.

edvanleeuwen’s picture

I second that. As @pingers already said, the 40th confirmation was enough, but we would really want this to be committed.

Garrett Albright’s picture

Priority: Normal » Major
Issue summary: View changes
1.96 KB

#58 doesn't work for me, but this does. PHP 5.4. plz 2 commit.

Garrett Albright’s picture

Priority: Major » Normal
Status: Reviewed & tested by the community » Needs review
SyneX’s picture

Patch in #78 works for me.

fenstrat’s picture

Status: Needs review » Reviewed & tested by the community

Confirming that #78 works. Marking as RTBC.

highfellow’s picture

Patch #78 works for me. Tested week, day, and year tabs as well as month.

Christopher Riley’s picture

Patch 78 worked like a champ for me thanks.

deggertsen’s picture

Confirmed. #78 works.

JollyDonky’s picture

Apology in advance for "newbie" rant:
I'm a new user, but have enjoyed learning Drupal to maintain a website for my town's "Prairie Arts Center",
doing everything successfully (so far) through Windows FTP,
and everything else through the website's admin menu.
It has been a lot to learn for someone with no previous experience, but so far everything has worked GREAT!
The little town of Princeton, Illinois is happy.
Now my host service (Bluehost) has upgraded PHP to 5.4 and the Calendar is messed up.
The main purpose of this website is to show the Calendar!,
but it seems like the only solution is that I have is to learn UNIX and figure out how to get to a shell command prompt on Bluehost to manually fix our site?
Every single Calendar user has to individually fix their version of Calendar as soon as they are forced into PHP 5.4 by their host system?
It seems insane to me, knowing how many people are using this module.
Forgive my naivete', but can't someone just patch Calendar? At least in the dev version?
Is this module still being maintained?
Is there a good alternative to Calendar?
Should I switch host service?

sorry for publicizing my frustration,
Jack (aka "the new guy)

ExTexan’s picture

[Edit: mis-read the previous comment - so I removed my follow-up question. Apologies.]

Garrett Albright’s picture

You could patch the necessary file on your local system and then just upload the patched file over the original on the server - no need for a shell account on the server if it would be bothersome for you.

gapa’s picture

#78 works for me to.

JollyDonky’s picture

oh, is that all it is?
THANK YOU #87 Garrett!
The Princeton Arts Center website is fixed!
sorry for the panic,
60% of newbie rant rescinded... (smile)

Jack (aka "the new guy")

bohemier’s picture

#78 works for me as well. Thanks. Commit?

nmc’s picture

#78 has also worked for me so far.

stevenx’s picture

#78 works. Thanks!

yce’s picture

#78 works for me too. Thank you!

colan’s picture

Folks: We don't need any more works-for-me type comments. All they're doing at this point is spamming everyone that's subscribed to the issue. If you'd like the patch committed, please either contact one of the maintainers directly, or become one yourself.

deryck.henson’s picture

Status: Reviewed & tested by the community » Patch (to be ported)

Two top maintainers have both been notified. Now we play the waiting game.

colan’s picture

Status: Patch (to be ported) » Reviewed & tested by the community

Thanks. Actually though, this should stay at RTBC. "Patch (to be ported)" would be useful after the patch goes into the D7 branch, and we then want to port it to D6. As this hasn't been committed yet, we can't use that state.

deryck.henson’s picture

@colan thanks didn't know that. I really should take a minute to read the docs...

Hopefully the two I e-mailed don't ignore messages on a daily basis.

cmwelding’s picture

#78 worked for me. Thanks.

flyingchris’s picture

# 3 worked for me.
Calendar 7.x-3.4+1-dev
Date: 7.x-2.7+6-dev
PHP 5.5.6

drlakshan’s picture

Hi Everyone, I had the same problem and patch 12 worked completely.
Thanks a lot!

fenstrat’s picture

@drlakshan Can you test the patch in #78? Because that's the one that is RTBC, thanks.

Johann Wagner’s picture

Patch #12 works, thanks.

fenstrat’s picture

@Johann Wagner Please test the patch in #78 as it (not #12) is Reviewed & tested by the community (RTBC), thanks.

Hooligan’s picture

#78 worked for me. Thanks.

kyuubi’s picture

#78 worked for me.

rosborn’s picture

#78 worked for me. Thanks for the work. I would argue that this deserves a full release as soon as possible. This bug destroyed the functionality of our calendar.

steinmb’s picture

This have been ready for a while though this module needs help - https://drupal.org/node/92594/commits as you can see, no commits lately. So someone needs to step up else patches like this will "never" make it in.

cmedina’s picture

#78 worked for me, too.


fizk’s picture

Status: Reviewed & tested by the community » Fixed

Committed #78. Thanks everyone!

  • Commit 82fd845 on 7.x-3.x authored by Garrett Albright, committed by fizk:
    #1471400: Fix illegal offset in template_preprocess_calendar_month().
fenstrat’s picture

Thanks @fizk, great to see this finally committed.

IreneKraus’s picture

Yes! Great work everyone and so glad to see this fix committed.
? - Assuming we want the 'fixed' version then, we should install the .dev one for now? Before I do that on my actual sites, I think I'll still do a test for each of those using this module on my test server using a backup database, etc. If anything should go wrong then I haven't screwed up an actual working site!

Garrett Albright’s picture

Irene: If what you have now with just a patch is working and you don't need any other features or bug fixes introduced since the last "normal" release, I'd just stick with what works for now - you may encounter bugs or unexpected behavior with the dev release. You can then upgrade when the next full release comes out.

fizk, thanks for finally getting this committed!

lnh92’s picture

I'm having the issue as well. I'm new to using Drupal. I installed git, downloaded the patch, and followed the directions on the version control tab of the Event Calendar page. When I try to apply the patch, I get "error: theme/theme.inc: No such file or directory". I was wondering if anyone could help me out. Thanks!

fizk’s picture

lnh92, the patch has been committed, you can try testing the latest dev release.

lnh92’s picture

Thanks fizk!

Bobop’s picture

#78 worked perfectly for me

JamesOakley’s picture

Small request: Please can people now stop posting that the patch in #78 works for them.

It's been established that #78 works, to the point where the (new) maintainer has committed the patch. (Big thanks for that).

The issue is marked as "fixed". Either apply the patch in #78 to the current released version, or switch over to use the -dev release until a new point release is made.

If everyone can refrain for adding "works for me" comments for two weeks, this issue will get moved automatically from "fixed" to "closed". Otherwise, we'll be here some time..!

Thanks again to fizk for becoming a maintainer, and committing this (and a few other) patch(es).

colan’s picture

I'd recommend having the thread locked by the site maintainers if we get any more "me too" comments.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

fazni’s picture

Thank u guys work for me (y) #3 #4

sanjaykaronjiya’s picture


comment #3 worked for me!....

ballboy’s picture

#3 worked for me too :-) thanks!

fenstrat’s picture

@fazni @sanjaykaronjiya @ballboy *please* read #118.

nanomn’s picture

#3 worked for me...

asirjacques’s picture

Patch works for me too. (version 7.x-3.4)


colan’s picture

I just created #2354363: Lock issue thread (too many "me too" comments). Hopefully the admins will get to it soon.

dddave’s picture

Version 3.5 has this fix included.