|
NCER
|
July 20, 2017 at 10:43 pm
My error log is filling up with the following errors:
PHP Fatal error: Uncaught Error: Class ‘EE_Defau’ not found in public_html/wp-content/plugins/event-espresso-core-reg/core/CPTs/EE_Register_CPTs.core.php:583
Stack trace:
#0 public_html/wp-content/plugins/event-espresso-core-reg/core/CPTs/EE_Register_CPTs.core.php(53): EE_Register_CPTs->set_default_term(‘espresso_event_…’, ‘single-event’, Array)
#1 [internal function]: EE_Register_CPTs->__construct()
#2 public_html/wp-content/plugins/event-espresso-core-reg/core/EE_Registry.core.php(930): ReflectionClass->newInstanceArgs(Array)
#3 public_html/wp-content/plugins/event-espresso-core-reg/core/EE_Registry.core.php(692): EE_Registry->_create_object(‘EE_Register_CPT…’, Array, ‘core’, false)
#4 public_html/wp-content/plugins/event-espresso-core-reg/core/EE_Registry.core.php(363): EE_Registry->_load(Array, ‘EE_’, ‘EE_Register_CPT…’, ‘core’, Array, false, true, false)
#5 public_html/wp-content/plugins/event-espresso-core-reg/core/EE_System. in /home/ncer1515/public_html/wp-content/plugins/event-espresso-core-reg/core/CPTs/EE_Register_CPTs.core.php on line 583
|
|
NCER
|
July 20, 2017 at 10:46 pm
Immediately following the error above, I have these in the error log:
The image at https://ncer1.org/wp-content/uploads/2015/06/ncer-logo-125×125.jpg is not readable.
The image at https://ncer1.org/wp-content/uploads/2015/06/ncer-logo-125×125.jpg is not readable.
If you enter the URL into your browser, the image is perfectly readable.
|
|
Tony
|
July 21, 2017 at 4:34 am
Hi there,
Have you modified EE’s core code at all?
The error shows there is no class called EE_Defaul, which is correct, that class doesn’t exist within EE.
The only way I can get that error is to edit the code, this is the original line of code:
$this->_default_terms[][$term_slug] = new EE_Default_Term($taxonomy, $term_slug, $cpt_slugs);
Initializing the EE_Default_Term
The only way I can reproduce is to change that code to:
$this->_default_terms[][$term_slug] = new EE_Defaul($taxonomy, $term_slug, $cpt_slugs);
If you have been editing Event Espresso core then check the EE_Register_CPTs.core.php line 583 and confirm the code is correct.
Note – We highly recommend NOT editing Event Espresso core code, we have tons of hooks within Event Espresso that allow for changing most of the code.
|
|
NCER
|
July 21, 2017 at 5:46 am
This is EE out of the box. Nothing has been edited. Nothing has been changed. This is the code at line 583:
$this->_default_terms[][$term_slug] = new EE_Default_Term($taxonomy, $term_slug, $cpt_slugs);
|
|
Tony
|
July 21, 2017 at 5:57 am
Hmm strange.
Do you have any custom code hooking into EE at all then?
Which PHP version are you running on the server? (You can find that within Event Espresso -> maintenance -> system info -> php version)
|
|
NCER
|
July 21, 2017 at 6:37 am
As an FYI, trying to connect to this site through the ManageWP Worker produces these php errors and a server 500 error:
[21-Jul-2017 12:34:09 UTC] PHP Warning: sprintf(): Too few arguments in /home/ncer1515/public_html/wp-content/plugins/event-espresso-core-reg/core/CPTs/EE_Register_CPTs.core.php on line 448
[21-Jul-2017 12:34:09 UTC] PHP Warning: sprintf(): Too few arguments in /home/ncer1515/public_html/wp-content/plugins/event-espresso-core-reg/core/CPTs/EE_Register_CPTs.core.php on line 449
[21-Jul-2017 12:34:09 UTC] PHP Warning: sprintf(): Too few arguments in /home/ncer1515/public_html/wp-content/plugins/event-espresso-core-reg/core/CPTs/EE_Register_CPTs.core.php on line 450
[21-Jul-2017 12:34:09 UTC] PHP Warning: sprintf(): Too few arguments in /home/ncer1515/public_html/wp-content/plugins/event-espresso-core-reg/core/CPTs/EE_Register_CPTs.core.php on line 451
[21-Jul-2017 12:34:09 UTC] PHP Warning: sprintf(): Too few arguments in /home/ncer1515/public_html/wp-content/plugins/event-espresso-core-reg/core/CPTs/EE_Register_CPTs.core.php on line 453
[21-Jul-2017 12:34:09 UTC] PHP Warning: sprintf(): Too few arguments in /home/ncer1515/public_html/wp-content/plugins/event-espresso-core-reg/core/CPTs/EE_Register_CPTs.core.php on line 455
[21-Jul-2017 12:34:09 UTC] PHP Warning: sprintf(): Too few arguments in /home/ncer1515/public_html/wp-content/plugins/event-espresso-core-reg/core/CPTs/EE_Register_CPTs.core.php on line 448
[21-Jul-2017 12:34:09 UTC] PHP Warning: sprintf(): Too few arguments in /home/ncer1515/public_html/wp-content/plugins/event-espresso-core-reg/core/CPTs/EE_Register_CPTs.core.php on line 449
[21-Jul-2017 12:34:09 UTC] PHP Warning: sprintf(): Too few arguments in /home/ncer1515/public_html/wp-content/plugins/event-espresso-core-reg/core/CPTs/EE_Register_CPTs.core.php on line 450
[21-Jul-2017 12:34:09 UTC] PHP Warning: sprintf(): Too few arguments in /home/ncer1515/public_html/wp-content/plugins/event-espresso-core-reg/core/CPTs/EE_Register_CPTs.core.php on line 451
[21-Jul-2017 12:34:09 UTC] PHP Warning: sprintf(): Too few arguments in /home/ncer1515/public_html/wp-content/plugins/event-espresso-core-reg/core/CPTs/EE_Register_CPTs.core.php on line 453
[21-Jul-2017 12:34:09 UTC] PHP Warning: sprintf(): Too few arguments in /home/ncer1515/public_html/wp-content/plugins/event-espresso-core-reg/core/CPTs/EE_Register_CPTs.core.php on line 455
[21-Jul-2017 12:34:09 UTC] PHP Fatal error: Uncaught Error: Class ‘P6’Ó/’ not found in /home/ncer1515/public_html/wp-content/plugins/event-espresso-core-reg/core/CPTs/EE_Register_CPTs.core.php:583
Stack trace:
#0 /home/ncer1515/public_html/wp-content/plugins/event-espresso-core-reg/core/CPTs/EE_Register_CPTs.core.php(53): EE_Register_CPTs->set_default_term(‘espresso_event_…’, ‘single-event’, Array)
#1 [internal function]: EE_Register_CPTs->__construct()
#2 /home/ncer1515/public_html/wp-content/plugins/event-espresso-core-reg/core/EE_Registry.core.php(930): ReflectionClass->newInstanceArgs(Array)
#3 /home/ncer1515/public_html/wp-content/plugins/event-espresso-core-reg/core/EE_Registry.core.php(692): EE_Registry->_create_object(‘EE_Register_CPT…’, Array, ‘core’, false)
#4 /home/ncer1515/public_html/wp-content/plugins/event-espresso-core-reg/core/EE_Registry.core.php(363): EE_Registry->_load(Array, ‘EE_’, ‘EE_Register_CPT…’, ‘core’, Array, false, true, false)
#5 /home/ncer1515/public_html/wp-content/plugins/event-espresso-core-reg/core/EE_System.co in /home/ncer1515/public_html/wp-content/plugins/event-espresso-core-reg/core/CPTs/EE_Register_CPTs.core.php on line 583
|
|
NCER
|
July 21, 2017 at 6:50 am
Tony, there’s no custom code hooked into EE. This is a vanilla installation. I’m getting these stack traces from the WP Debug log. I’m talking to the folks at ManageWP as well. Something in EE is not initializing correctly when the site is accessed through the ManageWP worker. If I deactivate EE, ManageWP connects perfectly.
|
|
NCER
|
July 21, 2017 at 7:29 am
PHP Version is 7.0.21. The site is on SiteGround. This is their default PHP version.
ManageWP has a lot of customers that run EE. The development team is going to look into whether or not they can workaround the errors if EE is installed so websites can still connect. I’ve looked at your code. The sprintf lines only have 1 parameter, but that parameter is null when connecting with the ManageWP worker because there aren’t any default values for the $post_type, $singular_name, and $plural_name parameters in the register_CPT() function. So the function is passing uninitialized variables to sprintf.
|
|
Josh
|
July 21, 2017 at 7:49 am
Hi there,
Can you check to see if any of the PHP errors and warnings get logged if ManageWP Worker is deactivated?
|
|
NCER
|
July 21, 2017 at 8:07 am
I believe the set of errors in the original post was with ManageWP deactivated. Nevertheless, the worker is deactivated now and the WP Debug logging is on. I’ve fixed the error about reading the logo.jpg by uploading the logo again. I have also corrected the uninitialized variables condition in the register_CPT() function. I’ll keep an eye on things for the next hour or so and report back later.
|
|
Josh
|
July 21, 2017 at 8:14 am
I have also corrected the uninitialized variables condition in the register_CPT() function.
How’s that? I thought you had a vanilla installation of Event Espresso 4 core? Can I assume it’s no longer vanilla?
|
|
NCER
|
July 21, 2017 at 8:26 am
It was completely vanilla until about 15 minutes ago to get past the errors. All I did was provide default values for the uninitialized variables. ManageWP worker still won’t connect to the site unless EE and all the add-ons are deactivated. This is a very active production site and I need things working. I can’t wait for development teams to respond with bug fixes, especially for fatal php errors. We get a lot of sign-ups every month for out luncheons. Errors like the ones EE produces are show stoppers for us.
|
|
NCER
|
July 21, 2017 at 8:30 am
I am a very experienced developer and support dozens of sites. This is the only site with EE installed and the only site that gives me problems on a regular basis. The error log fills up regularly with EE related errors. I’ve ignored them until now because ManageWP used to connect until the last update, then things went south. It’s been an absolute nightmare trying to figure out why and everything traces back to EE.
|
|
Josh
|
July 21, 2017 at 8:36 am
That’s a band-aid fix and not a fix for the underlying issue.
The errors and warnings you are reporting would quickly be noticeable on our tests sites and unit tests for vanilla EE as they are within core functionality. Since these errors are only happening on your site and not being reported on our tests sites, automated testing, and other users’ sites it’s a strong indicator that there is custom code and/or something else hooking into Event Espresso that’s causing these errors. Alternatively, there may be something unique about your server environment (HHVM maybe?).
For example if you look at your error messages like this one:
PHP Fatal error: Uncaught Error: Class ‘P6’Ó/’ not found in /home/ncer1515/public_html/wp-content/plugins/event-espresso-core-reg/core/CPTs/EE_Register_CPTs.core.php:583
and compare the actual code on line 583:
$this->_default_terms[][$term_slug] = new EE_Default_Term($taxonomy, $term_slug, $cpt_slugs);
You can see there’s nothing there to actually fix in the code there. The way forward is find out what’s on your server that’s mangling the class name.
|
|
NCER
|
July 21, 2017 at 8:45 am
Josh, I know it’s a band-aid and you couldn’t be more incorrect. There is absolutely no custom code. Everything you see is coming from EE. If you want access to the server, you can have it. You’ll also need access to Manage WP, but you can’t work on the site during the day when traffic is heaviest. I can set everything back to square one tonight and you can have at it.
|
|
Josh
|
July 21, 2017 at 8:51 am
Can you explain how Event Espresso is mangling the
EE_Default_Term class name? Are you certain it’s not being mangled by another plugin, theme function, or something unique to your server environment?
|
|
Darren Ethier
|
July 21, 2017 at 9:16 am
Hi there, I’m one of the developers on the EE core team. This thread was brought to my attention and we’re truly puzzled by what’s happening in your environment. Since you’ve identified yourself as an experienced developer, I’m sure you’re aware that one important criteria needed in order to fix issues is to be able to accurately identify the cause of the issue and then reproduce. This then helps with not only finding out where the fix is needed, but also ensuring the fix works as expected (without breaking anything else).
One way of identifying the cause of the issue is the usage of error logs. Your assistance with posting the contents of your error logs is valuable. However, right away we’re faced with some puzzling information in your logs.
In the very first log you posted in this thread, the log points to a fatal error produced by attempting to call a class that is not found. However when we look at the vanilla EE core code, we find that the class being called doesn’t exist in our core code (EE_Defau exists nowhere in EE core code). The lines reported in the error log don’t even match up with what we know to exist in vanilla EE core code. As you’ve reported, it doesn’t even match up with what you see on your server! Very puzzling. Not only that, but in a later log you posted (as Josh already pointed out), a fatal is reported for the same area of code but this time the class name is even MORE different:
PHP Fatal error: Uncaught Error: Class ‘P6’Ó/’ not found in /home/ncer1515/public_html/wp-content/plugins/event-espresso-core-reg/core/CPTs/EE_Register_CPTs.core.php:583
So right off the bat this presents the question of what is producing this fatal if the vanilla code in EE doesn’t even match what’s reported in the error log?
Next up is the notices your log is reporting with regards to the too few arguments for the sprintf call. You’ve mentioned that you traced it to the variables not being initialized (they have a value of null). However, this again just does not match up with the vanilla code in EE core. EE_Register_CPTs::register_CPT declares those variables in the signature and EVEN if they are sent into that method with a value of null (which in itself is puzzling because nothing in EE core’s usage of that method would do that), that notice should still not be in your logs (see http://sandbox.onlinephpfunctions.com/code/395d75ee320dbc49e7da40592fc3cd436f40d29c for a proof of concept). That notice means that the first argument in sprintf is declaring placeholders and there are not enough arguments passed into the sprintf function to match the number of placeholders. So again, what your logs are reporting and what is in the actual vanilla EE core code are VERY puzzling.
Finally, when it comes to us reproducing so we can fix this, the notices your logs are reporting and the errors they are reporting are the kinds of things that would show up immediately for anybody on our team who is testing or developing EE core code. Also we have automated tests that run constantly for every commit (and nightly) that these kind of notices and errors would surface on (because the code involved is core functionality covered by our tests).
No one on our team is doubting what’s being reported in your logs. Its just very puzzling to us because there’s simply nothing we can come up with that would explain it. Something in your server environment is affecting how PHP is interpreting code on your server.
Here’s some suggestions that may help you troubleshoot this further (and may give more insight into what’s going on). Apologies if some of these suggestions seem redundant as something you’ve already verified but I don’t know whether you’ve already done them or not.
1. Have you verified when those log entries are produced? Do they ONLY happen when Manage_WP (or whatever is setup on that site) is active or does it also happen when Manage_WP is not active?
2. Are you absolutely certain you are running PHP7+ on your server? One theory we’ve tossed out is that maybe HHVM is actually what’s running (and since HHVM works differently its possible this may account for some of the weird log entries we see. We know that Siteground supports HHVM in certain environments).
3. Do you have any unofficial Event Espresso add-ons installed on this site (unofficial being add-ons that aren’t released by the EventEspresso team)?
4. Do you have any code that is hooking into filters/actions for modifying EE behaviour on this site? Things that would fall in this question include hooking into any WordPress language filters to customize text found in EE.
Please don’t misunderstand any of the line of querying in this to accuse you of doing something that has borked your install. We do want to help and we are interested in finding out what’s going on. It’s just very puzzling for us and we’re trying to figure out what’s unique about your server environment/WordPress install that is producing these things.
-
This reply was modified 6 years, 9 months ago by
 Darren Ethier.
-
This reply was modified 6 years, 9 months ago by Darren Ethier. Reason: grammar fix
|
|
NCER
|
July 21, 2017 at 9:22 am
Josh, I can’t explain how EE is getting mangled. There is nothing unique in the server environment. It is a standard SiteGround shared server environment running PHP 7.0.21. All I know is that this site has been working well with ManageWP until the last EE update. I support a lot of sites and have to use ManageWP. This is the only site that won’t reconnect. When I turn on on WP Debug and try to reconnect ManageWP, the debug.log records the errors I’ve provided. These errors are not produced unless I try to connect to the site through ManageWP.
|
|
NCER
|
July 21, 2017 at 9:30 am
Darren, I agree that this is most puzzling. The unreadable jpg was happening all the time, regardless of what other plugins are active or not. I fixed that by uploading a new logo. These other errors are only produced when I try to connect ManageWP to the site. You can see that the site initially connects and then it fails with a server 500 error as reported by ManageWP. I’ve had WP Debug turned on for the past hour or so with all caching and ManageWP deactivated. This is in the error log and it happened about a minute ago:
[21-Jul-2017 14:28:26 UTC] PHP Fatal error: Class ‘EE_Messages_Base’ not found in /home/ncer1515/public_html/wp-content/plugins/event-espresso-core-reg/core/libraries/messages/EE_message_type.lib.php on line 18
I don’t know how the ManageDB connection process works, but if you want me to produce a screen capture video of the the connection failure, I’ll do it for you.
|
|
NCER
|
July 21, 2017 at 9:42 am
As for your other three questions:
2. On SiteGround, HHVM is only available for cloud servers. Shared servers use Apache/Nginx. This is a shared server environment.
3. The site only uses official add-ons downloaded from our account.
4. There is no code that is hooking into filters/actions for modifying EE behavior on this site.
|
|
Josh
|
July 21, 2017 at 10:30 am
One of the other developers saw the
PHP Fatal error: Uncaught Error: Class 'P6'Ó/' not found error that was posted here and mentioned that he’s seen the same error on sites that were infected with something. Have you scanned the site or can you check with SiteGround to see if they can find any malware infection?
|
|
NCER
|
July 21, 2017 at 10:48 am
SiteGround provides Securi scanning services. The site is scanned regularly for malware. I just scanned it again and the site is clean.
|
|
NCER
|
July 21, 2017 at 10:50 am
And if it was malware, why is it only affecting EE?
|
|
Josh
|
July 21, 2017 at 10:58 am
Can you deactivate WP Rocket’s OPCache?
|
|
NCER
|
July 21, 2017 at 11:41 am
WP Rocket is deactivated. OPCache is not a WP Rocket feature. It is a PHP 7 feature that is turned on by default in all SiteGround PHP 7 sites. It’s probably enabled in your test environments as well if your running PHP 7.
|
|
NCER
|
July 21, 2017 at 11:44 am
WP Rocket provides a way to empty the PHP 7 OPCache, that’s all. I’ve cleared the OPCache repeatedly during this process.
|
|
Josh
|
July 21, 2017 at 12:12 pm
Here’s a stackexchange thread where someone posted a similar issue:
https://stackoverflow.com/questions/26320832/opcache-causes-php-fatal-error-class-xa0l-xdaor-x7f-not-found
You might try the opcache.blacklist_filename workaround suggested there and contact Siteground to see if they can see any issues with the opcache.
|
|
NCER
|
July 21, 2017 at 12:39 pm
Temporarily disabling OPcache allowed me to reconnect ManageWP to the site. Enabling OPCache again caused the site to crash. Then I realized something. SiteGround’s default PHP version used to be 5.x. They recently upgraded all of their servers to default to 7.x. This site was set to use PHP 7 before SiteGround updated their server defaults. I commented out the addhandler line that the cPanel PHP Version manager added to htaccess when the update to PHP 7 was by choice. Everything came back up. I was able to reconnect again, enable WP Rocket, and even enable WP Spamshield. Everything is working again. Thanks for your support. This mystery was a tough one to solve.
|
