• The developers warn to have a backup before enabling this plugin’s features. They make it sound like failure is rare. I tested on a clone of live site and it nuked it. HTTP 500 error. The most difficult error to debug! Tested on a clean local site without problem.

    However… this plugin is made for live sites. It’s made to debug problems that are most likely plugin or theme conflicts. Thus you do have to risk nuking your site. And if it does get nuked and even if you do have a backup, it’s still going to mean you have to take you site down for an uncomfortable period of time.

    I think it’s safer to put your site in maintenance mode at a quieter time and debug normally.

    And if you can’t afford any downtime for your site, this plugin is definitely not worth the risk. In that case, you should really be cloning your site to a test environment.

Viewing 3 replies - 1 through 3 (of 3 total)
  • Plugin Author Marius L. J.

    (@clorith)

    Hi there, and thank you for the feedback!

    I agree, the warning can be jarring, but one of the purposes of the plugin is to help encourage best practices, keeping up to date backups is one of the most important ones.

    We also know we are not infallible, and accidents can happen, we hope make this clear in the notice and encourage users to report any issues to us so that we can avoid them affecting anyone else.

    I would love to get some input on better ways to approach this if you have any, as we definitely wish to keep this a safe and reliable experience.

    I’d like to know if your use of the term nuked it in this regard (judging by your review) means that you got a 500 error, not that it actually destroyed your site? (If it’s the latter, I agree with the terminology, and that’s not good, if not then I feel that’s a bit harsh, granted I understand the frustration). We have identified a common issue with child themes where that error may come up, and have fixed it in the upcoming version though, hopefully this is also the case for you.

    It is definitely always a better idea to do testing on a staging site though, the Troubleshooting Mode is for those who do not have such capabilities, or are unfamiliar with that kind of technology.

    I do hope I’ve addressed your concerns, and please do let us know if there’s any questions you might have ??

    Thread Starter chris howard

    (@chrishoward)

    Hi Marius

    The site could actually be considered destroyed – as other commenters her have also encountered – in terms of requiring some unknown and difficult database hack to recover it. Like others, I tried removing the Health Check plugin.

    Without knowing the hack, the recovery process would be to wipe WordPress entirely (since it’s corrupted) including all files and the database, and then reinstall as per the backup used.

    I didn’t bother with a backup since the site was just a staging site, so I can just wipe it and restage it.

    But Health Check is intended to run on live sites. And yet you need to test it before installing it… To do that you need to stage your site. If I’m going to have to stage my site anyway, I can then troubleshoot the site the usual way. So, why do I need Health Check?

    For it to be useful it needs failsafe switch to quickly turn it off if it breaks a site.

    For your info, I just renamed my child theme folder (so WP wouldn’t then find it) and the site is now un-nuked. So, can confirm my site’s issue was child theme related. (Tho, I though HC automatically switched to Twenty Seventeen?)

    I will give HC another look but will still be very wary

    Thread Starter chris howard

    (@chrishoward)

    Oh! Discovered that even after deactivating and deleting Health Check through the plugins screen, my site still goes 500 when I reactivate the child theme. So, HC still has its claws in my site even after it’s gone.

Viewing 3 replies - 1 through 3 (of 3 total)
  • The topic ‘Not worth the risk’ is closed to new replies.