_site_transient_update_themes not cleared after successful translation update

[psmits1567]

Version: 7.0
Component: Upgrade/Install
Description: After updating theme translations, the translations array in _site_transient_update_themes is not cleared, causing the same update to reappear indefinitely. Deleting the transient manually resolves it temporarily.
This is also happening for plugins!
Solution temporarely clearing this record, then perform update again and refresh the screen
DELETE FROM psmitsoptions
WHERE option_name = '_site_transient_update_themes';

[yasirkhalifa]

Fixed: _site_transient_update_themes not cleared after successful translation update

[yasirkhalifa]

Attached a patch that clears the relevant update transients after successful translation updates.

The patch tracks the translation types processed during Language_Pack_Upgrader::bulk_upgrade() and deletes the corresponding update transient (update_themes, update_plugins, or update_core) when clear_update_cache is disabled.

This prevents stale update data from persisting after translation updates and resolves the issue where completed translation updates may continue to be offered.

Testing:

• Reproduced the issue with a theme translation update.
• Confirmed that the update_themes transient is cleared after a successful translation update.
• Confirmed that the translation update is no longer repeatedly offered.

[josklever]

I reported this to the nl_NL polyglots team to see if others were having this issue and we did a lot of debugging already, so Peter decided to create this ticket.

After updating the translations, you go back to Dashboard - Updates and they are available again. They are installed correctly

Deleting the _site_transient_update_themes option didn't work at first and it was recreated again with the same content (only a bit more recent timestamp):

O:8:"stdClass":5:{s:12:"last_checked";i:1780753484;s:7:"checked";a:2:{s:5:"astra";s:6:"4.13.4";s:15:"twentytwentyone";s:3:"2.8";}s:8:"response";a:0:{}s:9:"no_update";a:2:{s:5:"astra";a:6:{s:5:"theme";s:5:"astra";s:11:"new_version";s:6:"4.13.4";s:3:"url";s:35:"https://wordpress.org/themes/astra/";s:7:"package";s:54:"https://downloads.wordpress.org/theme/astra.4.13.4.zip";s:8:"requires";s:3:"5.3";s:12:"requires_php";s:3:"5.3";}s:15:"twentytwentyone";a:6:{s:5:"theme";s:15:"twentytwentyone";s:11:"new_version";s:3:"2.8";s:3:"url";s:45:"https://wordpress.org/themes/twentytwentyone/";s:7:"package";s:61:"https://downloads.wordpress.org/theme/twentytwentyone.2.8.zip";s:8:"requires";s:3:"5.3";s:12:"requires_php";s:3:"5.6";}}s:12:"translations";a:1:{i:0;a:7:{s:4:"type";s:5:"theme";s:4:"slug";s:5:"astra";s:8:"language";s:5:"nl_NL";s:7:"version";s:6:"4.13.4";s:7:"updated";s:19:"2026-06-02 19:58:35";s:7:"package";s:72:"https://downloads.wordpress.org/translation/theme/astra/4.13.4/nl_NL.zip";s:10:"autoupdate";b:1;}}}

After deleting both _site_transient_update_themes and _site_transient_update_plugins I tried again and now it was working for Astra, but not for Essential Addons for Elementor, so it's only working partially and we're not sure if it's permanent.

The _site_transient_update_themes value changed to:

O:8:"stdClass":5:{s:12:"last_checked";i:1780759653;s:7:"checked";a:2:{s:5:"astra";s:6:"4.13.4";s:15:"twentytwentyone";s:3:"2.8";}s:8:"response";a:0:{}s:9:"no_update";a:2:{s:5:"astra";a:6:{s:5:"theme";s:5:"astra";s:11:"new_version";s:6:"4.13.4";s:3:"url";s:35:"https://wordpress.org/themes/astra/";s:7:"package";s:54:"https://downloads.wordpress.org/theme/astra.4.13.4.zip";s:8:"requires";s:3:"5.3";s:12:"requires_php";s:3:"5.3";}s:15:"twentytwentyone";a:6:{s:5:"theme";s:15:"twentytwentyone";s:11:"new_version";s:3:"2.8";s:3:"url";s:45:"https://wordpress.org/themes/twentytwentyone/";s:7:"package";s:61:"https://downloads.wordpress.org/theme/twentytwentyone.2.8.zip";s:8:"requires";s:3:"5.3";s:12:"requires_php";s:3:"5.6";}}s:12:"translations";a:0:{}}

I'm seeing this issue on about 50+ sites out of the 324 sites I manage. Various hosts/servers, various combinations of plugins/themes, but it's all sites using Astra, all sites using WPCode Lite, all sites using Essential Addons for Elementor, all sites using SEOPress, etc. Some sites might have 1 of these items, some have more, there's no real overlap we can find. Many translation updates are still working fine.

All the translations are nl_NL, but that's because most of my sites are. I don't know if it happens to other languages.

PHP is 8.4 on most sites, there are no errors during updates on screen, in the browser console or in the PHP error log. There's no caching involved.

I'm not sure if the supplied patch is correct, because it sounds like the transients are removed, while they are there for a reason.

[psmits1567]

Removing the record was a solution to fix it immediately. Tested with Astra and reproduced. After removing the record and forcing an update the problem was gone. Of course this is just to help identifying the problem. I do not know the normal behavior of the update process. But in my opinion this record is no longer necessary after an update, because there are no more details to fetch until the author updates the project, which causes recreating this record. As not all projects have this problem, I suspect that this might also be a problem within the project update mechanisme. E.g. Astra must also check its update function

[knutsp]

Can confirm this happens on at least some of my sites, by inspecting an unusually large and growing number of transients. Still investigating.

[eskapism]

Confirming on another project/locale: Simple History (plugin), es_ES. Reproduces with the plugin deactivated, so it seems to be purely core + the api.wordpress.org response.

For this one, deleting the transient doesn't help — the offer is regenerated on the next wp_update_plugins(), which matches the Astra-fixed-but-not-Essential-Addons report. My guess is it comes down to a mismatch between the updated the translations API advertises and the PO-Revision-Date inside the package it links to. Compare a broken locale (es_ES) with a working one (sv_SE):

# es_ES — broken (advertised newer than shipped content → loops):
curl -s 'https://api.wordpress.org/translations/plugins/1.0/?slug=simple-history&version=5.29.0' \
  | jq -r '.translations[] | select(.language=="es_ES") | .updated'
# => 2026-06-02 16:09:04
curl -s 'https://downloads.wordpress.org/translation/plugin/simple-history/5.29.0/es_ES.zip' \
  | bsdtar -xOf - '*.po' | grep -a 'PO-Revision-Date'
# => PO-Revision-Date: 2026-02-16 10:30:56+0000   ← older than advertised

# sv_SE — ok (advertised == shipped → installs once, never re-offered):
#   advertised .updated         = 2026-03-11 06:53:13
#   package PO-Revision-Date     = 2026-03-11 06:53:13   ← identical

Where advertised == PO-Revision-Date the update seems to reconcile and stop; where advertised stays ahead of the shipped content it doesn't. Only es_ES is affected for this plugin — all 19 other locales match like sv_SE above.

[josklever]

@eskapism This is exactly what I suspected, but I didn't know how this worked yet. So we need to figure out why these dates don't match.

The only "workaround" that's actually working is not executed on every website, but by creating a newer translation update for that locale, because it will create new dates. The sites aren't broken, it's something in the update mechanism that's causing this.

[threadi]

I'm currently having exactly the same problem with Permalink Manager Lite and nl_NL. Here, too, the dates provided by wordpress.org are different:

curl -s 'https://api.wordpress.org/translations/plugins/1.0/?slug=permalink-manager&version=2.5.3.4' | jq -r '.translations[] | select(.language=="nl_NL") | .updated'
=> 2026-06-04 11:30:49

curl -s 'https://downloads.wordpress.org/translation/plugin/permalink-manager/2.5.3.4/2.5.3.4.zip' | bsdtar -xOf - '*.po' | grep -a 'PO-Revision-Date'
=> 2026-05-06 20:41:49

By the way, this is happening to me with WordPress 6.9.4. I don't think a bug in the core is the cause here—it's more likely related to how the files are generated on wordpress.org.