WordPress.org

Make WordPress Core

Opened 10 months ago

Closed 10 months ago

Last modified 10 months ago

#45668 closed defect (bug) (fixed)

The (new) determine_locale() may throw a notice

Reported by: azaozz Owned by: SergeyBiryukov
Milestone: 5.0.2 Priority: normal
Severity: normal Version: 5.0
Component: I18N Keywords: has-patch fixed-5.0
Focuses: Cc:
PR Number:

Description

Happens then there is a plugin in /mu-plugins that loads a textdomain and $_GET['wp_lang'] is not empty, like when trying to log in.

Caused by the global $pagenow. It is set after mu-plugins are loaded (in vars.php) but determine_locale() expects is to always be set.

Attachments (1)

45668.diff (521 bytes) - added by swissspidy 10 months ago.

Download all attachments as: .zip

Change History (7)

#1 @azaozz
10 months ago

Introduced in [43776]. An ! empty( $GLOBALS['pagenow'] ) check would probably fix it.

Setting to 5.0.2 as a notice would break any JS output.

@swissspidy
10 months ago

#2 @swissspidy
10 months ago

  • Component changed from Administration to I18N
  • Keywords has-patch added

#3 @pento
10 months ago

In 44284:

i18n: Prevent a PHP warning when a mu-plugin loads a textdomain.

determine_locale() accesses the $pagenow global, but this is set after mu-plugins are loaded, so we need to check that it's been set.

Props swissspidy, azaozz.
See #45668.

#4 @pento
10 months ago

  • Keywords fixed-5.0 added

#5 @SergeyBiryukov
10 months ago

  • Owner set to SergeyBiryukov
  • Resolution set to fixed
  • Status changed from new to closed

In 44317:

i18n: Prevent a PHP warning when a mu-plugin loads a textdomain.

determine_locale() accesses the $pagenow global, but this is set after mu-plugins are loaded, so we need to check that it's been set.

Props swissspidy, azaozz.
Merges [44284] to trunk.
Fixes #45668.

#6 @pento
10 months ago

#45696 was marked as a duplicate.

Note: See TracTickets for help on using tickets.