Call to undefined function get_locale() in admin.php

[zyphlar]

On /wp-admin/includes/admin.php line 16, if admin.php is accessed directly or via any path that doesn't have the proper includes, the following error is emitted:

Fatal error: Uncaught Error: Call to undefined function get_locale() in /var/www/html/wp-admin/includes/admin.php:16 Stack trace: #0 {main} thrown in /var/www/html/wp-admin/includes/admin.php on line 16

Although it's not crucial, bots, scrapers, malicious users, and misconfigured aspects of WordPress or plugins can trigger this error making admins think that something is broken with the website. If something shouldn't be called directly, or only with certain parameters, that should be coded as such without assumption.

Bug introduced Nov 10 2022:

---
​https://github.com/WordPress/WordPress/commit/c9a4d274fcb6f176dfe1e509212780df6b749586
---

I18N: Always pass $locale to load_textdomain().

In [53874] the optional $locale parameter was added to load_textdomain(). While most load_textdomain() calls in core were were updated, some were missed. Passing the original locale avoids the need to call determine_locale() by load_textdomain() which is used as a fallback.

Props ocean90, swissspidy, desrosj.
See #57060.
Built from ​https://develop.svn.wordpress.org/trunk@54797

git-svn-id: ​http://core.svn.wordpress.org/trunk@54349 1a063a9b-81f0-0310-95a4-ce76da25c4cd

[Presskopp]

Patch simply using die() if the file is called directly.

[TobiasBg]

Hi @zyphlar,

thanks for opening this ticket!

The same occurs in most of /wp-includes/*.php and /wp-admin/includes/*.php

However, ​this is not a security issue, nor is it something that intends on being "fixed" as it's not encountered during "standard usage". If WordPress is used on a production server, error displays should be disabled, and/or direct access to the php files in the above directories disabled.

Please see also some of the related/duplicate tickets: #38317, #18715, #30103, #30806, #17737, #31663, #35835, #10367.

[zyphlar]

Thanks, in that case the real issue is that

If WordPress is used on a production server, error displays should
be disabled, and/or direct access to the php files in the above
directories disabled.

is probably not a sustainable solution. I see the errors in my error logs which makes me as an admin think that there's something broken with my website. The onus shouldn't be on me as an admin to modify the htaccess or other access controls of a software package to prevent spurious errors: all unhandled exceptions represent an unexpected condition that deserves investigation, so if failure on direct access is expected then the best place to handle that is inside the script itself where it refuses to proceed under invalid conditions.

You can close and #WontFix this, but it'll keep being an issue and keep making people think there are problems, as the eight duplicate tickets attest to. It shouldn't be hard to put a one-liner exit("direct script access disabled"); at the top of these files, or improved htaccess rules.

[scofennell@…]

I completely agree that it's a nuisance to have errors like this piling up in New Relic and other logging systems. Would love to see this addressed.