NerdPress

Hi @wppraesenz,

Thanks for being a longtime user of ODADR! 😊

Self-hosted analytics tools like Matomo have to store a lot of data, and there are other factors that impact performance besides sheer size of a table. It sounds like these tables may be either too big, or perhaps too complicated in some other way, for your server to be able to rebuild/optimize them.

I don’t know if Matomo allows this, but perhaps you could retain less data? For example, maybe keep 90 days instead of a year? But you’d need to contact them for more specific help with this, since our plugin just tells the server to run the optimization — and fixing issues with a specific table would be outside our scope or ability. You can open a support thread with them here: https://ww.wp.xz.cn/support/plugin/matomo/

In the meantime, as a workaround you could exclude those tables from optimization, so you can optimize all your other InnoDB tables if need be.

In Settings > Optimize Database > Exclude Database Tables from Optimization, you can check the box next to each Matomo table to ignore. We checked the Matomo plugin’s code, and here’s a list of all the tables it uses:

(replace wp_ with your table prefix)

wp_access
wp_archive_blob
wp_archive_invalidations
wp_archive_numeric
wp_brute_force_log
wp_changes
wp_goal
wp_locks
wp_log_action
wp_log_conversion
wp_log_conversion_item
wp_log_link_visit_action
wp_log_profiling
wp_log_visit
wp_logger_message
wp_option
wp_plugin_setting
wp_sequence
wp_session
wp_site
wp_site_setting
wp_site_url
wp_tracking_failure
wp_twofactor_recovery_code
wp_user
wp_user_token_auth

Since troubleshooting these tables is outside our scope and better-suited for Matomo to assist, I’m going to mark this as resolved…but I hope this helped point you in the right direction, or at least gave you a workaround!

Best,
Andrew

Hi @ljmac,

We just released version 5.3.0 which should resolve the issue you saw on PHP 5.6.

(That version of PHP reached end of life way back in 2018! In a future version we plan to increase the minimum required version of PHP — so hopefully you’ll be able to upgrade soon. But for now you should be back in business! 😄)

Best,
Andrew

Hi Mary,

Sorry to hear you’ve run into this issue. I’m not sure why there are no revisions saved, since it could be due to quite a few different factors. Nevertheless, it does sound like the best thing to do is to restore an older backup (if you have it) to a staging environment, and then manually copy the missing content back to the post.

Is https://drillhall.historic-sidmouth.uk/ the site? It looks like it’s hosted by IONOS, so I recommend you ask them for help creating a staging environment; better yet would be to ask them to restore an old backup as well.

Once you get the backup accessible on staging, since it’s a Classic Editor post, the easiest way to restore is to switch to “Text” mode, and then copy/paste the content from staging to the same post on the live site.

(If the images themselves are still on the live site, you may not need to restore images from a backup; just the database will suffice, since in that case you’d only need the code from the post content itself.)

Also, if you have a copy of the database in SQL format (or zipped or gzipped, in which case un-zipping should get you the SQL file), you can also open that in a text editor and search for the post. The formatting is a little challenging, but the content of the post itself should be visible there, so you could copy/paste it directly from the SQL file. (Once you have the SQL file open in a text editor, do a search for the post title, which should help you locate it more easily.)

Another option would be to check the Internet Archive to see if they have stored a copy of the page:

https://web.archive.org/web/20240701000000*/https://drillhall.historic-sidmouth.uk/

Hope that helps! I’m going to mark this thread as “resolved” since it’s outside the scope of our plugin, specifically, but if you are still stuck please do reply and I’ll be happy to jump back in.

Best,
Andrew

Awesome, thanks! Much appreciated. 😊

Hi @kkk07,

I was just able to reproduce the issue on my staging site. WordPress will return a 200 response and the default “Nothing Found” message if the tag itself still exists but there are no posts with the tag.

Screenshot: https://share.nrdp.rs/eDuZXPop

To double-check: Have you fully deleted the tag itself from Posts > Tags? Or did you only remove the tag from any post(s) that had the tag assigned to them?

Sorry, I just realized you shared the exact URLs above (it’s early here and I need more coffee!). ☕

Curiously, the URL showing the default error page:
https://steadyincomeinvestments.com/tag/early-stage-trader-fraud/

Is responding with a 200 (OK) status code — not a 404 or 410.

If I got to another URL with /tag/ in it, but for a tag that never existed, it also works correctly, returning your custom page, and a 410 response:
https://steadyincomeinvestments.com/tag/this-tag-never-existed/

So this does point back to something conflicting specifically on this URL, and specifically because it was a tag that existed and was later deleted. Very curious to see what you find in the SEOPress and Redirection settings!

Hi @kkk07 ,

I just deleted my test-tag archive, reloaded the /tag/test-tag/ page and it worked correctly for me. (So, deleting a tag isn’t the issue.)

Perhaps it’s a caching issue. This could be the case if you installed the plugin after initially seeing the default 404 page on that URL. Have you cleared all caches?

Or maybe another plugin is conflicting. Could you please share your list of plugins? You can get that from Tools > Site Health > Info > Active Plugins.

And, what Theme is your site using?

Thanks,
Andrew