PHP Parse Error - out of the blue

After a couple of years of successful usage of a MODx 0.9.5 driven website, out of the blue (the site hasn’t been modified over the last 3 months) it started showing errors on all pages:

« MODx Parse Error »
MODx encountered the following error while attempting to parse the requested resource:
« PHP Parse Error »

PHP error debug
Error: array_values(): The argument should be an array
Error type/ Nr.: Warning - 2
File: /var/www/html/manager/includes/document.parser.class.inc.php(748) : eval()’d code
Line: 420

I have checked that code at line 420 and here it is:

function outputContent($noEvent= false) {
$this->documentOutput= $this->documentContent;
// check for non-cached snippet output
if (strpos($this->documentOutput, ’[!’) > -1) {
$this->documentOutput= str_replace(’[!’, ’[[’, $this->documentOutput);
$this->documentOutput= str_replace(’!]’, ’]]’, $this->documentOutput);

I really don’t know why everything just stopped working - does anybody have a clue?

Any help would greatly appreciated!

Look at line 420 of the eval()’d code, i.e. the snippet being executed on your page(s). This is not an error at line 420 of the DocumentParser class.

Quote from: OpenGeek at Oct 04, 2007, 09:32 AM

Look at line 420 of the eval()’d code

Sorry, I don’t get it - from which file I should check that line 420? Is there a way to show it through the admin CP?

Thanks for your help

I do not know. You need to see what MODx snippets (or possibly plugins; you’ll need to see what line 748 in DocumentParser is actually doing, processing snippets or plugins) are executing on the pages with the error; likely one with at least 420 lines of code.

OK - thanks also to your help I found the culprit: it’s NewsListing 6.3.3. At line 420 it reads:

$output .= ($recordcount < 1)? $emptytext."\n" : ’’;

But that doesn’t mean much to me... And it shouldn’t crash the CMS anyway. Tried to delete that snipped call from the home page and it does work back again. But I’d like to use that NewsListing snipped on the site anyway... I think there is a bug or something on NewsListing - I’ll try to see if there is any more recent version available.

Quote from: Bryn at Oct 04, 2007, 10:12 AM

OK - thanks also to your help I found the culprit: it’s NewsListing 6.3.3. At line 420 it reads:

$output .= ($recordcount < 1)? $emptytext."\n" : ’’;

But that doesn’t mean much to me... And it shouldn’t crash the CMS anyway. Tried to delete that snipped call from the home page and it does work back again. But I’d like to use that NewsListing snipped on the site anyway... I think there is a bug or something on NewsListing - I’ll try to see if there is any more recent version available.

Newslisting is no longer maintained. See Ditto.

Quote from: OpenGeek at Oct 04, 2007, 09:32 AM

Look at line 420 of the eval()’d code, i.e. the snippet being executed on your page(s). This is not an error at line 420 of the DocumentParser class.

Jason,

I’ve wondered about this before. Is there a way that MODx could set the variable that’s displayed in these parse errors so that it would give the name of the document or snippet instead of "eval()’d code"?

Usually, the problem is in the snippet you’re currently working on, but in cases like this one, you hit some rare boundary condition later and can have a hard time figuring out where to look.


Bob

Quote from: OpenGeek at Oct 04, 2007, 10:18 AM

Newslisting is no longer maintained. See Ditto.

I have updated the NewsListing I was using to version 6.4.2 (see this thread) and now everything works as it should.

Thanks for your help!

Quote from: BobRay at Oct 04, 2007, 11:30 AM

I’ve wondered about this before. Is there a way that MODx could set the variable that’s displayed in these parse errors so that it would give the name of the document or snippet instead of "eval()’d code"?

Usually, the problem is in the snippet you’re currently working on, but in cases like this one, you hit some rare boundary condition later and can have a hard time figuring out where to look.

This should be possible, but the current problem is that to show which snippet is causing the problem, it would need to get passed to the error_handler. However, the error is halting execution of PHP and the error_handler is not made aware of the current snippet being executed. I’m a bit stretched on other tasks at the moment, but I’ll try and make some time to add this for 0.9.6.1 release in the next few days.