Hello @bonniew,
After reviewing the details, it appears that the notice is related to the function WP_Scripts::add and the script handle “wp-auth-check,” which includes dependencies that are not registered. I have thoroughly checked the files of our Speed Optimizer plugin and did not find any reference to “wp-auth-check.” This suggests that the issue may not be directly caused by our plugin.
I recommend checking other plugins or themes that might be enqueueing the “wp-auth-check” script. If you need further assistance with this matter, please don’t hesitate to contact our support team through your SiteGround Client area. They will be more than happy to help identify the source of the issue.
Best Regards,
Daniela Ivanova
I tried disabling my plugins one by one. It went away when I disabled SiteGround Optimizer and SiteGround Optimizer only.
I suggest SiteGround Optimizer stop messing with WP Heartbeat and pretending like it’s someone else doing it.
To address this matter effectively, I recommend posting a ticket through your SiteGround Client area. This will allow our team to review the situation closely and provide you with a more detailed resolution.
Best Regards,
Daniela Ivanova
They not only marked it resolved prematurely, they also removed two posts. One from another person who confirmed replicating the error message and linking it back to SG Optimizer, and then my reply to that.
Hi @bonniew,
I would like to clarify that our team did not remove any of your posts to this topic, only the forum moderators can do that.
Regarding the PHP notice, it does not appear on the sites we have tested, which suggests there might be an incompatibility with another plugin or theme. To thoroughly investigate this issue, we would need to examine it on a site where the notice is occurring. This is the reason my colleague recommended that you submit a ticket to our Help Desk for further analysis. Should we identify any incompatibility, we will report it to our developers so they can implement a fix.
I already “fixed” it on my website and posted my solution. That post vanished for whatever reason. I doubt the moderators took it down because they actually are pretty vocal about when the rules are violated and transparent about why they removed a post.
SiteGround, is it really that hard to install some of the most popular plugins and check yourselves for conflicts? I think that’s what any responsible plugin author should do. I don’t really use anything that exotic. AND I disabled all other plugins and the error happened when SG Optimizer was the only plugin enabled.
I am not putting myself in a silo and submitting a client ticket in the client area in my SiteGround account where only I will see it and you can shunt me away into invisibility. We are supposed to resolve WordPress issues here, as a community, on the WordPress.org website.
Hello @bonniew,
I want to start by clarifying that our team did not remove your previous post or solution. As the plugin support, we do not have the technical ability to delete content on the WordPress.org forums, only the official forum moderators can perform such actions. Moderators typically only remove posts if they violate specific community guidelines, such as containing sensitive private data or excessive expletives, using another person’s post to report one’s issues, etc.
https://wordpress.org/support/forum-user-guide/faq/#i-have-the-same-problem-can-i-just-reply-to-someone-elses-post-with-me-too
Regarding your suggestion to test for conflicts by installing popular plugins, this is unfortunately not a reliable way to identify the root cause of a specific PHP notice, as such are caused by a unique interaction between code and specific site data, it will never appear on our clean testing sites, no matter which plugins we install. There are also tens of thousands of plugins in the WordPress repository. Even “popular” ones have thousands of configuration permutations that we cannot replicate in a generic environment.
Because this notice is not appearing on our own test environments, we need to see it “in action” on a site where it is actually occurring. This is why we recommend submitting a ticket. By investigating the issue through our Help Desk, our technical team can pinpoint the exact code conflict. Once identified, this allows our developers to deploy an official fix in a future update, ensuring that the solution reaches the entire community.
We are not trying to “shunt you away” into invisibility, rather, a Help Desk ticket allows us to safely request technical details that should never be shared on a public forum for security reasons. Our goal is to identify the potential conflict so we can provide a fix that benefits the entire community, but we need your specific environment data to reach that solution, hence why you should submit a ticket in our Help Desk.
Best regards,
Ivaylo Stoyanov
@ivaylostoyanov,
This is happening on my Siteground sites as well.
Relevant settings page
/wp-admin/admin.php?page=sgo_environment
Speed Optimizer – Environment > WordPress Heartbeat Optimization
WordPress Admin Pages: Disabled
Posts and Pages: Disabled
From my testing and code review, it seems that any time the config is asked to disable heartbeat, public function maybe_disable(), it does so, but then other scripts that call heartbeat, can’t find it.
I tried playing with the priorities in public function add_heartbeat_control_hooks(), didn’t help.
I can resolve the issue by simply not disabling heartbeat and defining a timer in the above settings, ie, 120s.
-
This reply was modified 2 weeks ago by
deflime.
Hello,
The case has been reported to our WordPress Developers, and they have confirmed that a fix should be deployed in the next release of the Speed Optimizer plugin. In the meantime, you can either disable debugging mode in WordPress:
https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/
Or, you can keep debug mode enabled and disable only the display of errors and warnings. You can do this by defining the following constants in the wp-config.php file:
// Enable WP_DEBUG mode
define( 'WP_DEBUG', true );
// Enable Debug logging to the /wp-content/debug.log file
define( 'WP_DEBUG_LOG', true );
// Disable display of errors and warnings
define( 'WP_DEBUG_DISPLAY', false );
Best Regards,
Stanimir Panayotov
