Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 1.1.5
Bug #18405 Non-static method PEAR::load Extension() should not be called statically
Submitted: 2011-03-29 03:13 UTC
From: tj Assigned: cweiske
Status: Closed Package: XML_RPC2 (version 1.0.8)
PHP Version: 5.3.6 OS: FreeBSD and GNU/Linux
Roadmaps: (Not assigned)    
Subscription  
Comments Add Comment Add patch


Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know! Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem : 35 + 9 = ?

 
 [2011-03-29 03:13 UTC] tj (Thibault Jouan)
Description: ------------ I got the following PHP error when using the attached test script: PHP Strict Standards: Non-static method PEAR::load Extension() should not be called statically in /usr/local/share/php/XML/RPC2/Backend.php on line 111 Test script: --------------- https://gist.github.com/891398 Expected result: ---------------- $ php bug_test.php | head -n 5 PHP Notice: Undefined property: XML_RPC2_Server_Input_PhpInput::$readRequest in /home/tj/tmp/XML_RPC/XML_RPC2/XML/RPC2/Server/Input/PhpInput.php on line 65 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en"> <head> <meta http-equiv="Content-Type" content="text/HTML; charset=utf-8" /> <title>Available XMLRPC methods for this server</title> Actual result: -------------- $ php bug_test.php | head -n 5 PHP Strict Standards: Non-static method PEAR::loadExtension() should not be called statically in /home/tj/tmp/XML_RPC/XML_RPC2/XML/RPC2/Backend.php on line 111 PHP Notice: Undefined property: XML_RPC2_Server_Input_PhpInput::$readRequest in /home/tj/tmp/XML_RPC/XML_RPC2/XML/RPC2/Server/Input/PhpInput.php on line 65 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en"> <head> <meta http-equiv="Content-Type" content="text/HTML; charset=utf-8" /> <title>Available XMLRPC methods for this server</title>

Comments

 [2011-04-21 12:01 UTC] inzite (BigPapa Smurf)
This appears to be a bug in PEAR (present as of version 1.9.2, but may be fixed in later versions). When run in strict mode, PHP 5.3 checks to make sure that class functions are not called statically unless they've been declared with the static keyword. PEAR::loadExtension() is allowed to be called statically, but its implementation omits the static keyword. Hence you get a runtime warning. This is just a warning and should not affect program execution. Note: The documentation for the PEAR::loadExtension() function specifically states that it can be called statically. See http://pear.php.net/manual/en/core.pear.pear.loadextension.php
 [2011-05-29 19:35 UTC] doconnor (Daniel O'Connor)
-Status: Open +Status: Analyzed
Quick (if ugly) fix - instantiate a PEAR object and don't call it statically. The better fix is probably to stop trying to load extensions in user code - simply error if you try to instantiate a backend without the right extension. public static function setBackend($backend) { ... $backend == 'Xmlrpcext' && !function_exists('xmlrpc_server_create') ) ) { ... throw new XML_RPC2_Exception('Unable to load xmlrpc extension.'); } }
 [2011-06-30 19:36 UTC] sergiosgc (Sérgio Carvalho)
-Status: Analyzed +Status: Wont fix
Thanks to all involved. This is a fantastic bug report if I've ever seen one. I have relocated the bug to the PEAR package: http://pear.php.net/bugs/bug.php?id=18638 Daniel, I haven't implemented your solutions because: 1) The first one is indeed ugly. I'd be calling a static method non-statically. It is compounding an error with another error. 2) The second one removes functionality. I don't want to change the behavior of the package ad-hoc (deployed installations would break, as the pure-php xmlrpc backend is much much slower). I could set it as a configurable option, but that wouldn't really solve the bug, it would just reduce the scope of situations that trigger the bug. The best solution is really for PEAR to fix the bug upstream.
 [2015-07-26 12:22 UTC] cweiske (Christian Weiske)
-Status: Wont fix +Status: Closed -Assigned To: +Assigned To: cweiske
Fixed in PEAR git branch stable. Will be released in 1.10.0.