Skip Navigation

[Resolved] Receiving frequent PHP Fatal Error on all sites; appears to be Jetpack conflict

This thread is resolved. Here is a description of the problem and solution.

Problem:
With Toolset Types and Jetpack active I see often this error in the logs:

PHP Fatal error: Uncaught Error: Call to undefined function WP_Installer() in types/vendor/toolset/toolset-common/inc/controller/admin/notices.php:94

Solution:
It's solved in the current stable release.

This support ticket is created 7 years, 2 months ago. There's a good chance that you are reading advice that it now obsolete.

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

Sun Mon Tue Wed Thu Fri Sat
- - 14:00 – 20:00 14:00 – 20:00 14:00 – 20:00 14:00 – 20:00 14:00 – 20:00
- - - - - - -

Supporter timezone: Asia/Ho_Chi_Minh (GMT+07:00)

Tagged: 

This topic contains 21 replies, has 3 voices.

Last updated by sarahP 7 years ago.

Assisted by: Beda.

Author
Posts
#573881

I found this issue first reported here: https://toolset.com/forums/topic/php-fatal-error-uncaught-error-call-to-undefined-function-wp_installer/ and again here https://toolset.com/forums/topic/undefined-function-wp_installer-plugins-adminnotices-php-on-line-94/

The first thread has been closed, so I reported my findings in the second post but did not receive a respose, so I am resubmitting anew.

With debug enabled on my sites running Toolset, I see the following error:

PHP Fatal error: Uncaught Error: Call to undefined function WP_Installer() in /home/SITE/public_html/wp-content/plugins/types/vendor/toolset/toolset-common/inc/controller/admin/notices.php:94
• Stack trace:
• #0 /home/SITE/public_html/wp-content/plugins/types/vendor/toolset/toolset-common/inc/controller/admin/notices.php(72): Toolset_Controller_Admin_Notices->screen_any()
• #1 /home/SITE/public_html/wp-includes/class-wp-hook.php(298): Toolset_Controller_Admin_Notices->init_screens(Object(WP_Screen))
• #2 /home/SITE/public_html/wp-includes/class-wp-hook.php(323): WP_Hook->apply_filters('', Array)
• #3 /home/SITE/public_html/wp-includes/plugin.php(453): WP_Hook->do_action(Array)
• #4 /home/SITE/public_html/wp-admin/includes/class-wp-screen.php(396): do_action('current_screen', Object(WP_Screen))
• #5 /home/SITE/public_html/wp-admin/includes/screen.php(232): WP_Screen->set_current_screen()
• #6 /home/SITE/public_html/wp-content/plugins/jetpack/sync/class.jetpack-sync-sender.php(131): set_current_screen('sync')
• #7 in /home/SITE/public_html/wp-content/plugins/types/vendor/toolset/toolset-common/inc/controller/admin/notices.php on line 94

I have narrowed it down to a conflict with Jetpack, which makes sense since it is mentioned in the Stack trace #6. To confirm this, on a non-live site, I first deactivated most of my plugins, then when I reactivated and connected to Jetpack, the error appeared again. With Jetpack acitve, the error occurs frequently. I'm not sure what triggers it exactly, but I guess it happens whenever there is some communication with Jetpack, which is often, several times an hour.

Hope you can help. I worry that the frequency of these errors is causing performance issues on these sites.

Thanks,
Sarah

#573917

Shane
Supporter

Languages: English (English )

Timezone: America/Jamaica (GMT-05:00)

Hi Sarah,

Thank you for contacting our support forum.

As this is a duplicate post I would ask Beda to perform a followup in the ticket.

Thanks,
Shane

#573925

Thanks, Shane...whatever will help get this resolved! I assmued I did not get a response because I was not the original topic poster. It also seems like the other two posts were unresolved because the original posters did not respond. But I am willing to stick around and provide whatever info or access to get to the bottom of this!

#573929

Sorry, Shane....I just re-read your reply and am a bit unclear: do I need to do something to follow-up with Beda, or will he be assigned to this topic without me having to do anything else at this time?

#574002

Hello, here I am.

Very nice from you to help us going to the bottom of this "ghost".

If you search by this error, you will see that there are several reports where we never came to the bottom of "how to replicate".

Your report here looks promising.
We already had similar issues with JetPack:
https://toolset.com/errata/saving-a-post-with-a-file-field-may-produce-an-error-if-jetpack-is-installed/

I will now make extended tests with Jetpack, see if I can replicate something, and feedback as soon as possible here.

Thank you.

#574027

I set up an online test site, I connected JetPack, installed Toolset Types, but no error happens.

I also run the first steps of "recommended features" by JetPack.

Can you log in with the data I provided to your email and see if some changes to settings need to be made so to produce the error?
Can you also let me know where exactly you seem them?

#574225

Got it, danke! I'll set up Jetpack as I have it on my sites and will report back.

I have debug enabled and have plugin Error Log Monitor installed, so the errors are displayed on my dashboard. I can provide you access to one of my sites if you'd like to take a look for yourself.

#574236

Ok, I compared Jetpack, and your version has much more activated than I do on my sites, so there was nothing more for me to activate.

I considered also that the theme could be an issue (all my sites use Genesis), but even with the default theme, the error still occurs. I considered importing my Toolset settings to the test site but not sure if that would help since I use different settings on my sites but all generate the same error.

I clicked around a bit to see if I could find the error, and I did find errors on the Post Forms and User Forms pages, but these seem to relate to CRED which I do not have installed on my sites. The error mentions Jetpack, so maybe this is a hint in the right direction?!

Let me know what I can do next.

#574386

Yes, surely that error message is a hint. I know where it leads, I know what the error tells us, and why it happens.

But, the problem is, it is not replicable.

The error means, WP_Installer() (the function) is not defined.
But it is, as you will be able to doublecheck in your FTP files, in the Types Plugin, under types/vendor/otgs/installer/includes/class-wp-installer.php.

It might be possible that with some constellations we need to create a new instance of the Class, so the function that calls that class does not return undefined.

But for this we need to know why it happens, so to fix this properly.

I am consulting with the responsible Developer a part of the code, where I see the issue could be sourced.

Please await my feedback here, I will update you soon.

For him to work more effectively it will be very helpful if he could log into a site where this is visible.

Might it be possible that you have a Testing Site where this happens?
I am a little reluctant to let the Developer analyse this on your live site.

It might be that he needs to edit the code, which can result in issues.
Since we cannot replicate it locally, it is very helpful for us to have a copy of the site where it happens.

There are different approaches we can take:

1. A Site's Snapshot.
But, most probably I will not see the error on my end, as I suspect it is due to some things in the settings of Jetpack and it's way of managing the site.

2. Access to a test Site, or the permit to debug it on your live site.

I activated a Private reply, leaving both choices open.

Please let me know if you could help us with one of both.

#576011

I replicated your site locally, but the error is not filed.

Also on the online site, I do not receive those Errors in the Log, just the ones from CRED; which I filed as a BUG internally.

What I need to know is, on what action exactly this error happens.

The error suggests something with the Plugins Area or Admin Notices being dismissed, similar things, that trigger the error.

You can find out how you can trigger the error by deleting the content of your Error log and check when it does report the error again.

I need to know this so to have a replicable scenario.
I believe it might also be triggered by a CRED Form, but you do not use CRED on your own site, hence, it is not the only source.
https://toolset.com/forums/topic/after-last-update-all-my-ajax-forms-gives-error-in-the-first-run/

But there are also other reports where it was solved by PHP upgrades (not applicable here either) or simply I never heard back.

Can you help me to spot where, or after what, the error appears on your site?

I will keep you updated on the findings as well and the process of the CRED issue.

#576723

I did a fair amount of testing....visited pages on the site, on the backend, de/activated and updated plugins, toggled stuff in Jetpack, and this is what I found:

The error occurs EVERY time I activate and connect to Jetpack. The error occurs when toggling some Jetpack options (turned off Protect; turned on Image performance; enabled Jetpack mobile theme, toggle comments), but only once; it does not occur again when I immediately repeat the operation.

Mostly the error occurs by itself with no action taken by me. In the log, it shows it happened twice around midnight, then again several times an hour between 3-5pm. This particular website is not open to the public, so I don't think there were any hits on the site at these times to cause the error. And this is why I suspected that the error occurs when there is some communication with Jetpack. Stack trace #6 mentions jetpack-sync:

#6 /home/SITE/public_html/wp-content/plugins/jetpack/sync/class.jetpack-sync-sender.php(131): set_c in /home/SITE/public_html/wp-content/plugins/types/vendor/toolset/toolset-common/inc/controller/admin/notices.php on line 94

But I haven't found any info about when, how often, etc Jetpack syncs

Also, possibly unrelated, my site is loading exceptionally slowly after connecting to Jetpack, and I'm getting a new error:

PHP Warning: mysqli_real_connect(): (08004/1040): Too many connections in /home/SITE/public_html/wp-includes/wp-db.php on line 1548

Each time, it is followed by several instances of the Toolset error within 1 minute. Could this whole thing be an issue with my host? Or could it just be the error is causing issues with my host? Now I'm getting "Error establishing a database connection" on all my reseller site, so clearly my host is not happy with something!

Once the site is back up to speed, I'll see if there's anything else I can test. Sorry I didn't find anything super helpful! But let me know if you need me to do anything else.

#576791

Thank you very much for this informations.

I will forward this to the responsible developer, I think we have enough to work with.

Thank you once more, and I will update you here about the process.

#581555

I can replicate several errors with Jetpack, but all related to CRED.

I cannot replicate the Installer problem.
I once again set up a test site to confirm this.

I sent you an email with log in data. Can you review the Jetpack Settings?
Feel free to also connect to your own.

The CRED errors are all being addressed ASAP.

Thank you.

#581835

OK, an update related to the CRED Errors:

This issue here is caused by Jetpack: it modifies the columns listed in the post listing page, for any post type, and it assumes that by default there will be a column for date.

That is is not met for CRED listing pages, but also I am sure tht for several other post types which columns got modified by the same filter, before Jetpack.

I would suggest to open a ticket for Jetpack in their support forum. It looks like an easy fix on their side.

Meanwhile I am also still trying to get to the other error.

#582115

Thanks, Beda. I logged into the Test site and reviewed the Jetpack settings (and connected to my own); I set it up exactly as I have it on one of my sites, though this just entailed deactivating a few settings, so not sure how much help that will be.

I also imported my Types settings and registered Toolset for this site. Since we last talked, I also moved one of my sites to a new host; the error still occurs there, so perhaps that rules out an issue with my current host.

I also tried removing all my custom functions in case something there was the problem, but the error still occurs when reconnecting to Jetpack.

As for the CRED error, I do have one site using CRED but had not been using the Error Logging plugin there. I can set it up there, and if I see the error, I can write to Jetpack support about what you mentioned.

Let me know if you think of anything else you'd like me to try! I'll keep digging to see if I can come up with anything else to test. When I have time, I could maybe clone one of my sites and get it down to bare bones to see if the error still occurs.