Docket CacheWhat Went Wrong In 26.04.10, And How 26.04.11 Fixed It
On 14 October 2026 we released Docket Cache 26.04.10, a security release. Soon after, some of you wrote on the support forum that your site showed a critical error after the update. We released 26.04.11 with a fix the next day. We are sorry for the trouble. This post explains what went wrong, in plain words.
If you are already on 26.04.11, you do not need to do anything.
What people saw#
Two reports on the support forum showed the problem clearly.
On a site with SEOPress PRO, the WordPress admin crashed after a few page loads with this error.
Uncaught Error: Attempt to assign property "translations" on string
wp-seopress-pro/inc/admin/updater/t15s-registry.php:101
On a WooCommerce site, every page crashed with this error.
Uncaught TypeError: array_filter(): Argument #1 ($array) must be of type array, string given
woocommerce/includes/wc-attribute-functions.php:79
The two errors look different, but they have the same cause. SEOPress PRO asked for the update_plugins transient and expected an object. WooCommerce asked for its list of product attributes, the wc_attribute_taxonomies transient, and expected an array. Both got a piece of text instead.
What a transient is#
A transient is a value that a plugin saves for a short time, such as the list of plugin updates or the result of a slow query. Without an object cache, WordPress keeps transients in the database. With an object cache, WordPress keeps them in the cache and stops reading them from the database.
That creates a gap. When you first turn on Docket Cache, or when an update replaces the drop-in file, the transients already in the database would be lost. So Docket Cache copies them from the database into its cache once, at the end of the first request. The Data Storage page explains this step in detail.
What went wrong#
In the database, WordPress keeps each transient as serialized text. For example, an object is saved as text that starts with O:8:"stdClass". When WordPress reads it back, it unserializes the text into the object again.
The copy step took this text from the database and put it into the cache as it was. That was always the case. It worked in older versions only because, up to 26.04.09, Docket Cache unserialized any text that looked like serialized data when it read it back. So the text turned back into an object, and nobody noticed.
In 26.04.10 we stopped doing that, for good reasons. Text that a plugin puts in the cache must come back as the same text. Our post Why Docket Cache No Longer Unserializes Strings explains why. But the copy step was the one place that relied on the old behaviour. So the copied transients came back as serialized text, and plugins that expected an object or an array crashed.
The update itself made the problem appear at once. Each new version replaces the drop-in file, so every site that updated to 26.04.10 ran the copy step straight away.
Why our tests did not catch it#
The problem only appears on a site that already has such transients in its database, and only when a plugin reads one of them and is strict about its type. A new test site does not have them, and many plugins rebuild a transient when it looks wrong instead of crashing.
The copy step was added in 2021, and the old behaviour had hidden its mistake ever since. When we removed the old behaviour, we did not check what else depended on it. That is the lesson we take from this release.
How 26.04.11 fixed it#
Docket Cache 26.04.11 changes the copy step so that it gives back what WordPress would give back.
- A transient that holds only arrays and plain objects (
stdClass) is unserialized when it is copied, and stored as native PHP. This is the fastest way to load it later. - A transient that holds any other kind of object is stored as text and unserialized when it is read. At the time of the copy, the plugin that owns that object may not be loaded yet.
- Docket Cache only unserializes data it copied from the database itself, never text that a plugin gave it. The security fix from 26.04.10 stays in place.
While we were fixing this, we found three older mistakes in the same code and fixed them too.
- Each transient has a value row and a timeout row in the database. If the timeout row came second, its number could replace the value.
- Some transients that had already expired were still copied into the cache.
- Every copied transient was kept for the longest time allowed, not for its own expiry time.
What you need to do#
Update Docket Cache to 26.04.11 or later, from the Plugins screen or from WordPress.org.
You do not need to clear the cache. Each cache file has a format version, and 26.04.11 uses a new one. When it reads a file written by 26.04.10, it deletes the file and builds the value again. The update also runs the copy step again, this time in the correct way.
If you went back to 26.04.08 to get your site working, please update now. 26.04.08 does not have the security fixes from 26.04.09 and 26.04.10.
If your site still shows a critical error and you cannot open the admin, delete the file wp-content/object-cache.php and the folder wp-content/cache/docket-cache by FTP or your hosting file manager. Your site then works without the object cache, and you can update Docket Cache from the Plugins screen.
Thank you#
Thank you to everyone who reported the problem on the support forum, with the error messages and the plugin versions. Those details helped us find the cause quickly. A special thank you to the SEOPress support team, who looked at the error on their side and pointed to the update_plugins transient.