Adds an explicit 1 hour expiration for the translation file cache introduced in [57287] / #58919.
This prevents stale caches when a site does not use the regular way of installing language packs, for example when an atomic filesystem is involved.
Also configures the translation_files group as a global cache group on multisite.
Reviewed by swissspidy.
Merges [57831] to the to the 6.5 branch.
Props dd32.
Fixes#60764.
Built from https://develop.svn.wordpress.org/branches/6.5@57838
git-svn-id: http://core.svn.wordpress.org/branches/6.5@57339 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This fixes a bug introduced by [57129] and [56635] in which deprecating the previous `TEMPLATEPATH` and `STYLESHEETPATH` constants in favor of `get_template_directory()` and `get_stylesheet_directory()` functions caused the active theme template path to change when using `switch_to_blog()`.
This introduces a new function, `wp_set_template_globals()`, which is called during the bootstrap process to store the template paths to new globals values `$wp_template_path` and `$wp_stylesheet_path`. This restores behavior to how things worked prior to [56635] but retains the ability for template values to be reset for better testability.
Related #18298, #60025.
Props joemcgill, flixos90, mukesh27, swissspidy, manfcarlo, metropolis_john, jeremyfelt.
Fixes#60290.
Built from https://develop.svn.wordpress.org/trunk@57685
git-svn-id: http://core.svn.wordpress.org/trunk@57186 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Use 'theme_files' cache group for block pattern caches. Previously, block pattern cache data was not stored in a cache group and used the default group. This new cache group, is setup as a global cache group, meaning that sites using multisite, will have a single cache for block pattern data per theme. This change also no longer invalidate block pattern caches in multisite instances, meaning block pattern caches can be shared between sites on a network, meaning less repeated data in the object cache.
Props spacedmonkey, flixos90, joemcgill.
Fixes#60120.
Built from https://develop.svn.wordpress.org/trunk@57608
git-svn-id: http://core.svn.wordpress.org/trunk@57109 1a063a9b-81f0-0310-95a4-ce76da25c4cd
[57545] introduced the Plugin Dependencies feature, which contains a new `plugin_data` option.
Previously, the `plugin_data` option was being updated during bootstrap and in `get_plugins()`, causing an error when using the install script as the options database table does not yet exist, and also risked an "out of sync" issue between the database and the cache on websites with heavy traffic.
This removes the calls to `update_option()` during Core's bootstrap, and guards the call in `get_plugins()` to ensure that it doesn't run when WordPress is installing.
Follow-up to [57545].
Props desrosj, swisspidy, huzaifaalmesbah, afragen, dd32, azaozz, costdev.
Fixes#60461. See #60457, #60491.
Built from https://develop.svn.wordpress.org/trunk@57592
git-svn-id: http://core.svn.wordpress.org/trunk@57093 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Introduces a new "Requires Plugins" plugin header so that plugin developers can list the slugs of the plugins theirs depends on.
This will inform users of the requirements, and provide links to the WordPress.org Plugins Repository that they can click to install and activate the dependencies first.
Plugins whose requirements are not met cannot be installed or activated, and they will be deactivated automatically if their requirements become unmet.
Plugins that others rely on cannot be deactivated or deleted until their dependent plugins are deactivated or deleted.
In memory of Alex Mills and Alex King.
WordPress Remembers.
Props ahoereth, afragen, alanfuller, alexkingorg, amykamala, anonymized_10690803, apeatling, ashfame, atimmer, audrasjb, aristath, azaozz, batmoo, beaulebens, blobaugh, bobbingwide, boonebgorges, brianhenryie, chanthaboune, chrisdavidmiles, coolmann, costdev, courane01, danielbachhuber, davidperez, dd32, Denis-de-Bernardy, dingo_d, DJPaul, dougal, DrewAPicture, ethitter, filosofo, georgestephanis, giuseppemazzapica-1, goldenapples, griffinjt, hellofromTonya, husobj, ideag, jarednova, jbobich, jbrinley, jltallon, joedolson, johnciacia, johnjamesjacoby, joppuyo, jsmoriss, karmatosed, kebbet, knutsp, kraftbj, kraftner, kurtpayne, lkraav, logikal16, luisherranz, man4toman, markjaquith, matt, mbijon, megphillips91, mikeschinkel, mordauk, morehawes, mrwweb, mte90, mukesh27, mzaweb, nacin, norcross, nvwd, nwjames, obliviousharmony, ocean90, oglekler, paaljoachim, pauldewouters, pbaylies, pbiron, peterwilsoncc, Philipp15b, poena, pogidude, retlehs, rmccue, ryan, sabreuse, sc0ttkclark, scribu, sereedmedia, SergeyBiryukov, ShaneF, shidouhikari, soean, spacedmonkey, stephenh1988, swissspidy, taylorde, tazotodua, threadi, TimothyBlynJacobs, TJNowell, tollmanz, toscho, tropicalista, Viper007Bond, westi, whiteshadow, williamsba1, wpsmith, ZaneMatthew.
Fixes#22316.
Built from https://develop.svn.wordpress.org/trunk@57545
git-svn-id: http://core.svn.wordpress.org/trunk@57046 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This changeset introduces two functions:
* `wp_is_serving_rest_request()` returns a boolean for whether WordPress is serving an actual REST API request.
* `wp_is_rest_endpoint()` returns a boolean for whether a WordPress REST API endpoint is currently being used. While this is always the case if `wp_is_serving_rest_request()` returns `true`, the function additionally covers the scenario of internal REST API requests, i.e. where WordPress calls a REST API endpoint within the same request.
Both functions should only be used after the `parse_request` action.
All relevant manual checks have been adjusted to use one of the new functions, depending on the use-case. They were all using the same constant check so far, while in fact some of them were intending to check for an actual REST API request while others were intending to check for REST endpoint usage.
A new filter `wp_is_rest_endpoint` can be used to alter the return value of the `wp_is_rest_endpoint()` function.
Props lots.0.logs, TimothyBlynJacobs, flixos90, joehoyle, peterwilsoncc, swissspidy, SergeyBiryukov, pento, mikejolley, iandunn, hellofromTonya, Cybr, petitphp.
Fixes#42061.
Built from https://develop.svn.wordpress.org/trunk@57312
git-svn-id: http://core.svn.wordpress.org/trunk@56818 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Exit early when parsing Application Password credentials if Authorization header value does not contain at least one colon. The `Authorization` Basic header must use a colon to separate the username and password components per RFC 7617, so a username-only string is malformed and should not be processed.
Split `Authorization` header only on the first colon, properly handling passwords containing colons.
Resolves PHP 8.0 warning when `list()` was called on an exploded credentials array containing only one element.
Props kalpeshh, shooper, sc0ttkclark, jrf, mukesh27, oglekler, nicolefurlan.
Fixes#57512.
Built from https://develop.svn.wordpress.org/trunk@56804
git-svn-id: http://core.svn.wordpress.org/trunk@56316 1a063a9b-81f0-0310-95a4-ce76da25c4cd
While generally the functions `get_template_directory()` and `get_stylesheet_directory()` were long recommended to use to get the parent or child theme directory, the `TEMPLATEPATH` and `STYLESHEETPATH` constants were still used in a few places in core, most importantly in template related logic.
The remaining usage was problematic as it prevented testability of certain key components of WordPress core.
This changeset replaces all remaining usage with the corresponding functions and effectively marks these constants as deprecated. It also adds test coverage accordingly and even unlocks some existing, previously commented out test coverage to work as expected.
Performance of the new approach has been benchmarked and shows no notable differences. Yet, given that the current theme directories are not expected to change within a regular WordPress page load, the `get_template_directory()` and `get_stylesheet_directory()` functions were amended with in-memory caching of the result, unless one of the defining values is being filtered.
Props thekt12, spacedmonkey, mukesh27, aaroncampbell, scribu, lloydbudd, cais, chipbennett, toscho, omarabid, CrazyJaco, DrewAPicture, obenland, wonderboymusic, nacin, helen, dd32, chriscct7, SergeyBiryukov, swissspidy, joemcgill, flixos90.
Fixes#18298.
Built from https://develop.svn.wordpress.org/trunk@56635
git-svn-id: http://core.svn.wordpress.org/trunk@56147 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This changes the function name for the helper function to check whether the current environment is running with the `WP_DEVELOPMENT_MODE` constant set to be more consistent with similar functions in core, like `wp_is_maintenance_mode()` and `wp_is_recover_mode()`.
Props flixos90, swissspidy, costdev, peterwilson, robinwpdeveloper, SergeyBiryukov, joemcgill.
See 57487.
Built from https://develop.svn.wordpress.org/trunk@56249
git-svn-id: http://core.svn.wordpress.org/trunk@55761 1a063a9b-81f0-0310-95a4-ce76da25c4cd
`str_contains()` was introduced in PHP 8.0 to perform a case-sensitive check indicating if the string to search in (haystack) contains the given substring (needle).
WordPress core includes a polyfill for `str_contains()` on PHP < 8.0 as of WordPress 5.9.
This commit replaces `false !== strpos( ... )` with `str_contains()` in core files, making the code more readable and consistent, as well as better aligned with modern development practices.
Follow-up to [55988], [55990], [56014], [56021], [56031], [56032], [56065], [56241].
See #58206.
Built from https://develop.svn.wordpress.org/trunk@56245
git-svn-id: http://core.svn.wordpress.org/trunk@55757 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Introduce the development mode `all` as a a cover-all mode for the existing `theme`, `plugin` and `core` development modes. Developers can use the `all` mode if they are developing both themes and plugins, for example.
Introduce the utility function `wp_in_development_mode()` allowing developers to detect the mode via a parameter. If the development mode is set to `all` this function will always return `true`. If the development mode is specific then only the chosen mode will return `true`.
Follow up to [56079,56042].
Props flixos90.
Fixes#57487.
Built from https://develop.svn.wordpress.org/trunk@56223
git-svn-id: http://core.svn.wordpress.org/trunk@55735 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This changeset adds a check for the existence of `db.php` at the default path `ABSPATH . 'wp-content/db.php'`, even if `WP_CONTENT_DIR` is defined and `db.php`
is placed in `WP_CONTENT_DIR`.
Follow-up to [49161].
Props mikeyzm, SergeyBiryukov, hztyfoon,
Fixes#58201.
Built from https://develop.svn.wordpress.org/trunk@56152
git-svn-id: http://core.svn.wordpress.org/trunk@55664 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Updates the wordpress npm packages and their dependencies to the latest versions, as well as auto-updates to relevant core PHP files.
Props youknowriad, joemcgill, spacedmonkey, ramonopoly, peterwilsoncc, bernhard-reiter, tyxla, dmsnell.
Fixes#58623.
Built from https://develop.svn.wordpress.org/trunk@56065
git-svn-id: http://core.svn.wordpress.org/trunk@55577 1a063a9b-81f0-0310-95a4-ce76da25c4cd
In recent releases, WordPress core added several instances of cache usage around specific files. While those caches are safe to use in a production context, in development certain nuances apply for whether or not those caches make sense to use. Initially, `WP_DEBUG` was used as a temporary workaround, but it was clear that a more granular method to signify a specific development mode was required: For example, caches around `theme.json` should be disabled when working on a theme as otherwise it would disrupt the theme developer's workflow, but when working on a plugin or WordPress core, this consideration does not apply.
This changeset introduces a `WP_DEVELOPMENT_MODE` constant which, for now, can be set to either "core", "plugin", "theme", or an empty string, the latter of which means no development mode, which is also the default. A new function `wp_get_development_mode()` is the recommended way to retrieve that configuration value.
With the new function available, this changeset replaces all existing instances of the aforementioned `WP_DEBUG` workaround to use `wp_get_development_mode()` with a more specific check.
Props azaozz, sergeybiryukov, peterwilsoncc, spacedmonkey.
Fixes#57487.
Built from https://develop.svn.wordpress.org/trunk@56042
git-svn-id: http://core.svn.wordpress.org/trunk@55554 1a063a9b-81f0-0310-95a4-ce76da25c4cd
`str_contains()` was introduced in PHP 8.0 to perform a case-sensitive check indicating if the string to search in (haystack) contains the given substring (needle).
WordPress core includes a polyfill for `str_contains()` on PHP < 8.0 as of WordPress 5.9.
This commit replaces `false !== strpos( ... )` with `str_contains()` in core files, making the code more readable and consistent, as well as better aligned with modern development practices.
Follow-up to [55988], [56021], [56031].
See #58206.
Built from https://develop.svn.wordpress.org/trunk@56032
git-svn-id: http://core.svn.wordpress.org/trunk@55544 1a063a9b-81f0-0310-95a4-ce76da25c4cd
`str_contains()` was introduced in PHP 8.0 to perform a case-sensitive check indicating if the string to search in (haystack) contains the given substring (needle).
WordPress core includes a polyfill for `str_contains()` on PHP < 8.0 as of WordPress 5.9.
This commit replaces `false !== strpos( ... )` with `str_contains()` in core files, making the code more readable and consistent, as well as better aligned with modern development practices.
Follow-up to [55988], [56021].
See #58206.
Built from https://develop.svn.wordpress.org/trunk@56031
git-svn-id: http://core.svn.wordpress.org/trunk@55543 1a063a9b-81f0-0310-95a4-ce76da25c4cd
`str_ends_with()` was introduced in PHP 8.0 to perform a case-sensitive check indicating if the string to search in (haystack) ends with the given substring (needle).
WordPress core includes a polyfill for `str_ends_with()` on PHP < 8.0 as of WordPress 5.9.
Follow-up to [55990].
See #58220.
Built from https://develop.svn.wordpress.org/trunk@56014
git-svn-id: http://core.svn.wordpress.org/trunk@55526 1a063a9b-81f0-0310-95a4-ce76da25c4cd
`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
