Cleanup doesn't work on my website

[Andrea-C]

Hi Aaron

What Version I'm Using

404 Solution Version 2.28.1 WordPress: 6.0 PHP: 7.4.30 PHP time limit and max input time = 120 PHP Memory limit = 768M Hosting: Siteground shared Active plugins: 404 Solution | Versione 2.28.1 di Aaron J\ Complianz | GDPR/CCPA Cookie Consent | Versione 6.2.4 di Really Simple Plugins GA Google Analytics | Versione 20220517 di Jeff Starr Oxygen | Versione 4.0.1 di Soflyy Wordfence Security | Versione 7.5.11 di Wordfence WP Mautic | Versione 2.4.2 di Mautic community Yoast SEO | Versione 19.2 di Team Yoast

What I Expected To Happen

Log size is limited by config parameter

What Happened Instead

As you can see from the attached image taken in WordPress->Settings->404 Solution->Options The Maximum log disk usage was (is?) set to MB 100 but the current size is 242 MB (and 731.577 records) as reported in the following line in Options page. If I check directly in the MySQL Database, I get the same values

I think because of this big log table, may be also limited by the shared hosting constraints, 404 solution doesn't work properly:

• I get an empty page when I open WordPress->Settings->404 Solution->Captured 404 URLs (see image)
• Most of the time the Options page stops loading after the "Automatic Redirects" section (now I don't how I could get it load entirely and get the full page to check the "Maximum log disk usage" parameter (see image)
• If I click the "Run Maintenance" button in Tools page, the page start loading for more or less 60 seconds and then I get an empty page with only the WordPress Admin sidebar

Question: Can you suggest me the SQL Command to delete most of the 404 entries in the right way?

I would say something like: _DELETE FROM abj404logsv2 WHERE timestamp < '2022-06-01' _but I do not know if I should first delete related records in other tables, like abj404redirects

Steps to Reproduce the Bug

Don't know. May be leave 404 Solution unmanaged for 2 year like I did

Debug Lines or Stack Trace

[aaron13100]

Can you go to the tools page and scroll down and click "run maintenance?"

--

Can you view the debug file? It's at a location like /.../htdocs/404solution-site/wp-content/uploads/temp_abj404_solution/abj404_debug.txt

It should have some error messages in there, I assume. If so please paste them here (but if it's more than a page then use pastebin.com).

--

You can delete the logs with sql with a command like delete FROM mywp_abj404_logsv2 or truncate table mywp_abj404_logsv2

DELETE FROM abj404_logsv2 WHERE timestamp < '2022-06-01' might work fine but timestamp seems to be stored as a number not a date so I dunno.

I do not know if I should first delete related records in other tables, like abj404_redirects

There's no need to delete things from other tables.

[Andrea-C]

Hi Aaron

This is the fastest response to an issue I never had: 5 stars

As mentioned before, if I click "Run Maintenance" the script/page/function run for nearly 60 seconds and then I get an empty page with only the WordPress Admin sidebar.

The debug file si 20 MB. Attached here as zip, after renaming reference to my website abj404_debug-mywebsite.zip May be you can find error message in the past, when the issue origin, but I cannot see errors of today activity when I tried to shrink the log.

Before I truncate the log table, let me know if you need more testing to permit you understand whats going on. From my side, I think the info for table truncation are enough

Thank you Andrea

[Andrea-C]

I did the "run maintenance" 4 times, checking on the database if the table was decreasing the number of records every run. But it always ended with a blank page (server timeout?) without removing any record.

[aaron13100]

Maybe it's unrelated but there is an issue in the log file about continuous redirecting and a user-agent with "DataForSeoBot/1.0; +https://dataforseo.com/dataforseo-bot" in it. I'm not sure when I can get to this. It needs a code change to remove redundant url parameters...

[Andrea-C]

Thank you Aaron. For me, you can close my issue. If you need more debug, let me know. Ciao Andrea

[Andrea-C]

The log was filled by a recursive redirect in Options --> Automatic Redirects we had the following setting Redirect all unhandled 404s to: [OLD HOME PAGE]

The [OLD HOME PAGE] is an exiting page in our web site but has been set as "DRAFT" after publishing the [NEW HOME PAGE] In this way 404 solution was redirecting every 404 to another non existent page (actually a draft page, but for the public it's a non existent page) that cause another nested redirect. And so on for many times. I suggest to add a control to 404 Solution: if the destination page of "Redirect all unhandled 404s to:" is set to a non existent or draft page, do not redirect and instead fire an allarm

Ciao Andrea

[aaron13100]

Thanks for the extra info. I'll consider what I can do.

[aaron13100]

Thanks a lot for letting me know exactly how to reproduce the issue. I fixed it in the laziest way possible in the latest version. If you have other issues just let me know.

[Andrea-C]

You're welcome Aaron. Glad to have been useful. The least a user of open source software can do is to help the developer improve it.