I entered this as an issue, but since I haven't heard anything I thought I would try here as well.
I just installed SCHOLAR-2-0-BETA14 (on a shared hosting plan, with PHP 5.4). I went through the installation and it seemed to install correctly, but at the end I got a page full of identical warnings.
strict warning: Non-static method view::load() should not be called statically in /home/username/webapps/openscholar/sites/all/modules/contrib/views/views.module on line 879.
When I proceeded to the main page, I see this same warning, plus a bunch more, starting with:
strict warning: Declaration of views_handler_filter::options_validate() should be compatible with views_handler::options_validate($form, &$form_state) in /home/username/webapps/openscholar/sites/all/modules/contrib/views/handlers/views_handler_filter.inc on line 589.
strict warning: Declaration of views_handler_filter_boolean_operator::value_validate() should be compatible with views_handler_filter::value_validate($form, &$form_state) in /home/username/webapps/openscholar/sites/all/modules/contrib/views/handlers/views_handler_filter_boolean_operator.inc on line 149.
strict warning: Declaration of views_plugin_style_default::options() should be compatible with views_object::options() in /home/username/webapps/openscholar/sites/all/modules/contrib/views/plugins/views_plugin_style_default.inc on line 25
and more ....
I was able to get an initial site set up, but then that page has warnings as well:
strict warning: Non-static method vsite::excluded_paths() should not be called statically in /home/username/webapps/openscholar/sites/all/modules/openscholar_vsite/vsite/plugins/vsite.inc on line 242.
strict warning: Non-static method space_og::excluded_paths() should not be called statically in /home/username/webapps/openscholar/sites/all/modules/openscholar_vsite/vsite/plugins/vsite.inc on line 218.
strict warning: Non-static method space_type_purl::excluded_paths() should not be called statically in /home/username/webapps/openscholar/sites/all/modules/contrib/spaces/spaces_og/plugins/space_og.inc on line 185.
strict warning: Declaration of vsite::router() should be compatible with space_type::router($op, $object = NULL) in /home/username/webapps/openscholar/sites/all/modules/openscholar_vsite/vsite/plugins/vsite.inc on line 262.
Basically I get warnings on any page I'm on within openscholar, whether logged in as an administrator or as a regular user. I tried turning the error_reporting php variable off (setting it to 0) in the .htaccess file but that seems not to have made any difference whatsoever.
I'm happy to contact my hosting provider if it is an environmental problem, but I'm not sure what to ask them to check. Thanks.
Comments
I dont expect Drupal /
I dont expect Drupal / OpenScholar to work with PHP 5.4. PHP 5.2 is the supported version.
thanks!
worked
Thanks, forcing 5.2 worked.
Disabling warnings from php strict in Drupal
I'm well aware that hacking core is frowned upon, but sometimes ya gotta do what ya gotta do. Running drupal 6 with views 2.x using PHP 5.4 (Fedora 17 in this case) yields a number of strict warnings that are not easily turned off. PHP doesn't allow you to turn off these strict warnings in its php.ini file, they come through even if E_STRICT is disabled, see
http://stackoverflow.com/questions/4692999/e-strict-messages-thrown-thou... for more details.
In order to fix this, I have edited includes/bootstrap.inc and put the following at the beginning of function drupal_set_message starting after line 991:
// filter out strict warnings due to conflicts between views-2.x and PHP 5.4
if( !strncmp($message, 'strict warning:', 14) ) {
return isset($_SESSION['messages']) ? $_SESSION['messages'] : NULL;
}
There may be other messages that come through that you want to filter in this manner as well.
If there is a hook that can be used to filter drupal messages or a cleaner way to do this by adding a module instead of hacking core I'd love to hear about it.
Good idea!!!
Good idea!!!
Why not patch Views instead
There is a simple patch for Views here: http://drupal.org/node/465332#comment-5677056. This apparently isn't being fixed in Views in order to maintain PHP 4 compatibility.
Also
Here are some additional fixes for these types of warnings. For Views: http://drupal.org/node/893128#comment-5680104. And for CCK: http://drupal.org/node/1962718
Worked for me!
Within a 6.32 environment I added it like this:
function drupal_set_message($message = NULL, $type = 'status', $repeat = TRUE) {
if ($message) {
//
// GL 2014-07-28 PHP5.4 and Drupal 6 are not compatible and I am seeing a huge
// amount of STRICT warnings. This code eliminates them.
// BEGIN
// filter out strict warnings due to conflicts between views-2.x and PHP 5.4
if( !strncmp($message, 'strict warning:', 14) ) {
return isset($_SESSION['messages']) ? $_SESSION['messages'] : NULL;
}
// END
Seems to work just fine.
Thanks DarrelDuane!
Awesome!
THANK YOU!! That fixed my problem, as well :)
Thanks
Thank You !!!
This would really help.......:)
Thanks
Thank :)
Thanks
Thanks, it worsk fine.
Awesome.. Thanks :)
Awesome..
Thanks :)
A much better solution
If you're going to hack core, a much better solution is to properly fix the error handler. Add this line to the top of the drupal_error_handler function in includes/common.inc:
if ($errno == E_STRICT) { return; }
Or you could
configure error reporting in the php.ini or your site's settings.php and make Drupal take them into account:
settings.php
ini_set('error_reporting', 22519);
common.inc:
// if ($errno & (E_ALL ^ E_DEPRECATED ^ E_NOTICE)) {
if ($errno & (E_ALL ^ E_DEPRECATED ^ E_NOTICE) & error_reporting()) {
You can generate your error reporting code here:
http://www.bx.com.au/tools/ultimate-php-error-reporting-wizard
solution
Thanks eli,
This worked for me.
Eric,
http://www.statisticsworldwide.com
Thanks Eli. Your suggested
Thanks Eli.
Your suggested changed has worked for me as well.
Worked for me!
Thanks Eli, I'd been chasing down all of the E_STRICT era via the Views and CCK Threads and was having no luck, this solved the issue for me. I know its kind of a no-no to hack core like this, but I'm just rehearsing the migration of my site from D6 to D7 on MAMP, so I don't expect to have to do this on the live version. You're a rock star bud!
Works great! Thx!
Can't say how I appreciate this solution! Much easier than hacking core!
Thanks again!
Thanks for the tip eli! That
Thanks for the tip eli! That did it! Now to upgrade to Views 3 and then to remove it. Wish me luck!
Hey Guys, Actually I don't
Hey Guys,
Actually I don't know why I didn't think of it, but the "Error reporting" module will disable showing errors to the screen and you can limit to only the log file. I think this is a better alternative to hacking core and just removing the errors completely unless you just don't want to fill the error log up. Then this works the best.
Error Report is - http://www.sitename.com/admin/settings/error-reporting
Clear your cache, as always...
Otherwise, you will be wondering, like me, why it didn't work at once! :-) THANK YOU!
Karol Haltenberger's solution should be in core
There really should be a way to override error_reporting by setting your own levels of what you want to to ignore/log without hacking core.
Karol Haltenberger's solution is the cleanest solution, if we could just get that into core this would be very nice... if not, here is a diff / patch you can use:
diff --git a/includes/common.inc b/includes/common.inc
index 80fc911..cfb54f6 100644
--- a/includes/common.inc
+++ b/includes/common.inc
@@ -665,7 +665,9 @@ function drupal_error_handler($errno, $message, $filename, $line, $context) {
return;
}
- if ($errno & (E_ALL ^ E_DEPRECATED ^ E_NOTICE)) {
+ // HACK allows specifying one's own error reporting levels in settings.php
+ // See https://groups.drupal.org/node/217529#comment-928503
+ if ($errno & (E_ALL ^ E_DEPRECATED ^ E_NOTICE) & error_reporting()) {
$types = array(1 => 'error', 2 => 'warning', 4 => 'parse error', 8 => 'notice', 16 => 'core error', 32 => 'core warning', 64 => 'compile error', 128 => 'compile warning', 256 => 'user error', 512 => 'user warning', 1024 => 'user notice', 2048 => 'strict warning', 4096 => 'recoverable fatal error');
// For database errors, we want the line number/file name of the place that
It worked for me
I tried this solution and it worked for me.
Thanks mate