Revo on Centos 5.2 - no web resources tree panel

Ok, I’ve hit something again that I’d got rid of once, but I can’t remember how I did it!

I’ve just commissioned a new server running Centos 5.2 absolutely stock install to replace my previous dev centos box(its faster etc). With the latest SVN revo when I log into the manager The ’web resources’ panel contains no items i.e it doesn’t draw the tree, only the toolbar icons. The ’content elements’ and ’files’ panels are populated OK.

When I refresh the tree(refresh icon) I get this error in the FF error console ’no element found’ pointing to connectors/layout/tree/resource.php line 1.

Sometimes this shows up as line 11557 of ext-all-debug.js, this is in the readRecords function of the Ext.data.JsonReader. I’ve checked the data flow from the original POST which calls the resource connector with the params ’getNodes’ and’ root’ all the way back to the final response from the modconnectorresponse class line 75. The body i.e the json data looks fine to me compared to my windows box.

OK, in firebug I don’t get any response headers nor a response string, hence it has no data to draw the tree with. I can’t see why this should be.

I can’t really get to my other machine to check at the mo(or may be ever) so its driving me nuts a bit.

Its not FF, if a dial up my centos box from the browser on my windows box I get exactly the same error(s) so its on the server somewhere

Anybody seen this?

Ok, some closure on this painful(for me) issue.

After much debugging and trialling on different machines this has turned out to be a PHP 5.1.6 issue, this is stock on centos 5.2 and FC6 both of which the problem exists on. On my laptop which runs FC7 with PHP 5.2.6 its fine. The reason my old centos machine seemed to work was because it wasn’t running stock PHP, it had been upgraded to PHP 5.2 from the centos testing repos. There is a patch to latest svn revo(4876) to get round this as follows :-

Change Line 75 of modconnectorresponse.class.php, change ’die ($this->body);’ to ’return $this->body;’

Change Line 93 of modconnectorrequest.class.php, change ’$this->modx->response->outputContent($options);’ to ’$content = $this->modx->response->outputContent($options);’

Add new line 94 as ’die($content);’

i.e move the die up a level of scope and the json body is always returned, if you leave it where it is sometimes a null string is returned and no corresponding POST entry is seen in the apache access log.

Why? who knows. Its complicated even more by the fact that when I first looked for the fault on my FC6 machine it wasn’t present, it only appeared when I updated to the svn revision above, it was about 3 weeks out. So why its appeared and if it will disappear again on PHP 5.16 is unknown.

Anyway I’m upgrading my centos box to 5.3 today but this still uses PHP 5.1.6 so I’m not hopefull. I’ll up this to PHP 5.2.6 soon so it will probably become a non-issue again. I’ll leave FC6 alone for a while and see if it does just ’go’ again.

I had mentioned elsewhere that MODx 2.0 would not support 5.1.6 and other versions of PHP with known PDO issues built in, but this sounds completely unrelated to PDO. Can you find any PHP bug reports dealing with this issue or a similar one? Personally, I’d never run any version of PHP that out of date, but lot’s of people do.

Regardless, thanks for taking the time to check it out and report your results. Did you report this in Jira by chance? It would be great to have a bug report detailing this.

Yes, I read your post this is not a PDO prob however. I did try and correlate this with the changelog going from PHP 5.1.6 to the next version which I think was PHP 5.2 from the main PHP site but there are shed full of changes here, some quite bland, just saying ’fix heap allocation error’ and the like so I didn’t manage to find anything I could specifically pin this to.

Unfortunately with the PHP version if you run stock RHEL5/Centos5 boxes you are pretty much stuck with it, some people can’t move for various reasons although its becoming pretty standard now to use the PHP 5.2 versions from the extras/testing repo’s on these platforms. That’s one reason why I wanted to create a workround for this should other people hit it.

I’ve not JIRA’d it because I didn’t put it down as a revo bug but I’ll raise one if you wish.

I’ve raised ticket http://svn.modxcms.com/jira/browse/MODX-709 to document this more formally and allow further tracking of the fault if needed.

The affected Centos machine, like its predecessor has been upgraded to PHP 5.2.6, hence the fault has now gone. I have left the FC6 box however, frozen. I intend to update this with subsequent revo versions to see if the fault disappears again.