Make WordPress Core

Opened 8 weeks ago

Closed 6 weeks ago

Last modified 6 weeks ago

#61260 closed defect (bug) (fixed)

Rollback Auto-update: Automatic update of translations can cause confusion

Reported by: benniledl's profile benniledl Owned by: costdev's profile costdev
Milestone: 6.6 Priority: normal
Severity: normal Version: 6.6
Component: Upgrade/Install Keywords: has-patch has-testing-info commit
Focuses: Cc:

Description

Hey!
What I think could be confusing is, when the installation of wordpress is complete and you want to log in for the first time. If there happens to be updates to translations then instead of being logged in you will get the message that the installation is in maintenance mode.
This could really confuse beginners. I know maintenance mode will be turned off in a few seconds but we know users are not patient.

Steps to reproduce:
After the installation (german locale) finished, I immediately went to the login screen and entered my credentials. However, the post request that sent my login information returned a maintenance screen. This was because the automatic update feature was downloading new translations and put the site into maintenance.

Change History (11)

#1 @costdev
8 weeks ago

  • Keywords needs-patch added; dev-feedback removed
  • Milestone changed from Awaiting Review to 6.6
  • Owner set to costdev
  • Status changed from new to assigned
  • Version set to trunk

Hi @benniledl, thanks for reporting this!

We (myself and Benni) spoke about this in Slack, and a preliminary test shows that if we skip the maintenance mode calls added in [58128] when the upgrade $type is 'translation', this seems to remove the confusion.

I'll push a patch up for review and testing as soon I can.

Moving to the 6.6 milestone and pinging @afragen and @johnbillion for awareness.

Last edited 8 weeks ago by costdev (previous) (diff)

This ticket was mentioned in PR #6629 on WordPress/wordpress-develop by @costdev.


8 weeks ago
#2

  • Keywords has-patch added; needs-patch removed

@afragen commented on PR #6629:


8 weeks ago
#3

If we caught all the turn on points for maintenance mode, then this looks like it should work to keep maintenance mode from being on during translations.

#4 @costdev
8 weeks ago

  • Keywords needs-testing has-testing-info added

@benniledl I've added PR 6629.

Can you give it a test and leave a Test Report with your results please? 🙂 You can use the Test Reports plugin to get the environment information without having to check everything yourself.

#5 @costdev
8 weeks ago

  • Summary changed from Automatic update of translations can cause confusion to Rollback Auto-update: Automatic update of translations can cause confusion
  • Type changed from enhancement to defect (bug)

Adjusting the title so folks know that this is related to the Rollback Auto-update feature project that has been committed for 6.6.

Also changing this to a defect (bug) ticket as I think that's more appropriate given that the issue is more than an inconvenience.

Note: This ticket should ideally be tested and landed before Beta 1 to avoid the issue occurring during release party testing.

@rajinsharwar commented on PR #6629:


8 weeks ago
#6

This does look good, but I am curious if we really need the check while setting the maintenance mode to true. I mean, we should only check if the $type is 'translations', and only set the maintenance mode to false if it is not. But while setting maintenance_mode( true ), do we need that check @costdev?

@costdev commented on PR #6629:


8 weeks ago
#7

@Rajinsharwar We need to skip translations for both.

When setting maintenance mode to true, this creates a .maintenance file that puts the site into maintenance mode. This should not be done for translation updates in these locations. This is specifically what causes the reported issue.

When setting maintenance mode to false, this attempts to delete a .maintenance file, which won't exist. While this isn't an issue in itself, it means that filesystem operations will be attempted unnecessarily, and the ::feedback() method of the upgrader will also run unnecessarily. While this is not specifically what causes the reported issue, if we are skipping enabling maintenance mode for translation updates, for consistency and limiting attempted filesystem operations, we should skip disabling maintenance mode for translations as well.

#8 @benniledl
7 weeks ago

Test Report

Description

This report validates whether the indicated patch works as expected.

Patch tested: Upgrade/Install: Don't toggle maintenance mode for translation updates. #6629

Environment

  • WordPress: 6.6-alpha-58261
  • PHP: 8.0.30
  • Server: Apache
  • Database: mysqli (Server: 8.0.37 / Client: mysqlnd 8.0.30)
  • Browser: Firefox 126.0
  • OS: Windows 10/11
  • Theme: Twenty Twenty-Four 1.1
  • MU Plugins: None activated
  • Plugins: None activated

Actual Results

  1. ✅ Issue resolved with patch.

Additional Notes

  • I was able to log in for the first time and not get a maintenance screen

#9 @costdev
6 weeks ago

  • Keywords commit added; needs-testing removed

PR 6629 has been reviewed by another component maintainer, and has been tested and confirmed to resolve the issue by the original reporter.

Marking for commit and this must be committed before 6.6 Beta 1 tomorrow. I'll handle this as soon as possible.

#10 @costdev
6 weeks ago

  • Resolution set to fixed
  • Status changed from assigned to closed

In 58308:

Upgrade/Install: Don't toggle maintenance mode on translation updates.

The Rollback Auto-Update feature introduced additional maintenance mode toggling.

After installing WordPress in a non-English (US) language, translation updates are performed automatically. As there may be a large number of updates for Core and bundled themes, users will be presented with a maintenance notice upon visiting the newly installed website.

To avoid concerning users that the website has failed to install correctly, this excludes translation updates from triggering the additional maintenance mode toggling.

Follow-up to [58128].

Props benniledl, afragen, rajinsharwar, costdev.
Fixes #61260. See #58281.

@costdev commented on PR #6629:


6 weeks ago
#11

Committed in r58308.

Note: See TracTickets for help on using tickets.