- This topic has 10 replies, 4 voices, and was last updated 8 years, 10 months ago by
.
-
Posts
-
Strict Standards: Non-static method TribeCommonLibraries::getInstance() should not be called statically, assuming $this from incompatible context in /Users/Jeffrey/Sites/twentpress/wp-content/plugins/events-calendar-pro/vendor/tribe-common-libraries/tribe-common-libraries.class.php on line 66
Strict Standards: Static function TribeEventsTickets::get_instance() should not be abstract in /Users/Jeffrey/Sites/twentpress/wp-content/plugins/the-events-calendar/lib/tickets/tribe-tickets.php on line 204
Strict Standards: Declaration of Tribe_Events_Pro_Week_Template::event_classes() should be compatible with Tribe_Template_Factory::event_classes($classes) in /Users/Jeffrey/Sites/twentpress/wp-content/plugins/events-calendar-pro/lib/template-classes/week.php on line 17
Strict Standards: call_user_func_array() expects parameter 1 to be a valid callback, non-static method TribeCommonLibraries::activate_plugins() should not be called statically in /Users/Jeffrey/Sites/twentpress/wp-includes/plugin.php on line 406
Strict Standards: Accessing static property TribeSettings::$menuName as non static in /Users/Jeffrey/Sites/twentpress/wp-content/plugins/the-events-calendar/lib/tribe-settings.class.php on line 135
Strict Standards: Accessing static property TribeSettings::$requiredCap as non static in /Users/Jeffrey/Sites/twentpress/wp-content/plugins/the-events-calendar/lib/tribe-settings.class.php on line 136
Strict Standards: Accessing static property TribeSettings::$adminSlug as non static in /Users/Jeffrey/Sites/twentpress/wp-content/plugins/the-events-calendar/lib/tribe-settings.class.php on line 137
Strict Standards: Accessing static property TribeSettings::$errors as non static in /Users/Jeffrey/Sites/twentpress/wp-content/plugins/the-events-calendar/lib/tribe-settings.class.php on line 138
Strict Standards: Accessing static property TribeSettings::$major_error as non static in /Users/Jeffrey/Sites/twentpress/wp-content/plugins/the-events-calendar/lib/tribe-settings.class.php on line 139
Strict Standards: Accessing static property TribeSettings::$sent_data as non static in /Users/Jeffrey/Sites/twentpress/wp-content/plugins/the-events-calendar/lib/tribe-settings.class.php on line 140
Strict Standards: Accessing static property TribeSettings::$validated as non static in /Users/Jeffrey/Sites/twentpress/wp-content/plugins/the-events-calendar/lib/tribe-settings.class.php on line 141
Strict Standards: Accessing static property TribeSettings::$defaultTab as non static in /Users/Jeffrey/Sites/twentpress/wp-content/plugins/the-events-calendar/lib/tribe-settings.class.php on line 142
Strict Standards: Accessing static property TribeSettings::$currentTab as non static in /Users/Jeffrey/Sites/twentpress/wp-content/plugins/the-events-calendar/lib/tribe-settings.class.php on line 143
Strict Standards: Accessing static property TribeSettings::$requiredCap as non static in /Users/Jeffrey/Sites/twentpress/wp-content/plugins/the-events-calendar/lib/tribe-settings.class.php on line 164
Strict Standards: Accessing static property TribeSettings::$adminSlug as non static in /Users/Jeffrey/Sites/twentpress/wp-content/plugins/the-events-calendar/lib/tribe-settings.class.php on line 164
Strict Standards: Accessing static property TribeSettings::$admin_page as non static in /Users/Jeffrey/Sites/twentpress/wp-content/plugins/the-events-calendar/lib/tribe-settings.class.php on line 164
Strict Standards: call_user_func_array() expects parameter 1 to be a valid callback, non-static method TribeEventsQuery::parse_query() should not be called statically in /Users/Jeffrey/Sites/twentpress/wp-includes/plugin.php on line 487
Strict Standards: call_user_func_array() expects parameter 1 to be a valid callback, non-static method TribeEventsQuery::pre_get_posts() should not be called statically in /Users/Jeffrey/Sites/twentpress/wp-includes/plugin.php on line 487
Strict Standards: call_user_func_array() expects parameter 1 to be a valid callback, non-static method TribeEventsRecurrenceMeta::admin_bar_render() should not be called statically in /Users/Jeffrey/Sites/twentpress/wp-includes/plugin.php on line 406
Strict Standards: call_user_func_array() expects parameter 1 to be a valid callback, non-static method TribeEventsQuery::parse_query() should not be called statically in /Users/Jeffrey/Sites/twentpress/wp-includes/plugin.php on line 487
Strict Standards: call_user_func_array() expects parameter 1 to be a valid callback, non-static method TribeEventsQuery::pre_get_posts() should not be called statically in /Users/Jeffrey/Sites/twentpress/wp-includes/plugin.php on line 487
Strict Standards: call_user_func_array() expects parameter 1 to be a valid callback, non-static method TribeEventsRecurrenceMeta::displayErrors() should not be called statically in /Users/Jeffrey/Sites/twentpress/wp-includes/plugin.php on line 406
Seems WP3.6 enforces strict.
The events calendar (& PRO) update said it was compatible with 3.6.
Seems like this is not the case.. Unless you set WP_DEBUG to false.. then you won’t notice a thing. Was it off during dev?The display of errors (and notices) at strict level is a helpful tool – but it doesn’t necessarily mean things are non-functional or incompatible.
In a production site of course it is a best practice to have the display of errors turned off – and in some cases (such as if they cause headers to be dispatched prematurely) having display_errors on can impact operationally in an undesirable way.
All that to say – we’re definitely aware of this situation – but it isn’t one that ordinarily should cause you any great problems so long as you turn the display of errors (through WP_DEBUG in this case) off.
Thank you for your reply.
I get that turning WP_DEBUG doesn’t show you the errors, or notices in this case.
It’s also clear Strict doesn’t necessarily mean things are non-functional or incompatible, WordPress 3.6 however enforces Strict, meaning I should code around in core WP to turn it off?
As far as I know that’s not the Core – Plugin relationship works.I always have WP_DEBUG off on production, but it sure is still as annoying on development.
Obviously I have WP_DEBUG turned on my development; having the warnings appear breaks stylings etc. and makes it harder to find actual errors that pop-up when I am developing my own stuff. I actually use a little snippet like this (might be useful to others) in my wp-config.php:if( stristr($_SERVER[‘SERVER_NAME’], “twentwatchers.local” ) ) {
define(‘DB_NAME’, ”);
define(‘DB_USER’, ”);
define(‘DB_PASSWORD’, ”);
define(‘DB_HOST’, ‘localhost’);
define(‘DB_CHARSET’, ‘utf8’);
define(‘DB_COLLATE’, ”);
define( ‘WP_DEBUG’, true );
} else {
define(‘DB_NAME’, ”);
define(‘DB_USER’, ”);
define(‘DB_PASSWORD’, ”);
define(‘DB_HOST’, ‘live_db_host’);
define(‘DB_CHARSET’, ‘utf8’);
define(‘DB_COLLATE’, ”);
define(‘WP_DEBUG’, false);
}Well, I definitely sympathize but I’m not sure what else to suggest if it’s an absolute must to have WP_DEBUG and by extension WP_DEBUG_DISPLAY on.
Perhaps you could set display errors and the error reporting level at a system level using php_admin_value directives so they can’t be overridden by WordPress when wp_debug_mode() is called?
I also follow best practices by developing new websites with WP_DEBUG set to true.
I would appreciate it if Modern Tribe would fix these warnings asap.
Best,
BrianDefinitely – we’ve got this on the agenda and should be making some changes soon.
In the interim I’m afraid you would have to work around it by forcing the error reporting to a level that omits strict standards (as discussed above, that might be by setting a php_admin_value directive or else using ini_set() after WordPress has already set the level according to WP_DEBUG but before most other code runs – for instance by means of custom mu-plugins code).
Sorry for any inconvenience this causes in the interim.
Hi everyone: just wanted to let you know we’ve made some improvements in this regard – with a particular focus on the core plugin – and so you should see a reduction in the number of strict standard notices shortly (our next maintenance release is about to arrive).
There will still be strict standard notices, however, so please don’t expect them to disappear completely, but we will of course continue to drive forward with further work to resolve all such notices as best we can.
Thanks as ever for your patience and support while we addressed this.
- The topic ‘3.0.3 and PRO 3.0.5 Strict Standards Errors all over the place! Unworkable’ is closed to new replies.