yesyeah

First, thanks for your continued replies and help, greatly appreciated!

The first time I tried that – I cleaned the cache and all the errors went away. However, a few days / week later or whatever it was, we got the notification that the scan picked up another 300+ errors so they were back. I can’t say I have cleared cached and tried this several times to see how common it is, but I’m doing it now and if you can keep this thread open and let me try it out over a week or so, that would probably be best in order to track / monitor it.

I just cleared cache and am scanning again right now (last scan had no related errors) so we’ll see.

That’s hysterical. 🙂 Ok, thanks.

2 Quick Questions:

1. What’s odd though is this NEVER came about until WP Rocket was used and “index-https.html” was tacked on to the end. Why all of a sudden?

2. If they are false positives, should I officially “Ignore” them all and if so, how do I ignore all 300+ of these in bulk?

Thanks!

Thanks @ausdamo!

You sent something directly to them and they responded? Did they confirm this was a bug they’re fixing?

Again, appreciate you following up. Hope they commment here as well.

Hello: Why is this marked as “Resolved? I asked about a timeline and IF IT’S SAFE TO KEEP THE PLUGIN LOADED BUT DEACTIVATED. I know you had a your other plugin removed as well – the fix on this plugin seems to be taking longer. I’m simply asking if users should fully remove the plugin from their sites, or if leaving it on the site, but deactivated is sufficient. And if the plugin SHOULD be removed, will all data / settings be saved or is there a good way to back things up so they can be restored easily once you guys pass safety testing?

Please advise. Thanks.

Thank you kindly, I just sent you a message via the contact form. I appreciate your help!

I already disabled sucuri and wordpress before submitting this and that didn’t help.

I know that a few months ago, the site was experiencing high resource usage. It’s on siteground and they are notoriously and annoyingly sensitive. They did 3 things:

1. disabled api heartbeat
2. disabled default cron and setup real cron
3. setup cloudflare

Could any of those issues be causing this problem? Thanks for your help.

Thanks @tigroumeow Setting a 410 for 1000x images is fine, I’m just trying to find out how to do it.

I’m not very versed on working with the DB to pull files. Can either of you help with specifics on how to find / download that csv of images marked for deletion before deleting? If nothing else, this will allow us to do a visual double check before fully deleting them. Or that process or availability within the plugin already?

Thanks for your help here.

Well, if it’s not handled in this plugin (which was the question) then yes, it has to happen with another plugin. 🙂 But yes, it has to happen, you can’t just have 1000+ dead links (not best practice).

@tigroumeow

So then the next question is, if in the process of using this plugin, XXXX images are chosen for deletion, is there a .csv / .xls available to export all the links of the images marked for deletion? If so, then we could figure something out. If there’s a way to get that list, that would be helpful so just want to know if that’s available.

Thanks.