The earlier reply message is the quick and easy way to disable the warnings via disabling the PHP.ini settings.
But we normally want those warnings and E_STRICT reports, right?
Sooooo, here's how I temporarily hacked the jumi code by disabling and restoring the message levels at runtime.
This approach works for pretty much any plugin/extension which has the problem.
~~~~
Paste the code below at the beginning of the class definitions for Jumi and Jumirouter
- In ./jumi/jumi.php ... right after "class plgSystemJumi extends JPlugin"
- In ./jumirouter/jumirouter.php ... right after "class plgSystemJumiRouter extends JPlugin"
Code: Select all
////
// Begin DevByStarlight Temporary Hack
private $originalErrorFlags;
private $errorHackDebug = true;
function HideJumiErrors(){
$this->originalErrorFlags = error_reporting(); // ini_get('error_reporting'); //--- Using INI version may not be correct if other runtime changes occur
if ( $this->errorHackDebug == true ) {
echo 'Quiet Jumi Before:' . $this->originalErrorFlags . "<br />\n";
}
error_reporting(0); // Hide messages temporarily - note: may also hide errors in any of our Jumi code too :(
}
function RestoreJumiErrors(){
// Set error level back to what it was
error_reporting($this->originalErrorFlags);
if ( $this->errorHackDebug == true ) {
echo 'Quiet Jumi After:' . error_reporting() . "<br /><br />\n";
}
}
// End DevByStarlight Temporary Hack
////
Example: (using the jumi.php "onAfterRender" case)
Code: Select all
$this->HideJumiErrors();
$mainframe = &JFactory::getApplication();
$this->RestoreJumiErrors();
There were two exceptions ...
1. parseJumiRouter (in jumirouter.php) ... the function isn't part of the class definition so
Code: Select all
$origErrorFlags = error_reporting();
error_reporting(0);
$db =& JFactory::getDBO();
error_reporting($origErrorFlags);
So you can either make sure RestoreJumiErrors() is called along both true or false paths. Or use the following instead.
Code: Select all
$this->HideJumiErrors();
$thingie = ($pluginParams->hide_code == 1);
$this->RestoreJumiErrors();
if ( $thingie ) {
$content = preg_replace( $regex, '', $content );
return true;
}
Also, The HideJumiErrors and RestoreJumiErrors write out "before" and "after" values of the current flags - the numbers should be the same. Once the errors are gone and appears things are working correctly, just set ...
Code: Select all
private $errorHackDebug = false;
~~~~
Sooo ... now you have the php.ini workaround or the hack code to quiet the errors locally and temporarily (using Jumi as an example).
Personally, I like the temporary "make it quiet" hack so I can keep E_STRICT enabled.
Pick whichever makes sense for you.
~~~~
Yeah, it's a pain to go through and use the temporary hide and restore hack. But actually doesn't take too long to do. And the best thing is can keep E_STRICT enabled to detect problems in your own templates, extensions, etc.!
Just remember it will re-appear when you install an update of the plugin (unless the developer fixes it of course). And it'll occur when installing new extensions too ... but that's quick and easy copy pastey.
P.S - I went back to look through my Joomla 1.5.x sites in development mode with the new PHP with E_STRICT enabled and (Sweet maple syrup, Batman!) there were tons of these messages.
