In `WP_Upgrader::delete_temp_backup()`, a malformed `sprintf()` call did not pass the value, triggering a Warning in PHP 7 and a Fatal Error in PHP 8.
This fixes the malformed `sprintf()` call by correctly passing the value.
Follow-up to [55720].
Props akihiroharai, afragen.
Fixes#59320.
Built from https://develop.svn.wordpress.org/trunk@56550
git-svn-id: http://core.svn.wordpress.org/trunk@56062 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Replaces `trigger_error()` with `wp_trigger_error()` in each of the `WP_Text_Diff_Renderer_Table` magic methods.
[56354] added the dynamic properties deprecation messages to the `__get()`, `__set()`, `__isset()`, `__unset()` magic methods. Since that commit, `wp_trigger_error()` was introduced (see [56530]) as a wrapper for `trigger_error()`.
Follow-up to [56354], [56530].
See #58898, #57686.
Built from https://develop.svn.wordpress.org/trunk@56544
git-svn-id: http://core.svn.wordpress.org/trunk@56056 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Replaces `trigger_error()` with `wp_trigger_error()` in each of the `WP_User_Query` magic methods.
[56353] added the dynamic properties deprecation messages to the `__get()`, `__set()`, `__isset()`, `__unset()` magic methods. Since that commit, `wp_trigger_error()` was introduced (see [56530]) as a wrapper for `trigger_error()`.
Follow-up to [56353], [56530].
See #58897, #57686.
Built from https://develop.svn.wordpress.org/trunk@56543
git-svn-id: http://core.svn.wordpress.org/trunk@56055 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Replaces `trigger_error()` with `wp_trigger_error()` in each of the `WP_List_Table` magic methods.
[56349] added the dynamic properties deprecation messages to the `__get()`, `__set()`, `__isset()`, `__unset()` magic methods. Since that commit, `wp_trigger_error()` was introduced (see [56530]) as a wrapper for `trigger_error()`.
Follow-up to [56349], [56356], [56530].
See #58896, #57686.
Built from https://develop.svn.wordpress.org/trunk@56542
git-svn-id: http://core.svn.wordpress.org/trunk@56054 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The static instance of `WP_Font_Face` is not needed. It was an unnecessary carryover from the experimental Fonts API (which was not introduced into Core).
Whereas the Fonts API needed to persist its data (i.e. to maintain the registered and enqueued fonts throughout the web request), Font Face does not have data to persist.
Font Face processes the fonts it receives when `WP_Font_Face::generate_and_print( $fonts )` is invoked. Thus, a singleton is not needed.
Removing the static reduces the amount of the code in the function and eliminates running its tests in separate processes to ensure a different instance is always used.
References:
* [https://github.com/WordPress/gutenberg/pull/54228 Gutenberg PR 54228].
Follow-up to [56500].
Props hellofromTonya, costdev.
Fixes#59165.
Built from https://develop.svn.wordpress.org/trunk@56540
git-svn-id: http://core.svn.wordpress.org/trunk@56052 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This updates all 3rd-party GitHub actions to their latest versions. The following actions were updated:
- `actions/cache`
- `actions/checkout`
- `actions/setup-node`
- `codecov/codecov-action`
- `shivammathur/setup-php`
- `slackapi/slack-github-action`
In the latest version of `actions/checkout` (`4.0.0`), a new input was introduced to control the output of command progress. This change uses this new `show-progress` input to turn off displaying progress by default. Progress will be shown when a workflow is run with debug mode enabled, just in case it contains helpful information.
Props johnbillion, desrosj.
See #58867.
Built from https://develop.svn.wordpress.org/trunk@56537
git-svn-id: http://core.svn.wordpress.org/trunk@56049 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This updates the npm dependencies for Twenty Nineteen and Twenty Twenty to their latest versions. This also includes the results of running `npm audit fix`.
There are no changes in any built files as a result.
See #58863.
Built from https://develop.svn.wordpress.org/trunk@56533
git-svn-id: http://core.svn.wordpress.org/trunk@56045 1a063a9b-81f0-0310-95a4-ce76da25c4cd
While `npm install` was working without issue after [56531], `npm ci` was not. The latter expects dependencies in the `package-lock.json` to match those in `package.json` exactly.
Follow up to [56378], [56387], [56442], [56531[.
Fixes#59187. See #56658.
Built from https://develop.svn.wordpress.org/trunk@56532
git-svn-id: http://core.svn.wordpress.org/trunk@56044 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This results in a new `package-lock.json` file being generated that uses `lockfileVersion` 2.x.
There are no changes to built files as a result of this update.
Follow up to [56378], [56387], [56442].
Props mikestraw, whyisjake, jivygraphics.
Fixes#59187. See #56658.
Built from https://develop.svn.wordpress.org/trunk@56531
git-svn-id: http://core.svn.wordpress.org/trunk@56043 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Introduces `wp_trigger_error()` as a wrapper around PHP's native `trigger_error()`. As a wrapper, it's lean and not opinionated about the message. It accepts an E_USER family error level, meaning it is not limited to only notices.
Where `_doing_it_wrong()` intends to loudly alert developers "Hey you're doing it wrong - fix it", `wp_trigger_error()` is not opinionated and does not add wording. Rather, it passes the given message to `trigger_error()`.
`wp_trigger_error()` is meant for every `trigger_error()` instance. It can be used:
* in `_doing_it_wrong()` and each `_deprecated_*()` function.
* for PHP 8.x deprecations.
* for PHP error parity.
* for less severe "doing it wrong" instance that do not require bailing out.
* when a component or extension is not available on the server
* for instances where it's not clear if a plugin's or theme's code is the root cause.
* and more.
Technical details:
* Does not trigger the error if `WP_DEBUG` is not `true`.
* Includes `wp_trigger_error_run` action to allow hooking in for backtracing and deeper debug.
* Accepts an E_USER error level, but defaults to `E_USER_NOTICE`.
* Requires a function name, though can be an empty string. As the output message generated by `trigger_error()` references the file and line number where it was invoked, passing the function's name provides more information where the error/warning/notice/deprecation happened. It's intended to help with debug.
* A WordPress version number is not included.
* As messages can appear in the browser, the message is escaped using `esc_html()`. As noted in [https://www.php.net/manual/en/function.trigger-error.php the PHP manual]: "HTML entities in message are not escaped. Use htmlentities() on the message if the error is to be displayed in a browser."
References:
* [https://www.php.net/manual/en/function.trigger-error.php PHP manual for `trigger_error()`].
* [https://www.php.net/manual/en/errorfunc.constants.php E_USER constants (error level) in the PHP manual].
Props azaozz, hellofromTonya, flixos90, costdev, peterwilsoncc, oglekler, mukesh27.
See #57686.
Built from https://develop.svn.wordpress.org/trunk@56530
git-svn-id: http://core.svn.wordpress.org/trunk@56042 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Ensures that preview callbacks attached to the `stylesheet` and `template` filters do not run before `pluggable.php` has been included. These callbacks need functionality from `pluggable.php`.
Props: scruffian, johnbillion, SergeyBiryukov, okat, okat.
Fixes: #59000.
Built from https://develop.svn.wordpress.org/trunk@56529
git-svn-id: http://core.svn.wordpress.org/trunk@56041 1a063a9b-81f0-0310-95a4-ce76da25c4cd
In WordPress 6.3, the last parameter of `wp_register_script()` and `wp_enqueue_script()` was changed to an array rather than a boolean. While a boolean is still supported for backward compatibility, it makes sense to update the codebase to use the new signature.
The updates are fully backward compatible:
* In places where `true` was provided, `array( 'in_footer' => true )` will still be interpreted as a boolean true in WordPress versions prior to 6.3.
* In places where `false` was provided, the parameter is omitted which will work correctly throughout all WordPress versions given that is and has been the default value anyway.
Props mrinal013, huzaifaalmesbah, niravsherasiya7707, joemcgill.
Fixes#59302.
See #58634.
Built from https://develop.svn.wordpress.org/trunk@56526
git-svn-id: http://core.svn.wordpress.org/trunk@56038 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Previously, bulk upgrades did not verify that a plugin package was compatible with the site's WordPress version or the server's PHP version. This could lead to incompatible updates being installed, causing various compatibility issues and errors.
This change implements the following checks:
- If available, the API response's `requires` and `requires_php` values are checked for compatibility. This saves time, diskspace, memory and file operations by failing the upgrade before the package is downloaded and unpacked.
- If the API check passes, the downloaded and unpacked package is verified using `Plugin_Upgrader::check_package()` to ensure a plugin file is present, and the plugin's "RequiresWP" and "RequiresPHP" headers are compatible, if present. This ensures that a mismatch between the API response and the plugin file's headers does not cause an incompatible plugin to be installed.
Props salcode, afragen, mukesh27, iammehedi1, zunaid321, johnbillion, SergeyBiryukov, costdev.
Fixes#59198.
Built from https://develop.svn.wordpress.org/trunk@56525
git-svn-id: http://core.svn.wordpress.org/trunk@56037 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This fixes an issue introduced in [56044] in which the path to core block styles are cached to avoid expensive file operations on every page load. The original caching strategy is now modified so that only the path relative to the blocks location are stored, rather than the full path, since the path to the `wp-includes` folder can change after the value is generated. The new cached value also includes the current WordPress version value to ensure it is rebuilt when the version changes.
Props lhe2012, coreyw, colorful tones, petitphp, mukesh27, spacedmonkey, joemcgill, flixos90, kimannwall, desmith.
Fixes#59111.
Built from https://develop.svn.wordpress.org/trunk@56524
git-svn-id: http://core.svn.wordpress.org/trunk@56036 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Previously, several functions and methods in themes api were designed to check for the existence of files in a child theme before falling back to the parent theme. However, these checks did not consider whether the current theme was a child theme or not, resulting in unnecessary file existence checks for non-child themes. Check to see if stylesheet directory matches the template directory before doing the file exists. This optimization helps reduce unnecessary file system access, as file existence checks can be resource-intensive in PHP.
The following functions and methods have been updated as part of this enhancement:
- `WP_Theme::get_file_path`
- `get_theme_file_path`
- `get_theme_file_uri`
Props spacedmonkey, flixos90, sabernhardt, 10upsimon, mukesh27.
Fixes#59279.
Built from https://develop.svn.wordpress.org/trunk@56523
git-svn-id: http://core.svn.wordpress.org/trunk@56035 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The transient `dirsize_cache` stores an array of directory sizes. This transient can grow very large, if the plugin directory has lots of sub directories in it. For example, a site with 30 plugins, the transient was around 2MB. For sites without a persistent object cache, transients without an expiration, are stored in autoloaded options. This means this option would load on every page request. Loading this option on every page request when it is not used it wasteful. Adding a expiration to this transient means it will not autoload. To ensure there is no degradation in performance, the expiration was set to a generous 10-year timeframe, making it highly unlikely to expire before it's refreshed.
Props nicomollet, spacedmonkey, flixos90, wpgurudev.
Fixes#54221.
Built from https://develop.svn.wordpress.org/trunk@56522
git-svn-id: http://core.svn.wordpress.org/trunk@56034 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Includes removing an obsolete recommendation to use a gettext context matching the post type for disambiguation, which would be redundant with the new labels, as they already include the type of content.
Follow-up [14571], [56515].
See #47125.
Built from https://develop.svn.wordpress.org/trunk@56519
git-svn-id: http://core.svn.wordpress.org/trunk@56031 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 `$class` parameter to `$class_name` in `_deprecated_class()`.
Follow-up to [54929], [56467].
Props jrf.
See #59161.
Built from https://develop.svn.wordpress.org/trunk@56514
git-svn-id: http://core.svn.wordpress.org/trunk@56026 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Prior to this commit, the `WP_Query` class split the query for posts into two database queries. First, it initiated an ID-based query to retrieve post IDs, followed by a call to _prime_post_caches to fetch post objects if they weren't already in memory. This splitting of queries was limited to cases where fewer than 500 posts were being requested, to prevent a potentially large database query within the IN statement in _prime_post_caches.
However, this limitation becomes unnecessary when a persistent object cache is enabled, as the post objects can be efficiently retrieved from the fast object cache. This commit transfers the responsibility of fetching posts to the object cache, which not only speeds up the process but also reduces the strain on the database server.
Props peterwilsoncc, spacedmonkey, SergeyBiryukov.
Fixes#57296.
Built from https://develop.svn.wordpress.org/trunk@56513
git-svn-id: http://core.svn.wordpress.org/trunk@56025 1a063a9b-81f0-0310-95a4-ce76da25c4cd
In the method `WP_Widget_Media_Gallery::has_content` call `_prime_post_caches` before the foreach loop. This ensures that the post objects are primed in memory before trying to access the post object in `get_post_type`.
Props niravsherasiya7707, spacedmonkey, mukesh27.
Fixes#58757.
Built from https://develop.svn.wordpress.org/trunk@56512
git-svn-id: http://core.svn.wordpress.org/trunk@56024 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This function accepts an associative array of option names and their autoload values to set, and it will update those values in the database in bulk, only for those options where the autoload field is not already set to the given value.
Two wrapper functions for ease of use accompany the new main function:
* `wp_set_options_autoload( $options, $autoload )` can be used to set multiple options to the same autoload value.
* `wp_set_option_autoload( $option, $autoload )` can be used to set the autoload value for a single option.
All of these functions allow changing the autoload value of an option, which previously has only been possible in combination with updating the value. This limitation prevented some relevant use-cases: For example, a plugin deactivation hook could set all of its options to not autoload, as a cleanup routine, while not actually deleting any data. The plugin's activation hook could then implement the reverse, resetting those options' autoload values to the originally intended ones for when using the plugin.
Props boonebgorges, joemcgill, costdev, mukesh27, SergeyBiryukov, tabrisrp, flixos90.
Fixes#58964.
Built from https://develop.svn.wordpress.org/trunk@56508
git-svn-id: http://core.svn.wordpress.org/trunk@56020 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Block themes currently lack the means to trigger the main query loop for singular content, since they cannot reasonably use the `core/query` and `core/post-template` blocks which are intended only for displaying a list of posts. So far, the missing main query loop on singular block templates has been worked around by enforcing the loop in certain `core/post-*` blocks, which however causes other bugs.
This changeset ensures that the main query loop is still started for singular block theme templates, by wrapping the entire template into the loop, which will by definition only have a single cycle as it only encompasses a single post. This is currently the most reliable solution, since even if there were blocks to properly trigger the main query loop on singular content, it would be unrealistic to expect all existing block themes to update their templates accordingly. It may be revisited in the future.
Props gziolo, youknowriad, joemcgill, costdev, mukesh27, flixos90.
Fixes#58154.
See #59225, #58027.
Built from https://develop.svn.wordpress.org/trunk@56507
git-svn-id: http://core.svn.wordpress.org/trunk@56019 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This extends the performance test workflow added in [55459] to also run tests against the target branch (if running on a pull request) or the previous commit (if running on trunk).
Those results are then compared with the ones from the current commit, and the difference is displayed as a GitHub Actions workflow summary for convenience.
Props mukesh27, flixos90, desrosj, joemcgill, swissspidy.
Fixes#58358, #58359.
See #56150.
Built from https://develop.svn.wordpress.org/trunk@56506
git-svn-id: http://core.svn.wordpress.org/trunk@56018 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Introducing Font Face, a server-side `@font-face` styles generator and printer.
tl;dr:
* Introduces Font Face.
* Deprecates `_wp_theme_json_webfonts_handler()`.
**Introduce Font Face**
From an array of fonts (i.e. each font-family and its font variations to be processed), it:
1. Validates each `font-face` declaration, i.e. the CSS property and value pairing. If validation fails, processing stops with no font-face styles printed.
3. Generates the `@font-face` CSS for each font-family.
4. Prints the CSS within a `<style id="wp-fonts-local">` element.
The entry point into Font Face is through a new global function called `wp_print_font_faces()`, which is automatically called:
* when the `'wp_head'` hook runs (for the front-end).
* when the `'admin_print_styles'` hook runs (for the back-end).
* when `_wp_get_iframed_editor_assets()` runs to inject the `@font-face` styles into the iframed editor.
Once called, it gets the fonts from Theme_JSON merged data layer, which includes theme defined fonts and user activated fonts (once the Font Library #59166 is introduced into Core).
For classic sites, themes and plugins can directly call `wp_print_font_faces()` and pass their fonts array to it for processing.
**Deprecates `_wp_theme_json_webfonts_handler()`.**
As Font Face is a direct replacement, the stopgap code in `_wp_theme_json_webfonts_handler()` (introduced in 6.0.0 via [53282]) is deprecated and unused in Core.
**Props note:**
There's a long multiple year history baked into Font Face, which dates back to the early versions of a web font API (see #46370 and [https://github.com/WordPress/gutenberg/issues/41479 roadmap]. The props list includes those who contributed from those early versions up to this commit.
**References:**
* #46370 original (Web)Fonts API proposal for registering and enqueuing web fonts.
* [https://github.com/WordPress/gutenberg/issues/41479 Gutenberg tracking issue] which includes the evolution from Webfonts API to Fonts API to Font Face.
* [53282] / #55567 Added the stopgap code `_wp_theme_json_webfonts_handler()` in 6.0.
* [https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face @font-face on mdn web docs]
* #59166 Font Library: Font manager for WordPress
Follow-up to [53282].
Props aristath, jonoaldersonwp, hellofromTonya, andraganescu, annezazu, antonvlasenko, arena, askdesign, azaozz, bph, bradley2083, colorful-tones, costdev, davidbaumwald, desrosj, dingo_d, djcowan, domainsupport, dryanpress, elmastudio, flixos90, francina, garrett-eclipse, gigitux, grantmkin, grapplerulrich, gziolo, ironprogrammer, jb510, jeffpaul, jeremyyip, jffng, joostdevalk, jorgefilipecosta, juanmaguitar, mamaduka, matveb, mburridge, mitogh, ndiego, ntsekouras, oandregal, ocean90, oglekler, paaljoachim, pagelab, peterwilsoncc, poena, priethor, scruffian, SergeyBiryukov, shiloey, simison, skorasaurus, soean, westonruter, wildworks, zaguiini.
Fixes#59165.
Built from https://develop.svn.wordpress.org/trunk@56500
git-svn-id: http://core.svn.wordpress.org/trunk@56012 1a063a9b-81f0-0310-95a4-ce76da25c4cd
PHP 8.3 is expected to be released at the end of November 2023.
Enabling the tests to run in CI on PHP 8.3 allows WordPress core to start getting ready.
Note: Xdebug-related tests will not be run on PHP 8.3 at this time as the Docker image for PHP 8.3 does not contain Xdebug yet. Once a stable release of Xdebug 3.3.0 is available, it can be added to the Docker image and the test step can then be enabled for PHP 8.3.
Follow-up to [53922], [56492], [56495].
Props jrf, costdev.
See #59231.
Built from https://develop.svn.wordpress.org/trunk@56498
git-svn-id: http://core.svn.wordpress.org/trunk@56010 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This changeset adds an exception to prevent permission issues on `.docx` generated by Google Docs. This is a temporary fix for an upstream bug on the `finfo_file()`
PHP function which returns a redundant MIME type for these documents.
Props winterstreet, jakariaistauk, mujuonly, mi5t4n, annashopina, audrasjb, azaozz, mikeschroder, oglekler.
Fixes#57898.
Built from https://develop.svn.wordpress.org/trunk@56497
git-svn-id: http://core.svn.wordpress.org/trunk@56009 1a063a9b-81f0-0310-95a4-ce76da25c4cd
