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).

Comments

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.

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)

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

<?php
$cell
= $data['data'];
?>

change to

<?php
     
if (!isset($data['data'])) {
        continue;
      }
     
$cell = $data['data'];
?>

@dizarter, I think it would be better this:

<?php
if(!is_array($data))
  continue;
?>

Yep #4 worked for me.

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.

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

Thanks.

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) {
  [0]=>
  array(1) {
    ["data"]=>
    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) {
  [0]=>
  array(7) {
    [0]=>
    array(3) {
      ["data"]=>
      array(6) {
        ["date"]=>
        string(0) ""
        ["datebox"]=>
        string(0) ""
        ["empty"]=>
        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) )
        continue;
      $cell = $data['data'];

I can provide you with additional var_dumps if you want.
Cheers

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

Issue tags:+PHP 5.4

adding tag

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

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

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

Setting to needs review...

#3 worked for me as well!!!

Thanks!

Regards,

Arnold

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.

Status:Needs review» Reviewed & tested by the community

The patch worked for me. Thanks, rickmanelius.

Irene Kraus, here is some info on applying patches:

http://drupal.org/patch/apply
http://youtu.be/i-oe7_qHreY

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

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:
http://drupal.org/node/1019816

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:
http://drupal.org/node/60179

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!

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.

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

#4 worked for me. MAMP - PHP 5.4.4

yes.. thanks.

<?php
if(!is_array($data))
  continue;
?>

is worked for me.

Patch in #12 works for me as well.

#12 worked like a charm, thx :-)

patch removed the error for me too. thanks alot!

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

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.

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!

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.

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.

<?php
// <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...

<?php
     
// 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;
        continue;
?>

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)

Patch #12 works like a charm!
Thanks.

#12 works! please commit

patch #12 worked for me too :-D

#4 worked for me. thank you so much.

#4 works for me
that is the solution in code

thanks dcoulombe

#12 perfect.

Tank you.

Status:Reviewed & tested by the community» Needs work
StatusFileSize
new1.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

#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))

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.

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;
+ }
}

@fquran - Any patch?

@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.

@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.

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?

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.

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

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

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.

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'?).

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

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

Issue tags:+PHP 5.4

and the tag again

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.

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.

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']; */
      if(!is_array($data))
        continue;

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.

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?

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

StatusFileSize
new806 bytes

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.

Succesfully tested the patch with PHP 5.5.

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

Yes, I applied the patch of #58.

Status:Needs review» Reviewed & tested by the community

The code looks good, and it works for me.

Worked for me also on PHP 5.4

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

works for me as well, thanks!

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!

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

@pingers- can we get a commit?

Thanks a lot guys...dcoulombe & dizarter

Patch in #58 works for me also.

Can this be committed please?

Thank you very much

Also confirming that #58 is RTBC.

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.

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.

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:

<?php
if(!is_array($data))
  continue;
?>

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'];

with

<?php
     
if (!isset($data['data'])) {
        continue;
      }
     
$cell = $data['data'];
?>

as posted in #3.

#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).

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.

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

Priority:Normal» Major
Issue summary:View changes
StatusFileSize
new1.96 KB

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

Priority:Major» Normal
Status:Reviewed & tested by the community» Needs review

Patch in #78 works for me.

Status:Needs review» Reviewed & tested by the community

Confirming that #78 works. Marking as RTBC.

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

Patch 78 worked like a champ for me thanks.

Confirmed. #78 works.

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.
http://frontdoor.biz/pac
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.
but...
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)

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

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.

#78 works for me to.

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")

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

#78 has also worked for me so far.

#78 works. Thanks!

#78 works for me too. Thank you!

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.

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

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

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.

@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.

#78 worked for me. Thanks.

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