Upgraded from Drupal 5.2 to 5.3 and suddenly, malformed views arguments sent to a Calendar view - e.g. http://example.com/calendar/5/2007/10/25 instead of a correctly formed URL such as http://example.com/calendar/2007/10/25 - result in 3 PHP foreach errors related to table theming - specifically the headers. I've submitted this as a Drupal bug rather than Calendar because the error did not occur in Drupal 5.2, and I'm guessing that Drupal should catch the issue - a string being sent in place of the array that should contain the table headers for the table used for previous and next navigation on a calendar view. An array is expected in tablesort_get_order, table_get_sort, and theme_table. When they don't get it, "warning: Invalid argument supplied for foreach()" is thrown three times - once for every function mentioned.

Because of a couple bots requesting malformed URLs in one of my site's calendars (why, I do not know), I've had to set the site's watchdog to discard entries older than 3 hours, otherwise it fills up the logs so fast (at three errors a page request) I eventually get white screens.

I've tested with both the DRUPAL-5--1-5 and DRUPAL-5--1-6 releases of Calendar and Views (the 1.6 release being the most current), and there's no difference.

I've confirmed that the error occurs on both Apache 2.0.59 on Windows and OS X using PHP 5.2.4 and 5.2.1, respectively.

I've spent a fair amount of time trying to debug this, but am not sure where to go from here and would love some wiser minds' advice.

Should there be a check on the header variable at some point to verify that it's in fact an array? The header arguments in this case originate from the views' arguments in the URL.

I can provide a backtrace if desired. It's quite long...

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

mlsamuelson’s picture

Version: 5.3 » 5.x-dev
FileSize
2.75 KB

I've supplied a patch to add is_array() checks to the functions throwing errors (tablesort_get_order, table_get_sort, and theme_table) when a string is sent in for the $header(s) array.

This seems to solve the issue, and shouldn't adversely affect anything else.

I've changed the version on this issue to Drupal 5 dev, as that's what the patch was created for.

mlsamuelson

mlsamuelson’s picture

Status: Active » Needs review

Oops.

Changed the status to needs review.

drumm’s picture

Project: Drupal core » Calendar
Version: 5.x-dev » 5.x-1.x-dev
Component: theme system » Code

Moving to the correct project.

mlsamuelson’s picture

The patch applies to Drupal core, fixing a lack of type checking for the functions mentioned in #1, above. Perhaps my issue titling was a bit clumsy... or perhaps I'm mistaken that this issue should be fixed in core and my patch is misguided... ?

drumm’s picture

I was misled by the title. However, I do think calendar module should handle checking what it passes to theme('table'). PHP may be sloppy about typing, but we try not to encourage it.

sonicthoughts’s picture

I have the exact same problem with foreach() error. it's all over the boards. what is the best resolution - note i do have arguments with calendar view?

thanks!

KarenS’s picture

Status: Needs review » Postponed (maintainer needs more info)

Is this still a problem in the 5.2 version? I don't see it.

killes@www.drop.org’s picture

Yes, this is a problem at groups.d.o right now.

KarenS’s picture

I don't know of any place where I would be passing something that might not be an array to theme table, and I can't replicate the problem, so I don't know where it is coming from. Is anyone in a place where they can do a debug_backtrace to figure out what function this is coming from?

therainmakor’s picture

Status: Postponed (maintainer needs more info) » Needs review
FileSize
474 bytes

So I was reading some of http://drupal.org/node/171843 and noticed they were talking about the previous/next links. So I figure why not make a check for the array that is being sent to theme_table(). Line 327 of calendar.theme seemed to have just an array being sent without any processing, so I made the following change.

Original

function theme_calendar_nav_wrapper($array) {
  return theme('table', $array, array());
}

Revised

function theme_calendar_nav_wrapper($array) {
  return theme('table', is_array($array) ? $array : array(), array());
}

And now I don't have any errors being written in my log. I noticed that the kind of URLs that were generating these errors was in the form of http://www.example.com/events/73/2008/01/15. Notice the "73" right after the events, well that brought me to a page with the date of Friday, April 1 2140. Don't ask me why but with this fix, the previous/next links do not show up anymore on pages that have that kind of URL. I'm assuming search engine bots are going through the site and getting to very far dates away from now and is causing all the problems. Well, once the bot gets to a page that either the calendar or date module can't handle, it doesn't produce the previous/next links anymore to let it go further. Just my theory anyways.

I will update you all if I continue to not have any messages written to my log.

therainmakor’s picture

I have not found any errors in my log as of today, so I believe the code I submitted fixed the problem.

KarenS’s picture

Status: Needs review » Fixed

Thanks for the help identifying this. This helped me figure out where something that went to that function might not always be an array. I made a different fix and committed it to 5.x, 5.2.x, and HEAD. Please reopen if the fix I committed doesn't work and I'll at least come back and cast this as an array.

beekerstudios’s picture

Worked for me too. I was seeing crazy amounts of errors on this one. I suspect from a crawler or something.

Anonymous’s picture

Status: Fixed » Closed (fixed)

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