Upgrade/Install: Label the en_US update offer with its own locale - #12824
Upgrade/Install: Label the en_US update offer with its own locale#12824jigneshbhavani wants to merge 1 commit into
Conversation
When a localized site is offered both a localized and an en_US core update, and the en_US offer advertises a partial build matching the installed version, the second condition in list_core_update() matches but only assigns a version string when that offer is the only one available. With more than one offer the value falls through to the default, which is built from get_locale() rather than from the offer's own locale. Both buttons then read "Update to version 7.2-de_DE" on a de_DE site, while the second one posts locale=en_US and would install the English package. Add the missing branch so the label names the package the offer installs, which is what the following condition already does for the non-partial case. Props bejignesh, o815. Fixes #65666.
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the Core Committers: Use this line as a base for the props when committing in SVN: To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
Test using WordPress PlaygroundThe changes in this pull request can previewed and tested using a WordPress Playground instance. WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser. Some things to be aware of
For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation. |
When a localized site is offered both a localized and an en_US core update, and the en_US offer advertises a partial build matching the installed version, both buttons end up with the same label while posting different locales.
The second condition in
list_core_update()matches for that offer, but only assigns a version string when it is the only update available:With more than one offer, nothing is assigned, so
$version_stringkeeps the default set earlier in the function, which is built fromget_locale()rather than from the offer's own locale. Because this is anelseifchain, the following condition that would have labelled it correctly is never reached.Reproduction
On a
de_DEsite, serving two offers, onede_DEand oneen_USwith a partial build matching the installed version:localede_DEen_USBoth buttons read the same, but the second posts
locale=en_USand would install the English package. With this change:localede_DEen_USThe added branch assigns the same string the following condition already uses for the non-partial case.
Testing
Update to version 7.2with no locale suffix.--group upgradepasses, 183 tests.--group adminpasses, 1016 tests, 0 failures. It reports 10 PHPUnit 10 deprecation warnings, which are identical on unmodified trunk.phpcsandphp -lclean.No unit test is included.
list_core_update()is defined inwp-admin/update-core.php, which runs page logic on include, so it cannot be exercised from PHPUnit without refactoring the function out of the page file. The reproduction above was done against the rendered admin screen.Trac ticket: https://core.trac.wordpress.org/ticket/65666
Use of AI Tools
AI assistance: Yes
Tool(s): Claude Code
Model(s): Claude Opus 5
Used for: Drafting the patch and this description. I reproduced the mislabelled buttons on the rendered update screen before and after the change, confirmed the single-offer case still renders without a locale suffix, ran the upgrade and admin groups and checked the admin warnings against a trunk baseline, ran phpcs and php -l, and I take responsibility for the result.