And, now the temporary hack version ... using Jumi as an example.
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:
////
// 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
////
Then, for each Strict and Notice message, call
"HideJumiErrors()" and
"RestoreJumiErrors" before and after the offending line.
Example: (using the jumi.php "onAfterRender" case)
Code:
$this->HideJumiErrors();
$mainframe = &JFactory::getApplication();
$this->RestoreJumiErrors();
Repeat for each of the others.
There were two exceptions ...
1. parseJumiRouter (in jumirouter.php) ... the function isn't part of the class definition so
Code:
$origErrorFlags = error_reporting();
error_reporting(0);
$db =& JFactory::getDBO();
error_reporting($origErrorFlags);
2. onAfterRender (in jumi.php) ... the line in question is in the "if()" logic test.
So you can either make sure RestoreJumiErrors() is called along both true or false paths. Or use the following instead.
Code:
$this->HideJumiErrors();
$thingie = ($pluginParams->hide_code == 1);
$this->RestoreJumiErrors();
if ( $thingie ) {
$content = preg_replace( $regex, '', $content );
return true;
}
Again, we are just hiding the errors and not really fixing anything.
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:
private $errorHackDebug = false;
... in both the jumi.php and jumirouther.php
~~~~
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.
