Seagull87

Is the latest version 2.42.0? I’m not seeing it available for download.

Thanks for that confirmation, just wanted to be sure.

We’ve had the facebook spider blocked via useragent for over a week now and they are still constantly requesting the calendar with the id= query string. I assume things won’t calm down until facebook have exhausted all the links they’ve already gathered. Hopefully they shouldn’t be picking up any more new links now thanks to the last update.

This is happening us as well.

Does anyone have a solution?

/calendar/?id=1438129239&ajaxCalendar=1&mo=5&yr=2024

The id is changing every time on GET requests, which is causing the bots to get caught in a loop. The bots can’t tell they shouldn’t be following that link

Would blocking GET requests to that URL work? I believe when used as intended they are supposed to be ajax POST requests.

• This reply was modified 9 months ago by Seagull87.

Sorry I am not an expert in this and haven’t tested that but in theory that makes sense that it could solve the problem. I don’t know what the risks of doing that to your data are though.

I just wanted to point out to wordpress that some form of error logging to indicate there was an issue would be useful.

For me just deleting the Copy Delete Posts plugin worked. If that didn’t fix your problem perhaps another plugin it also causing you an issue. Deleting the transient fields won’t help as they get recreated.

The error was happening when checking for plugin updates.

All installed plugins (active or not) are checked for updates when this page is called: /wp-admin/update-core.php.

So once our “problem” plugin was deleted and it wasn’t being checked for an update, the rest of the updates showed fine.

So deleting plugins and installing them again one by one should help you workout which plugin was the issue.

The error seems to be hidden by wordpress unfortunately so it’s hard to track down, that’s why I started the new thread.

Also 10.6.17-MariaDB-cll-lve and php 8.1

Sorry I wasn’t clearer. The issue we had wasn’t installing the plugin new, it was updating the plugin from I think version 1.4.3.

When wordpress checks for updates it populates this field (_site_transient_update_plugins) with json. The json is made up of text from each plugin that needs updated. The copy-delete-posts plugin had some emojis in their text causing that field not to be populated. So then wordpress never knows any plugins need updated.

As a basic test can you paste this into your utf8mb3_general_ci options table: “<span style=”font-family: Inter, sans-serif; white-space: pretty;”>Just try it out! You’ll love it </span>??”

If you don’t get an error like we do then yes it’s something to do with our DB setup but regardless it’s causing wordpress to unexpectedly not update that field without notification.

It would be happening in this function wp-includes\update.php function wp_update_plugins

Just to be clear it’s not an issue for us in general now we know what’s happening. I thought it might be a useful wordpress improvement.

It was this plugin https://www.ads-software.com/plugins/copy-delete-posts/ but I don’t think it’s an issue with the plugin. Just a hidden error in wordpress to do with the collation of our options table.

Yes there was nothing in the error logs.

Just thought it was something wordpress could have reported an error about.

This error happens when you paste the update json into the _site_transient_update_plugins field in phpmyadmin:

#1366 Incorrect string value:

‘\xF0\x9F\x92\x9A (…’ for column….

If anyone finds this helpful, we found a solution. For us it turned out to be a collation issue with the options table. An plugin of ours had non standard characters in it’s update text and our DB couldn’t handle them.

Disabling the plugins is not enough of a test in this scenario as even disabled plugins try to get updates. Deleting them and adding them back one by one is a better test.

Further info:

https://www.ads-software.com/support/topic/db-not-updating-issue-but-no-error-reporting/

We are having the same problem. It’s been going on for about 8 months. Core will update fine but plugins say they are updated when they are not. Disabling all plugins doesn’t fix it.

Like tux1 we also have yoast and wordfence.

Has anyone found a cause/solution to this?

I had the same warning come up.
This link for the issue works:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-23983

Thanks for your help. I’m going to look into the litespeed crawler or reducing our TTL way down.

Sorry I should clarify as few things.
As we have so many sites, we have no reliable way to know which pages have a contact form. So excluding all the contact form pages from being cached via url isn’t an option.

I had been wondering if submitting a contact form already automatically triggered a purge. I tested it there myself and it does, which would explain why the problem doesn’t come up very often.

wpforms_process_complete hook is a good option thanks, I’ll probably try it with wpforms_frontend_output_before though as a purge seems to happen on successful contact forms anyway.