WordPress.org

Make WordPress Core

Opened 14 months ago

Last modified 5 months ago

#50980 reviewing defect (bug)

Extra query to get WPLANG option on each page-load when the option doesn't exist in the db

Reported by: aristath Owned by: SergeyBiryukov
Milestone: Future Release Priority: normal
Severity: normal Version: 5.0
Component: I18N Keywords: has-patch
Focuses: performance Cc:

Description

On each page-load we call determine_locale() which in turn tries to get the WPLANG option using get_option.
When the site language is en_US and has never been changed, the WPLANG option doesn't exist in the options table in the database.
As a result, get_option doesn’t find it autoloaded and then triggers a query.

If the language is changed to something else and then back to en_US, the option is saved as an empty string and gets autoloaded.

Proposed solution:
The simplest solution that comes to mind (which also wouldn't interfere with the way multilingual plugins work) would be to check if the row exists in the table, and if not just create it and save as empty string. It can then get picked-up by the object-caches and spare us the extra query.

Change History (14)

#1 @SergeyBiryukov
14 months ago

  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to 5.6

This can be done in an upgrade routine like upgrade_550(), for example.

This ticket was mentioned in PR #476 on WordPress/wordpress-develop by aristath.


14 months ago

  • Keywords has-patch added; needs-patch removed

Adds a default value for WPLANG on new installations and introduces a new upgrade routine for WP 5.6.0.

Trac ticket: https://core.trac.wordpress.org/ticket/50980

#3 @SergeyBiryukov
14 months ago

  • Owner set to SergeyBiryukov
  • Status changed from new to reviewing

#4 @aristath
14 months ago

Just a note here: I noticed that all upgrade processes mention database-versions and that's how things get triggered.
I don't know how these get generated or what the db-version will be in order to add that in the patch, is there documentation somewhere about that?

This ticket was mentioned in Slack in #core by justinahinon. View the logs.


13 months ago

#6 @audrasjb
13 months ago

Just added a comment in the PR about a very small WPCS point

#7 @prbot
13 months ago

ocean90 commented on PR #476:

The current test failure is valid and needs to be investigated:

1) Tests_L10n_GetLocale::test_network_option_should_be_fallback_on_multisite
Failed asserting that two strings are identical.
--- Expected
+++ Actual
@@ @@
-'es_ES'
+'en_US'
/var/www/tests/phpunit/tests/l10n/getLocale.php:54

A similar upgrade routine was done in 4.0:
https://github.com/WordPress/wordpress-develop/blob/c7f5af72dcc4f36365656fdbfccfa0fb51fefd1f/src/wp-admin/includes/upgrade.php#L1921-L1933

#8 @prbot
13 months ago

aristath commented on PR #476:

Failing tests were fixed.
Tested on single-site and multisite installations :+1:

This ticket was mentioned in Slack in #core by hellofromtonya. View the logs.


11 months ago

#10 @SergeyBiryukov
11 months ago

  • Milestone changed from 5.6 to 5.7

It looks like the tests are still failing with the latest patch, so this needs some more work:
https://travis-ci.com/github/WordPress/wordpress-develop/jobs/386888985

With 5.6 RC in a few days, moving to the next release for now.

#11 @hellofromTonya
11 months ago

  • Version changed from trunk to 5.0

#12 @lukecarbis
8 months ago

  • Milestone changed from 5.7 to 5.8

With not much activity happening here and beta 3 now out for 5.7, I'm moving this to 5.8.

This ticket was mentioned in Slack in #core by chaion07. View the logs.


5 months ago

#14 @JeffPaul
5 months ago

  • Milestone changed from 5.8 to Future Release

Given no traction on resolving the failing tests since the 5.6 release cycle I'm going to punt this out of the 5.8 milestone to Future Release. If someone is able to update the linked PR to resolve those failures, then this ticket would be good to get added back to a numbered milestone.

Note: See TracTickets for help on using tickets.