Plugin caused our website to fail to load…

@loghin

While I know you have the best of intentions, it’s forum policy that you <em>not</em> ask users for admin or server access. Users on the forums aren’t your customers, they’re your open source collaborators, and requesting that kind of access can put you and them at high risk.

If they <em>are</em> paying customers (such as people who bought a premium service/product from you) then by all means, direct them to your official customer support system. But in all other cases, you need to help them here on the forums.

Thankfully are other ways to get information you need:

<ul>
<li>Ask the user to install the <a href=”https://www.ads-software.com/support/plugin/health-check/”>Health Check plugin</a> and get the data that way.</li>
<li>Ask for a link to the https://pastebin.com/ or https://gist.github.com log of the user’s web server error log.</li>
<li>Ask the user to create and post a link to their phpinfo(); output.</li>
<li>Walk the user through <a href=”https://www.ads-software.com/support/article/debugging-in-wordpress/”>enabling WP_DEBUG and how to log that output to a file and how to share that file.</a></li>
<li>Walk the user through basic troubleshooting steps such and disabling all other plugins, clear their cache and cookies and try again (the Health Check plugin can do this without impacting any site vistors).</li>
<li>Ask the user for the step-by-step directions on how they can reproduce the problem.</li>
</ul>

You get the idea.

We know volunteer support is not easy, and this guideline can feel needlessly restrictive. It’s actually there to protect you as much as end users. Should their site be hacked or have any issues after you accessed it, you could be held legally liable for damages. In addition, it’s difficult for end users to know the difference between helpful developers and people with malicious intentions. Because of that, we rely on plugin developers and long-standing volunteers (like you) to help us and uphold this particular guideline.

When you help users <em>here</em> and in public, you also help the next person with the same problem. They’ll be able to read the debugging and solution and educate themselves. That’s how we get the next generation of developers.

Hi @joyryde !

It is unfortunate to hear about the Cloudways issue. I would love to help you troubleshoot this further.

Are you using version 1.1.2 of the plugin? Additionally, I see that you are using a plugin called “Asset CleanUp: Page Speed Booster”. This is often paired with other caching plugins that might control your heartbeat interval. While Dynamic Front-end Heartbeat Control is meant to work with multiple existing performance plugins, it’s best to let the heartbeat interval be handled by only 1 plugin. You can make use of virtually all features a caching plugin has to offer – just disable its heartbeat control.

As recommended here, you can install this plugin so we can further inspect any compatibility issues:

https://www.ads-software.com/plugins/health-check/

Also kindly post your WordPress Error log on a website like:

https://pastebin.com/

I’m looking forward to hearing back from you.

Hi!

Asset CleanUp: Page Speed Booster has no heartbeat control that we are aware of, it’s a plugin that stops other plugins from loading their CSS and scripts where they aren’t needed.

We also cannot use caching plugins because Cloudways uses server caching, so none of them work with it.

Hi @joyryde !

Thank you for your response.
Cloudways works with caching plugins and they also have their own plugin called Breeze. You can look it up if you are interested in this topic further.

Back to our issue. Can you please confirm that you have tried using the latest version of the plugin and if you get the same error?

https://downloads.www.ads-software.com/plugin/dynamic-front-end-heartbeat-control.1.1.3.zip

In the event that you get the same error, kindly post your error log here so we can pinpoint the exact issue.

Looking forward to hearing back from you!

We tried using WP Super Cache with Cloudways and it failed, causing caching to never be able to be cleared, and product to all be outdated. Cloudways told us to remove the plugin because caching plugins aren’t compatible with server side caching. We also used to use Breeze years ago and Cloudways had us remove it due to it causing numerous issues with the website.

Yes, we tested your current version, as it was the only version that was offered in the plugins directory when we tested it 24 hours ago.

I just enabled your plugin again just now, and the pages appear to be loading properly, can you check for us?

https://nomadicsupply.com/jenhert-mercedes-sprinter-amp-v-40-camptec-4-channel-audio-amplifier-11306/

The plugin was updated yesterday adding a new performance feature(asynchronous heartbeat calculation) making it more robust. I have a checked and everything is loading properly now. Great job!

About the caching, it really comes down to your setup and how it was configured at the time. Setting up a caching plugin on Cloudways does indeed take a bit more care than your regular shared hosting caching. Do you recall if you set the proper paths to Varnish or Redis cache clearing? Without calling for server cache clearing your website can indeed serve old content.

Hi!

We use the Proxy Cache Purge plugin to automate the Cloudways caching. Everything on our site works well with it, but as soon as we attempt to add a plugin such as WP Super Cache, we can no longer clear any cache and all content remains stuck; nothing we update on the website ever appears no matter how many times we force clear the cache.

As soon as we disable the WP Super Cache plugin, we can make updates to the website and see them again in real time.

“The plugin was updated yesterday adding a new performance feature(asynchronous heartbeat calculation) making it more robust. I have a checked and everything is loading properly now. Great job!”

THANK YOU! We appreciate your help!

• This reply was modified 1 year, 6 months ago by joyryde.