I made this Priority minor because its hard to get there, but you have to evaluate priority yourself.

Fatal error: Cannot break/continue 1 level in C:\***\***\***\sites\all\modules\date\includes\date_api_argument_handler.inc on line 291

I got it when played around calendar view url for calendar module.

1) went to calendar page http://***/***/calendar/
2) entered something after url http://***/***/calendar/randomstring and went there
3) switched from DAY view to MONTH view
4) url changed to http://***/***/calendar/-10 and i got that error on bottom of page

Comments

karens’s picture

Status: Active » Fixed

Yes, it will assume that anything in the position where the date belongs in the url is a date that needs to be parsed, causing a lot of errors. I've just added some checking in the pre_query() to keep from doing that.

markDrupal’s picture

Version: 6.x-2.x-dev » 6.x-2.0-rc6
Status: Fixed » Active

Fatal error: Cannot break/continue 1 level in .../date/includes/date_api_argument_handler.inc on line 336

I still get this bug, even though it was claimed to be fixed in RC6 and I am using RC6 on my site.

I try to generate a page using the date range

"1990--@"

both of these pages fail:

"http://example.org/view/sorttime/all/all/1990--%40"
"http://example.org/view/sorttime/all/all/1990--@"

That page was working when using RC4 of the Date module, it now shows a PHP error

markDrupal’s picture

This doesn't solve my problem but the error is with the following code

    if (date_format($min_date, 'Y') < $this->view->date_info->min_allowed_year || date_format($max_date, 'Y') > $this->view->date_info->max_allowed_year) {
      drupal_not_found();
      break;
    }

Call me presumptuous, but I don't see any "foreach" or "switch" statement to break from at this point in the code, prehapse you wish to stop PHP execution?
in that case wouldn't you use
exit();

    if (date_format($min_date, 'Y') < $this->view->date_info->min_allowed_year || date_format($max_date, 'Y') > $this->view->date_info->max_allowed_year) {
      drupal_not_found();
      exit();
    }
markDrupal’s picture

karens’s picture

Status: Active » Fixed

It should not even get to the break, drupal_not_found() returns immediately, but I'll add exit anyway.

But I cannot replicate any problems even without fixing that when I put in urls like the ones in your examples.

john.karahalis’s picture

I am getting the same error in rc-6 when I visit /calendar/2013-11 or /calendar/2013-W9

Fatal error: Cannot break/continue 1 level in [...]/modules/date/includes/date_api_argument_handler.inc on line 336

john.karahalis’s picture

Status: Fixed » Active

Changed to active, bug does not seem to have been resolved.

junro’s picture

Hello, same problem

Fatal error: Cannot break/continue 1 level in www/sites/all/modules/date/includes/date_api_argument_handler.inc on line 336

My views using an date argument or filter are broken since a few weeks.

I don't have this problem with Calendar anymore, just change the Date year range into the date settings, and no problem it's working.

I've got the Fatal error abow when I want to use the date argument with Panel... It's only working since 1995.

john.karahalis’s picture

Priority: Minor » Normal

I have noticed that an anonymous visitor on our website constantly visits pages which generate this error. This makes me think that this bug could (emphasis on could) potentially be related to a security issue, or at very least be misunderstood as such. For this reason, I am bumping the priority up to "normal".

mikeypotter’s picture

I've got this problem as well - changing break to exit did seem to solve the problem.

Mike

paul-c’s picture

Getting the same problem, lots of these errors in my PHP error logs

[18-Dec-2008 20:06:57] PHP Fatal error: Cannot break/continue 1 level .../../../date/includes/date_api_argument_handler.inc on line 336

djsmeg’s picture

Priority: Normal » Critical

I think this should be a critical issue. I've just noticed that this is causing my drupal to leak database connections when the error occurs, which is taking down my site after a period. It looks like search bots are triggering it, not sure why, by crawling my calendar.
error.log:
[Mon Jan 19 14:09:24 2009] [error] [client 66.249.71.206] PHP Fatal error: Cannot break/continue 1 level in /sites/all/modules/date/includes/date_api_argument_handler.inc on line 336
[Mon Jan 19 14:13:25 2009] [error] [client 66.249.71.206] PHP Fatal error: Cannot break/continue 1 level in /sites/all/modules/date/includes/date_api_argument_handler.inc on line 336
[Mon Jan 19 14:17:24 2009] [error] [client 66.249.71.207] PHP Fatal error: Cannot break/continue 1 level in /sites/all/modules/date/includes/date_api_argument_handler.inc on line 336
[Mon Jan 19 14:25:25 2009] [error] [client 66.249.71.207] PHP Fatal error: Cannot break/continue 1 level in /sites/all/modules/date/includes/date_api_argument_handler.inc on line 336
[Mon Jan 19 14:29:24 2009] [error] [client 66.249.71.207] PHP Fatal error: Cannot break/continue 1 level in /sites/all/modules/date/includes/date_api_argument_handler.inc on line 336
[Mon Jan 19 14:33:24 2009] [error] [client 66.249.71.206] PHP Fatal error: Cannot break/continue 1 level in /sites/all/modules/date/includes/date_api_argument_handler.inc on line 336

access.log (trimmed to show last url access, all others are very similar with random calendar arguments):
66.249.71.206 - - [19/Jan/2009:14:33:23 -0700] "GET /calendar/1999-10-30/1999-10-30 HTTP/1.1" 404 10896 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

Note it's not just googlebot, I also get this with the Yahoo bot, and another one I haven't identified yet.

Changing the break; to an exit(); call appears to plug the database connection leakage, though I will continue monitoring.

drewish’s picture

Version: 6.x-2.0-rc6 » 6.x-2.x-dev
Status: Active » Fixed

in the latest 6.x-2.x-dev release this has been converted to an exit(); so i'd say this has been fixed.

john.karahalis’s picture

"In the latest 6.x-2.x-dev release this has been converted to an exit(); so i'd say this has been fixed."

Considering the critical nature of this bug, can we expect to see a stable release including this fix anytime soon?

Status: Fixed » Closed (fixed)

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