error handling

Hi,

we’ve moved a site over to using modx - it’s gone pretty well - we have the new modx system accessing the old data via snippets and we have parts of the old system that are taking snippets and TVs from the modx-end to keep the new look-n-feel. Very nice.

One thing that’s come up is if there is a bug in a snippet - sometimes we get the modx error page. If it possible to customize this to give us more information (it doesn’t always give us in which file the error occurred) and to adjust what happens when an error occurs? For example - instead of dumping - it might be nice for the page to print out whatever it can so we retain the look of the site and then put a error code that would help us track it down. Also perhaps to mail us whenever such an error occurs.

Thanks!
Yehosef

Quote from: yehosef at Dec 25, 2006, 06:53 AM

One thing that’s come up is if there is a bug in a snippet - sometimes we get the modx error page. If it possible to customize this to give us more information (it doesn’t always give us in which file the error occurred) and to adjust what happens when an error occurs? For example - instead of dumping - it might be nice for the page to print out whatever it can so we retain the look of the site and then put a error code that would help us track it down. Also perhaps to mail us whenever such an error occurs.

Unfortunately, to do this at the moment, you have to do some pretty significant hacking to the core code. As part of the new core rewrite however, error handling will be much more robust in the next release.

In addition, since the new MODx core has an assortment of new debugging capabilities and will no longer use eval() to execute snippets, plugins, and modules, there is a lot more control over how you decide to perform error handling within your own code. You’ll even be able to use PHP 5’s exception handling features if PHP 4 compatibility is not one of your requirements, and that can really help reduce the amount and complexity of code you need to properly handle errors in your own code.

Also, keep in mind that as a MODx manager user logged into a manager session, you will also see error dumps in many cases where anonymous users will not, as not having a manager session automatically turns off PHP error_reporting during the requests to MODx.

Jason,

Thanks for the reply and explanation.

I read through you blog post about the design methodologies - thank you for posting it. The new core sounds very promising. I’m sure this is a questions you’ve heard a few times already - but do you have an estimate for when the code would be available? The project I’m working on was using 100% custom code and we’ve been moving it over to modx to help in more clearly separating the logic and presentation and to make it easier for the marketing people to update what they need to. But we’ve felt certain limitations in the current design which seem like they’ll be addressed in the next modx release. If you would like any alpha testers - I’ll volunteer.

Thanks again to you and all the modx team for creating such a powerful and usable system.

Yehosef

PS. I was speaking to someone and zend yesterday about the zend platform for performance issues - caching, etc. I showed him an comparison of several code cachers - he told me how the greatest benefit comes from page and subpage caching and that’s one of the greatest performance benefits of the zend platform. I told him - we have that already - check out www.modxcms.com