s9y 1.7: "Depreciated" php methods result blog to crash?

[blog.brockha.us]

At the moment the xml_rpc plugin crashes when used with s9y 1.7

Code: Select all

exception 'ErrorException' with message 'Serendipity error: Function ereg_replace() is deprecated' in /var/www/virtual/grischa/html/blog/include/compat.inc.php:105
Stack trace:
#0 [internal function]: errorToExceptionHandler(8192, 'Function ereg_r...', '/var/www/virtua...', 495, Array)
#1 /var/www/virtual/grischa/html/blog/plugins/serendipity_event_xmlrpc/PEAR/XML/RPC.php(495): ereg_replace()
#2 [internal function]: XML_RPC_ee(Resource id #80, 'METHODNAME')
#3 /var/www/virtual/grischa/html/blog/plugins/serendipity_event_xmlrpc/PEAR/XML/RPC/Server.php(529): xml_parse(Resource id #80, '<?xml version='...', 1)
#4 /var/www/virtual/grischa/html/blog/plugins/serendipity_event_xmlrpc/PEAR/XML/RPC/Server.php(414): XML_RPC_Server->parseRequest()
#5 /var/www/virtual/grischa/html/blog/plugins/serendipity_event_xmlrpc/PEAR/XML/RPC/Server.php(390): XML_RPC_Server->createServerPayload()
#6 /var/www/virtual/grischa/html/blog/plugins/serendipity_event_xmlrpc/PEAR/XML/RPC/Server.php(347): XML_RPC_Server->service()
#7 /var/www/virtual/grischa/html/blog/plugins/serendipity_event_xmlrpc/serendipity_xmlrpc.inc.php(875): XML_RPC_Server->XML_RPC_Server(Array, 1, 1)
#8 /var/www/virtual/grischa/html/blog/plugins/serendipity_event_xmlrpc/serendipity_event_xmlrpc.php(150): require_once('/var/www/virtua...')
#9 /var/www/virtual/grischa/html/blog/include/plugin_api.inc.php(1073): serendipity_event_xmlrpc->event_hook('frontend_xmlrpc', Object(serendipity_property_bag), Array, NULL)
#10 /var/www/virtual/grischa/html/blog/serendipity_xmlrpc.php(10): serendipity_plugin_api::hook_event('frontend_xmlrpc', Array)
#11 {main}

What is that? Is it some kind of testmode I can switch off?

[garvinhicking]

Hi!

I don't remember the actual reasoning for this, but Timbalu/ophian implemented a Exception Handler for the s9y framework to catch on errors, which in "old days" was handled be the error_reporting() thingie.

However I also believe this is currently too broad. deprecation notices should not be caught in the exception handler. Sadly, I'm not efficient with PHP's exception handler...anyone in to help?

Regards,
Garvin

[Timbalu]

Hi
Deprecated messages are Error-Notices as far as I know, they should not appear, as the new set_error_handler is called with E_ALL & ~E_NOTICE. I am running my local blog with php_5.3.8 and the 1.7alpha and I do not get this message. Maybe you are using error_reporting(E_ALL) in your plugin or somewhere else, which unsets the original?

[Timbalu]

I saw you did an upgrade on PEAR / XML / RPC, which now uses an error handling somehow itself.
Maybe we need to add error_reporting(E_ALL & ~E_NOTICE) to the plugin or its PEAR files, while this uses var $errno = 0, which is E_ALL.

[blog.brockha.us]

No, I just updated the PEAR RPC XML to a newer version, that does not use depreciated PHP functions (for luck). So there is no depreciation exception anymore.

But this exception was no warning.. It was crashing the plugin. I think, it's cool to have a testmode, that tells me what is wrong and should be changed (like I was informed, that the PEAR code was much too old). But I would like to have it configurable in the S9Y settings, so I'm still able to use the alpha code in a normal blog environment w/o having it to crash because of things that are warnings only..

[Timbalu]

I think we are talking about 2 different things:
$serendipity['production'] is alway false, if using a non released version.
We do have another dig deeper with $serendipity['production'] set to 'debug'.

Serendipity and the new set_error_handler() use error_reporting(E_ALL & ~E_NOTICE);
which should not halt with error NOTICES, like deprecated method messages.

In case you use $serendipity['production'] = 'debug', it is E_ALL and shows every notice appended to the blogs output.
There you can see that Serendipity has lots of other warning messages, which aren't solved, as they are not very essential to stop something happen.

So your crash must have been produced by any file or includement which sets even error NOTICES to another $errno, then this gets passed to the new error_handler as a fatal error number, I assume. Could you try to investigate this?

You might test that with using ereg_replace() somewhere else.

#edited#

[Timbalu]

You might test that with using ereg_replace() somewhere else.

I did, its not throwing any error and is still working as a function. This is the same behaviour as before. So the (old) PEAR package must set some more restricted error_reporting, which overwrites our own.

[blog.brockha.us]

Yeah, that might be. Mattsches told me via twitter, that PEAR likes to do stuff like that.
So the PEAR XML lib upgrade was the solution for this.