`str_starts_with()` and `str_ends_with()` were introduced in PHP 8.0 to perform a case-sensitive check indicating if the string to search in (haystack) begins or ends with the given substring (needle).
WordPress core includes a polyfill for these functions on PHP < 8.0 as of WordPress 5.9.
This commit uses `str_starts_with()` and `str_ends_with()` in core files where appropriate:
* `$needle === substr( $string, 0, $length )`, where `$length` is the length of `$needle`, is replaced with `str_starts_with( $haystack, $needle )`.
* `$needle === substr( $string, $offset )`, where `$offset` is negative and the absolute value of `$offset` is the length of `$needle`, is replaced with `str_ends_with( $haystack, $needle )`.
This aims to make the code more readable and consistent, as well as better aligned with modern development practices.
Follow-up to [52039], [52040], [52326], [55703], [55710], [55987], [55988].
Props Soean, spacedmonkey, Clorith, ocean90, azaozz, sabernhardt, SergeyBiryukov.
Fixes#58220.
Built from https://develop.svn.wordpress.org/trunk@55990
git-svn-id: http://core.svn.wordpress.org/trunk@55502 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The `usermeta` group was introduced in WP 2.0, but was never actually used in WordPress core.
The `user_meta` group is used instead.
Follow-up to [3011], [15482], [16562], [53823], [53832], [54940].
Props ignatggeorgiev, peterwilsoncc, oglekler, pamprn09, spacedmonkey, SergeyBiryukov.
Fixes#58175.
Built from https://develop.svn.wordpress.org/trunk@55940
git-svn-id: http://core.svn.wordpress.org/trunk@55452 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Updates `wp_get_active_and_valid_themes()` to return early when `wp_using_themes()` returns `false`. This prevents a theme's `functions.php` from being loaded erroneously when the site isn't using themes.
Also adds `define( 'WP_USE_THEMES', true );` to the test suite bootstrap. Some tests randomly break without it because they were dependent on the previous buggy behavior.
Props bpayton, costdev, danielbachhuber, hellofromtonya, sergeybiryukov, spacedmonkey.
Fixes#57928.
Built from https://develop.svn.wordpress.org/trunk@55890
git-svn-id: http://core.svn.wordpress.org/trunk@55402 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The cache group `users-queries` was added in [55657]. This global cache group, was named to be inline with cache groups added in [55526]. However, the naming of the group does not match, as other cache groups, do not end with s at the end. This change fix this naming.
Props spacedmonkey, SergeyBiryukov, peterwilsoncc.
See #40613.
Built from https://develop.svn.wordpress.org/trunk@55680
git-svn-id: http://core.svn.wordpress.org/trunk@55192 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Cache the results of database queries within `WP_User_Query` class. Only cache queries that are requesting 3 or less fields so that caches are not storing full user objects. Cache results are stored in a new global cache group named `users-queries`. Add a new parameter to `WP_User_Query` called `cache_results` to allow developers to opt out of a receiving cached results. `cache_results` parameter defaults to true. Also add a new helper function called `wp_cache_set_users_last_changed`, similar to `wp_cache_set_posts_last_changed` that incroments last changed value in cache group `users`. Ensure that `wp_cache_set_users_last_changed` is called whenever user / user meta is modified for proper cache invalidation.
Props johnjamesjacoby, spacedmonkey, westi, dd32, strategio, srikanthmeenakshi, OllieJones, khoipro, rjasdfiii, flixos90, mukesh27, peterwilsoncc.
Fixes#40613.
Built from https://develop.svn.wordpress.org/trunk@55657
git-svn-id: http://core.svn.wordpress.org/trunk@55169 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Fixes a bug introduced in [55526]. The cache groups `network-queries` and `site-queries` store query results for network and site. These are network level data and should be stored in a global cache group.
Props spacedmonkey, tillkruess, flixos90.
See #57625.
Built from https://develop.svn.wordpress.org/trunk@55537
git-svn-id: http://core.svn.wordpress.org/trunk@55049 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This resolves a fatal error and displays an actionable message if the `mysqli` PHP extension is missing.
Previously, `wp_check_php_mysql_versions()` performed an early check whether `mysql`, `mysqli`, or `mysqlnd` extensions are loaded, but that did not work if the `mysqlnd` extension is the only one present.
Checking specifically for `mysqli_connect()` or `mysql_connect()` functions should be a more reliable approach and more closely mirrors the existing checks in the `wpdb` class.
Follow-up to [1955], [4489], [7234], [12732], [19760], [27257], [36434].
Props bgin, desrosj, dimadin, ipajen, hellofromTonya, sc0ttkclark, azaozz, SergeyBiryukov.
Fixes#51988.
Built from https://develop.svn.wordpress.org/trunk@55367
git-svn-id: http://core.svn.wordpress.org/trunk@54900 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This changeset is part of a greater effort to enhance the caching strategy for `theme.json` based data. Similar to [55138], the cache is currently ignored when `WP_DEBUG` is on to avoid interrupting the theme developer's workflow.
Props oandregal, spacedmonkey, hellofromtonya, flixos90, ironprogrammer, azaozz, aristath, costdev, mcsf.
Fixes#56910.
Built from https://develop.svn.wordpress.org/trunk@55148
git-svn-id: http://core.svn.wordpress.org/trunk@54681 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Calls to `wp-admin/load-styles.php` do not include the loading of `wp_cache_*()` functions. With [55086], this caused a fatal error:
{{{
Fatal error: Uncaught Error: Call to undefined function wp_cache_get() in /wp-includes/global-styles-and-settings.php on line 285
}}}
In some production and local environments running `trunk`, the admin area looked broken as the styling was not loaded as there were no HTTP requests.
This commit reverts the caching from [55086] to restore sites running `trunk` until a solution is found.
Follow-up to [55086].
Props Otto42, dmsnell, costdev.
See #56975.
Built from https://develop.svn.wordpress.org/trunk@55092
git-svn-id: http://core.svn.wordpress.org/trunk@54625 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Adds `wp_theme_has_theme_json()` for public consumption, to replace the private internal Core-only `WP_Theme_JSON_Resolver::theme_has_support()` method. This new global function checks if a theme or its parent has a `theme.json` file.
For performance, results are cached as an integer `1` or `0` in the `'theme_json'` group with `'wp_theme_has_theme_json'` key. This is a non-persistent cache. Why? To make the derived data from `theme.json` is always fresh from the potential modifications done via hooks that can use dynamic data (modify the stylesheet depending on some option, settings depending on user permissions, etc.).
Also adds a new public function `wp_clean_theme_json_cache()` to clear the cache on `'switch_theme'` and `start_previewing_theme'`.
References:
* [https://github.com/WordPress/gutenberg/pull/45168 Gutenberg PR 45168] Add `wp_theme_has_theme_json` as a public API to know whether a theme has a `theme.json`.
* [https://github.com/WordPress/gutenberg/pull/45380 Gutenberg PR 45380] Deprecate `WP_Theme_JSON_Resolver:theme_has_support()`.
* [https://github.com/WordPress/gutenberg/pull/46150 Gutenberg PR 46150] Make `theme.json` object caches non-persistent.
* [https://github.com/WordPress/gutenberg/pull/45979 Gutenberg PR 45979] Don't check if constants set by `wp_initial_constants()` are defined.
* [https://github.com/WordPress/gutenberg/pull/45950 Gutenberg PR 45950] Cleaner logic in `wp_theme_has_theme_json`.
Follow-up to [54493], [53282], [52744], [52049], [50959].
Props oandregal, afragen, alexstine, aristath, azaozz, costdev, flixos90, hellofromTonya, mamaduka, mcsf, ocean90, spacedmonkey.
Fixes#56975.
Built from https://develop.svn.wordpress.org/trunk@55086
git-svn-id: http://core.svn.wordpress.org/trunk@54619 1a063a9b-81f0-0310-95a4-ce76da25c4cd
While using reserved PHP keywords as parameter name labels is allowed, in the context of function calls using named parameters in PHP 8.0+, this will easily lead to confusion. To avoid that, it is recommended not to use reserved keywords as function parameter names.
This commit renames the `$object` parameter to `$input_object` in `wp_clone()`.
Follow-up to [52946], [52996], [52997], [52998], [53003], [53014], [53029], [53039], [53116], [53117], [53137], [53174], [53184], [53185], [53192], [53193], [53198], [53203], [53207], [53215], [53216], [53220], [53230], [53232], [53236], [53239], [53240], [53242], [53243], [53245], [53246], [53257], [53269], [53270], [53271], [53272], [53273], [53274], [53275], [53276], [53277], [53281], [53283], [53284], [53285], [53287], [53364], [53365], [54927], [54929], [54930], [54931], [54932], [54933], [54938], [54943].
Props jrf, aristath, poena, justinahinon, SergeyBiryukov.
See #56788.
Built from https://develop.svn.wordpress.org/trunk@54944
git-svn-id: http://core.svn.wordpress.org/trunk@54496 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Includes minor formatting edits for consistency.
Follow-up to [53/tests], [12179], [12946], [35288], [37884], [38810], [38928], [46596], [48131], [52955], [53548], [53813], [53873], [54118], [54316], [54420], [54421], [54803].
See #56792.
Built from https://develop.svn.wordpress.org/trunk@54855
git-svn-id: http://core.svn.wordpress.org/trunk@54407 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Initialize `WP_Textdomain_Registry` in `wp_load_translations_early()`. This ensures the global `$wp_textdomain_registry` is set up prior to loading the translations.
Props azurseisme, TimothyBlynJacobs, costdev, ocean90, flixos90, swissspidy.
Fixes#57051.
Built from https://develop.svn.wordpress.org/trunk@54803
git-svn-id: http://core.svn.wordpress.org/trunk@54355 1a063a9b-81f0-0310-95a4-ce76da25c4cd
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
[54080] refactored the logic in `get_network_option()`, `update_network_option()` and `delete_network_option()` to use the metadata API. However, this change resulted in issues with large multisite installs that utilize memcached having network options > 1MB in size.
This change reverts [54080] and all related follow-up changes.
Reverts [54080], [54081], and [54082]. Partially reverts [54267] and [54402].
Props pavelschoffer, rebasaurus, johnbillion, spacedmonkey, desrosj, rinatkhaziev.
Fixes#56845.
See #37181.
Built from https://develop.svn.wordpress.org/trunk@54637
git-svn-id: http://core.svn.wordpress.org/trunk@54189 1a063a9b-81f0-0310-95a4-ce76da25c4cd
As the function can be used in a variety of contexts, the `_screen` suffix may not always be appropriate.
This commit aims to reduce confusion by renaming the newly added `is_login_screen()` function to `is_login()`, which better aligns with `is_admin()` and the related `is_*_admin()` function family.
While it does not save a lot of lines of code, this function aims to save developers some time that would otherwise be spent investigating the most reliable way to determine whether the current request is for the login screen.
Implementation details:
* By checking `wp_login_url()`, the function accounts for custom login locations set via the `login_url` filter.
* By checking `$_SERVER['SCRIPT_NAME']` directly, instead of `did_action( 'login_form_login' )` or `$pagenow` global, the function can work as early as possible, for example in a must-use plugin.
Follow-up to [53884].
Props azaozz.
Fixes#19898. See #56400.
Built from https://develop.svn.wordpress.org/trunk@54447
git-svn-id: http://core.svn.wordpress.org/trunk@54006 1a063a9b-81f0-0310-95a4-ce76da25c4cd
After some further discussion, it is apparent that the added clarity was subjective, and the `_screen` suffix may not always be appropriate, e.g. in Ajax context. To address any confusion with the existing names, the documentation for these functions can be updated instead.
Additionally, the `is_super_admin_user()` alias for `is_super_admin()` is reverted as well, which may be reconsidered in the future.
Follow-up to [54259].
Props azaozz, jrf, johnbillion, manfcarlo, Clorith.
See #56400.
Built from https://develop.svn.wordpress.org/trunk@54332
git-svn-id: http://core.svn.wordpress.org/trunk@53891 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Following the introduction of `is_login_screen()` in [53884], it is time to reconsider the `is_*_admin()` functions:
* `is_admin()`: Determines whether the current request is for an administrative interface page.
* `is_blog_admin()`: Whether the current request is for a site's administrative interface, e.g. `/wp-admin/`.
* `is_network_admin()`: Whether the current request is for the network administrative interface, e.g. `/wp-admin/network/`.
* `is_user_admin()`: Whether the current request is for a user admin screen, e.g. `/wp-admin/user/`.
For someone new to WordPress, these names can be quite confusing, especially the last one. When using these functions, one always needs to remember that they don't actually check if the current user is a site administrator.
To complicate things further, there is one more similarly named function that does exactly the latter:
* `is_super_admin()`: Determines whether user is a site admin.
With the above in mind, this commit introduces aliases that better match the functionality and allow for more descriptive code:
* `is_admin()` → `is_admin_screen()`
* `is_blog_admin()` → `is_site_admin_screen()`
* `is_network_admin()` → `is_network_admin_screen()`
* `is_user_admin()` → `is_user_admin_screen()`
Additionally, `is_super_admin_user()` is introduced as an alias for `is_super_admin()`:
* `is_super_admin()` → `is_super_admin_user()`
Plugins and themes are encouraged to start using the newer function names to make code self-descriptive and bring more clarity. The older names are not deprecated at this time, though it may be up for discussion in the future.
Follow-up to [2481], [6412], [12393], [12732], [15558], [15481], [15746], [53884].
Props jrf, tobifjellner, SergeyBiryukov.
See #56400.
Built from https://develop.svn.wordpress.org/trunk@54259
git-svn-id: http://core.svn.wordpress.org/trunk@53818 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Replace logic found in `get_network_option`, `update_network_option` and `delete_network_option` to use the metadata api. Using the metadata api has a number of benefits, such as consistency, default values and useful filters. This change also improves performance by priming the caches of all network options in a single database request.
Props spacedmonkey, swissspidy, sc0ttkclark, johnjamesjacoby, flixos90, jeremyfelt, pento, peterwilsoncc, mukesh27, desrosj.
Fixes#37181
Built from https://develop.svn.wordpress.org/trunk@54080
git-svn-id: http://core.svn.wordpress.org/trunk@53639 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The function to check whether WordPress is not installed has evolved over time, ending up with duplicate conditionals.
This commit combines two conditionals into a single one and includes an early return.
Follow-up to [672], [676], [725], [1184], [1401], [1980], [2171], [2467], [2468], [2486], [2703], [3011], [3670], [12688], [12732], [12762], [13253], [29599], [30581], [34828].
See #55647.
Built from https://develop.svn.wordpress.org/trunk@53915
git-svn-id: http://core.svn.wordpress.org/trunk@53474 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This should help determine whether the current request is for the login screen.
While it does not save a lot of lines of code, including this function in core aims to save developers some time that would otherwise be spent investigating the most reliable way to solve this problem.
Implementation details:
* By checking `wp_login_url()`, the function accounts for custom login locations set via the `login_url` filter.
* By checking `$_SERVER['SCRIPT_NAME']` directly, instead of `did_action( 'login_form_login' )` or `$pagenow` global, the function can work as early as possible, for example in a must-use plugin.
Follow-up to [2481], [6412], [12393], [12732], [15558], [15481], [15746].
Props dcowgill, scribu, donmhico, iandunn, wonderboymusic, nacin, robmiller, kitchin, chriscct7, tazotodua, davidbaumwald, SergeyBiryukov.
Fixes#19898.
Built from https://develop.svn.wordpress.org/trunk@53884
git-svn-id: http://core.svn.wordpress.org/trunk@53443 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This renames the file containing the `wpdb` class to conform to the coding standards.
This commit also includes:
* A new `wp-db.php` that loads the new file, for anyone that may have been including the file directly.
* Replacing references to the old filename with the new filename.
Fixes#56268. See #55647.
Built from https://develop.svn.wordpress.org/trunk@53749
git-svn-id: http://core.svn.wordpress.org/trunk@53308 1a063a9b-81f0-0310-95a4-ce76da25c4cd
`phpversion()` return value and `PHP_VERSION` constant value are identical, but the latter is several times faster because it is a direct constant value lookup compared to a function call.
Props ayeshrajans, jrf, mukesh27, costdev, hellofromTonya, SergeyBiryukov.
Fixes#55680.
Built from https://develop.svn.wordpress.org/trunk@53426
git-svn-id: http://core.svn.wordpress.org/trunk@53015 1a063a9b-81f0-0310-95a4-ce76da25c4cd
When `add_filter( 'wp_is_application_passwords_available', '__return_false' )` exists, HTTPS requirement message is shown even if HTTPS is enabled on the site. This happens because `wp_is_application_passwords_available_for_user()` first invokes `wp_is_application_passwords_available()` which is filterable. The situation could happen if the `'wp_is_application_passwords_available_for_user'` filter returns `false`.
To fix this, the check for HTTPS (or if in a 'local' environment) is moved to a new function called `wp_is_application_passwords_supported()`. Then the return from this function is used as an OR condition for the Application Passwords section and for displaying the HTTPS required message.
Tests are included for both `wp_is_application_passwords_supported()` and `wp_is_application_passwords_available()`.
Follow-up to [51980], [51988].
Props davidbinda, SergeyBiryukov, ocean90, felipeelia, costdev, hellofromTonya.
Fixes#53658.
Built from https://develop.svn.wordpress.org/trunk@52398
git-svn-id: http://core.svn.wordpress.org/trunk@51990 1a063a9b-81f0-0310-95a4-ce76da25c4cd
If `SCRIPT_NAME'` does not exist (which can happen in cron jobs), the following happens:
* PHP 8.1+:
* `Warning: Undefined array key "SCRIPT_NAME"`
* `Deprecated: strpos(): Passing null to parameter #1 ($haystack) of type string is deprecated`
* PHP 8.0: `Warning: Undefined array key "SCRIPT_NAME"`
* PHP 5.6-7.4: No warning or notice
This commit checks if the key exists before passing it to `strpos()`. This resolves the warning, notice, and future error.
Follow-up to [3034], [3069], [12732].
Props audrasjb, costdev, hellofromTonya, karpstrucking, mcjambi, sergeybiryukov.
Fixes#54142.
Built from https://develop.svn.wordpress.org/trunk@52144
git-svn-id: http://core.svn.wordpress.org/trunk@51736 1a063a9b-81f0-0310-95a4-ce76da25c4cd
As of November 2021, the `HTTP/3` protocol is still officially an Internet Draft, but is already supported by 74% of running web browsers and, according to W3Techs, 23% of the top 10 million websites. It has been supported by Google Chrome (including Chrome for Android, and Microsoft Edge, which is based on it) since April 2020 and by Mozilla Firefox since May 2021. Safari 14 (on macOS Big Sur and iOS 14) has also implemented the protocol but support is hidden behind a feature flag.
Based on the wide support, this change adds `HTTP/3` as a valid HTTP protocol.
Props malthert.
Fixes#54404.
Built from https://develop.svn.wordpress.org/trunk@52087
git-svn-id: http://core.svn.wordpress.org/trunk@51679 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Previously errors were not displayed or logged, but the original intention was only to prevent them from being displayed. Hiding them from logs makes problems like #53492 much harder to debug.
This makes the handling of errors in `ms-files` consistent with the REST API, `admin-ajax`, and XML-RPC.
Props iandunn, johnjamesjacoby.
Fixes#53493.
Built from https://develop.svn.wordpress.org/trunk@51358
git-svn-id: http://core.svn.wordpress.org/trunk@50967 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Adds timer_float which can be used to get the time elapsed so far during the PHP script. Should make it easier to display the page generation time in the footer of admin.
WordPress should expose timing data as a float in the most accurate manner possible. timer_stop() has two problems: it uses an initial timestamp generated later than it needs to be and its formatted return value can not reliably be used as a number (some locales swap commas and periods, for example).
Props andy, matt, jorbin.
Fixes#39163.
Built from https://develop.svn.wordpress.org/trunk@50786
git-svn-id: http://core.svn.wordpress.org/trunk@50395 1a063a9b-81f0-0310-95a4-ce76da25c4cd
In [49752] a check was added to prevent creating new Application Passwords if Basic Auth credentials were detected to prevent conflicts. This check takes place in WP-Admin, though a conflict would only arise if Basic Auth was used on the website's front-end.
This commit extracts the Basic Auth check into a reusable function, `wp_is_site_protected_by_basic_auth()`, which can be adjusted using a filter of the same name. This way, a site that uses Basic Auth to protect WP-Admin can still use the Application Passwords feature.
In the future, instead of requiring the use of a filter, WordPress could make a loopback request and check for a `WWW-Authenticate` header to make this detection more robust out of the box.
Props SeBsZ, archon810, aaroncampbell, ocean90, SergeyBiryukov, TimothyBlynJacobs.
Fixes#52066.
Built from https://develop.svn.wordpress.org/trunk@50006
git-svn-id: http://core.svn.wordpress.org/trunk@49707 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Previously, we only supported `application/json` which prevented using subtypes like `application/activity+json`. This allows for the REST API to `json_decode` the body of requests using a JSON subtype `Content-Type`. Additionally, `wp_die()` now properly sends the error as JSON when a JSON subtype is specified in the `Accept` header.
Props pfefferle.
Fixes#49404.
Built from https://develop.svn.wordpress.org/trunk@49329
git-svn-id: http://core.svn.wordpress.org/trunk@49090 1a063a9b-81f0-0310-95a4-ce76da25c4cd
