Fixed: Database update fails when Backdrop is set to another language than English and the string "Apply pending updates" has a translation

[djzwerg]

Steps To Reproduce

1. Install an outdated Backdrop (old modules should also do the trick) with pending db/config updates
2. Add another language (e.g. German)
3. Make that language the default one, disable English
4. Translate "Apply pending updates" - anything that's different from the original string will do
5. Run updates

You'll end up with a white (empty) page in step "Run updates", but that's no WSOD - just a page with zero content.

---

Original report:

Description of the bug

When you're using Backdrop CMS with another language than Englisch and you're trying to update the database (core tables) you'll get a white screen. The log files are empty.

Steps To Reproduce

To reproduce the behavior:

1. Add another language (e.g. German)
2. Set your language to default
3. Disable English language
4. Update core
5. Run update.php

Actual behavior

You'll get a white screen. Enable English language and try again update.php works.

Add any other information that could help, such as:

• Backdrop CMS version: 1.19.3
• Web server and its version: Apache

[klonos]

I was not able to reproduce this @djzwerg. Here's what I've tried:

• vanilla Backdrop installation
• enabled all errors in /admin/config/development/logging
• enabled the Language module
• added German
• set German as default
• disabled English (not deleted - just disabled)
• added a new dummy update hook at the end of the /core/modules/system/system.install file, with the following (set the update hook number to whatever is the last one in your system +1):

    function system_update_1076() {
      dpm('update has been run');
    }

• headed to /admin/reports/status and started the db update process
• no errors or white screens:
  

[djzwerg]

I got this issue a few times on different setups but not every time a core updated was installed. I will try to reproduce it on a clean Backdrop site these days...

[findlabnet]

I have another scenario for a similar error:

• English is enabled, but not as default language, only for admin use;
• URL language detection is configured to use the "en" prefix for English and no prefix for another (default) language.
  The update link from admin side is built as domain.name/en/core/update.php, so the result is a 404 error.

[klonos]

Thanks @djzwerg ...if you can spot a common factor in your setups that might be causing this, then that would help. We can't fix things that we can't reproduce :)

@findlabnet what you are describing seems to be a known issue with Drupal as well: https://www.drupal.org/project/drupal/issues/2616164 (I found it during my research for the issue that @djzwerg reported here). I suspect that that might be a different problem than the one @djzwerg has reported here, so can you please create a separate issue for it? Thanks.

[djzwerg]

@findlabnet that's not the same issue. If you try using yourdomain.name/update.php it should work.

[findlabnet]

@djzwerg thanks, i know this workaround and didn't say it is the same error, just similar, sorry for my mistake.
@klonos sure, I will. Update: done, #5169

[indigoxela]

I also can't reproduce it (yet).

@djzwerg are the sites native Backdrop installs, or did you upgrade from D7? Which modules are installed?

[djzwerg]

@indigoxela these are native Backdrop installs. On the sites are different modules and themes installed.

[indigoxela]

On the sites are different modules and themes installed.

I guess, we need to figure out, what these sites share. Are the modules completely different, or is there some overlap? Are the sites on different hosting, or do problems appear on the same hosting?

The first thing that always comes to my mind when it's about WSOD: PHP memory limit (memory_limit). Which limits are reported on /admin/reports/status on affected sites?

[olafgrabienski]

I guess, we need to figure out, what these sites share.

Today I was able to reproduce the issue: I installed a site from @djzwerg on my shared hosting and got a white screen when I tried to run database updates. The issue persisted after disabling all contrib modules and contrib themes. I was only able to run the database updates after enabling English and setting it as default language. No errors in DBlog, btw.

[indigoxela]

Same here. I could drill the problem down to the relatively large locales_source and locales_target database tables (both ~4MB).

Two ways worked to complete the pending updates:

1. run bee updb
2. truncate both db tables and re-imported the translations (the tables went down to less than 1MB)

But... as new modules get added to sites, the tables will grow again and at some point updating will fail again. It's not completely clear to me if it's really a WSOD - no 5xx in the logs. But there is a problem other people could run into as well. The more modules and the more time has passed (updated strings and translations), the bigger the tables get.

Other things I tried that did not help: larger memory_limit and other values in php.ini.

[jayelless]

Is this the same as issue #5092? In that case one link would work but the other would fail.

[indigoxela]

Is this the same as issue #5092?

No, definitely not the same. In the other issue the link points to 404, in this issue the link is OK, but the database update ends up with an empty (white) page and the update won't run at all, if the translation tables are too big.

[indigoxela]

FTR: this issue needs more recherche. It's not clear to me, why the batch job for database (and config) updates gets stuck in a white page (note: not a 5xx) in step "Run updates". According to the apache logs nothing happens after the (successful) POST.
And in the browser there's only a completely empty page with the url /core/update.php?op=selection&token=THE_RIGHT_TOKEN....

Note: the updates themselves are harmless, they complete in less than a second if either run:

• via bee updb
• on English language
• after truncating both large locale tables and flushing caches

[indigoxela]

And another remark: the size of tables locales_source and locales_target from the demo web are big, but I have D7 sites that have a lot more records in both tables and I never experienced any problems with that. It seems to be specific to Backdrop.

[indigoxela]

UPDATE forget my previous assumptions, the actual problem is a translation for "Apply pending updates".

// debug() output
array (
  'op' => 'Ausstehende Aktualisierungen durchführen',
  ...
)

In update.php the form submit button has a translated value:

https://github.com/backdrop/backdrop/blob/1.x/core/update.php#L162

But later on the check is against the untranslated string:

https://github.com/backdrop/backdrop/blob/b8dca2c551b95c93a33c4b43e00be575c1491f51/core/update.php#L547

Which means that the requested operation and proper batch id can not be determined. The batch has not started yet, so $_REQUEST['id'] isn't set yet, and in function _batch_page() we end up with a return FALSE - which explains the empty page.
https://github.com/backdrop/backdrop/blob/b8dca2c551b95c93a33c4b43e00be575c1491f51/core/includes/batch.inc#L43

I'm not sure how to solve that. For sure the update is by design a little simpler (using $_REQUEST instead of $form_state['triggering_element']...), because at that point some parts of Backdrop may not be fully available.
On the other hand, IMO it's bad practice to bind form actions to translated strings - correct me if I'm wrong.
Should we:

• Use the translated string also in the case statement?
• Try to hand the actual operation in a cleaner way? How?

I'll update the STR.

[oadaeh]

Should we:
* Use the translated string also in the case statement?

Yes, that should be done. If the string is initially translated and then used elsewhere for any purpose like comparing against values, it should use the translated string.
So the line should read: case t('Apply pending updates'):

[indigoxela]

If the string is initially translated and then used elsewhere for any purpose like comparing against values, it should use the translated string

Many thanks for your hint - nice, this makes it a one-liner fix.

[klonos]

Thanks @indigoxela for all the troubleshooting, research, and for figuring out what the culprit is and filing a PR 👍🏼 ❤️

@djzwerg can you please apply the change from https://github.com/backdrop/backdrop/pull/3701/files (wrap the string in t()) on your test environment/server, and report back if it fixes the problem? Thanks

[djzwerg]

Patch applied - I can confirm that this solves this issue. Thanks a lot for your time and work!

[indigoxela]

Assuming that @djzwerg has no permission here to set labels, I'm updating to "works for me".

[laryn]

Thanks @djzwerg for filing the issue and testing the fix. Thanks @indigoxela and @oadaeh for the fix! And thanks for testing/reviewing @klonos and @olafgrabienski. I've merged backdrop/backdrop#3701 into 1.x and 1.19.x.

@djzwerg I've also invited you to the "Documentation and Organization" team which will give you access to set labels.