Opened 3 months ago
Last modified 12 days ago
#63906 new defect (bug)
Review and improve reliability of language pack upgrades
| Reported by: |
|
Owned by: | |
|---|---|---|---|
| Milestone: | Awaiting Review | Priority: | normal |
| Severity: | normal | Version: | |
| Component: | Upgrade/Install | Keywords: | |
| Focuses: | administration | Cc: |
Description
In a WooCommerce GitHub issue we were investigating user reports about missing translations after upgrading the WooCommerce plugin to a new version. And we tracked it down to unreliability of language pack upgrades for the plugin.
When you upgrade WooCommerce from version 10.0.4 to 10.1.0, the new version 10.1.0 is not fully compatible with the language pack for 10.0.4. Some translations will be missing. Even if they are not new: for client-side JSON translation files, a translation can move from one JSON file to another, and then load_script_textdomain will fail to load the matching JSON file for a given JS script if the language pack is not up to date.
A plugin upgrade (at least manual one in WP Admin) should trigger also language pack upgrade (it's the LanguagePackUpgrader::async_upgrade method hooked to upgrader_process_complete) but apparently failed language pack upgrade doesn't affect the result of the plugin upgrade. It's reported as success even if languages failed to update.
We've seen cases where after a successful plugin upgrade the language pack is not updated at all (there are only old files) and the site is therefore in a broken state (wrong language in parts of frontend).
We've also seen a case where wp-content/languages/plugins/woocommerce contained files from both old and new language packs. That doesn't break the site, but it's still something that shouldn't happen: the language pack upgrader is supposed to clear the destination directory before moving the new files there. This is another sign that something is unreliable.
Looking at the code confirms that errors from LanguagePackUpgrader are generally ignored. Wherever we call the upgrader's upgrade_bulk method, we ignore the return value:
- in
update-core.phphandling thedo-translation-upgradeform action - in the
async_upgrademethod hooked to be done after a plugin upgrade - in the REST handler for
POST /wp/v2/pluginsafter a plugin install/upgrade
Compared to that, when calling upgrade_bulk on a Plugin_Upgrader or Theme_Upgrader the results are handled and reported.
Change History (4)
#2
@
13 days ago
- Version trunk deleted
I checked the original report on woocpmmerce repo, and the video attached there shows that the WordPress version is 6.8.2, so this is not an issue that occurs in the unreleased trunk branch at least.
#3
@
13 days ago
Is this a new issue for the current unreleased version (trunk)?
Looking at the code and its history, this bug has been there for 12+ years, since language pack upgrader was first implemented. It's not new at all. It's simply that errors during language pack download and upgrade have been always ignored.
We can set the version to "3.8" if it's helpful. Or make it blank, because the particular version is not really relevant here.
@jsnajdr Is this a new issue for the current unreleased version (trunk)? If we don't know the version, perhaps we can set the version blank.