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.
git-svn-id: https://develop.svn.wordpress.org/trunk@56530 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@56529 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@56513 602fd350-edb4-49c9-b593-d223f7449a82
This expands the code block previously added for `.docx` files to include `.xlsx` files as well, which are known to have the same issue with `finfo_file()`.
Includes a unit test case for `wp_check_filetype_and_ext()`.
Reference: [https://bugs.php.net/bug.php?id=77784 PHP Bug #77784: mime_content_type() result gets doubled for .xlsx].
Follow-up to [56497].
See #57898.
git-svn-id: https://develop.svn.wordpress.org/trunk@56510 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@56508 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@56507 602fd350-edb4-49c9-b593-d223f7449a82
Changes fluid typography calculation to use fallback value if layout wide size is a fluid value.
Props ramonopoly, mukesh27, jastos, aurooba.
See #58754.
git-svn-id: https://develop.svn.wordpress.org/trunk@56503 602fd350-edb4-49c9-b593-d223f7449a82
Adds the ability to process block style variations to the `remove_insecure_properties` function of theme json class.
Props dsas, ramonopoly.
Fixes#59108.
git-svn-id: https://develop.svn.wordpress.org/trunk@56502 602fd350-edb4-49c9-b593-d223f7449a82
Removes the test file and `webfonts` directory for the stopgap code that was deprecated by [56500].
Follow-up to [56500], [53282].
Fixes#59165.
git-svn-id: https://develop.svn.wordpress.org/trunk@56501 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@56500 602fd350-edb4-49c9-b593-d223f7449a82
It was a design goal of the HTML Processor to abort processing its input document when encountering unsupported markup. Unfortunately there was no test for this and so-far, the HTML Processor has paused, but continued processing in these situations.
In this patch a new test ensures that the HTML Processor stops and refuses to move forward after encountering any unsupported markup. It also ensures that it doesn't report any current tag names since unsupported markup could imply that the read tag name is different than the parsed tag name.
Props dmsnell.
Fixes#59167.
git-svn-id: https://develop.svn.wordpress.org/trunk@56493 602fd350-edb4-49c9-b593-d223f7449a82
The single parameter signature, which was used for setting the value on a static property, is deprecated since PHP 8.3. A cross-version solution is to pass `null` as the first parameter.
This commit updates all the instances that use the deprecated signature in WordPress core.
Reference: [https://wiki.php.net/rfc/deprecate_functions_with_overloaded_signatures#reflectionpropertysetvalue PHP RFC: Deprecate functions with overloaded signatures: ReflectionProperty::setValue()].
Follow-up to [53152], [54493], [54799].
Props jrf, costdev, Tests: Correct uses of `ReflectionProperty::setValue()` for static properties.
The single parameter signature, which was used for setting the value on a static property, is deprecated since PHP 8.3. A cross-version solution is to pass `null` as the first parameter.
This commit updates all the instances that use the deprecated signature in WordPress core.
Reference: [https://wiki.php.net/rfc/deprecate_functions_with_overloaded_signatures#reflectionpropertysetvalue PHP RFC: Deprecate functions with overloaded signatures: ReflectionProperty::setValue()].
Follow-up to [53152], [54493], [54799].
Props jrf, costdev, sc0ttkclark.
See #59231.
git-svn-id: https://develop.svn.wordpress.org/trunk@56492 602fd350-edb4-49c9-b593-d223f7449a82
This fixes an issue introduced in [55569] that broke sort ordering by `post_modified_gmt` or `modified_gmt`.
Props david.binda, azaozz, spacedmonkey, flixos90, joemcgill.
Fixes#59226.
git-svn-id: https://develop.svn.wordpress.org/trunk@56490 602fd350-edb4-49c9-b593-d223f7449a82
The `mysql` extension is no longer used in PHP 7 or above. There's a good amount of conditional code in `wpdb` and the health checks that can be removed now that only the `mysqli` functions are used.
Fixes#59118
git-svn-id: https://develop.svn.wordpress.org/trunk@56475 602fd350-edb4-49c9-b593-d223f7449a82
- `__construct()` gets the new `_deprecated_class()` function
- `WP_User_Search` PHP4 style constructor is changed from `_deprecated_function()` to `_deprecated_constructor()`
Adds a test to confirm `WP_User_Search` class is testable as deprecated.
Props jrf, DrewAPicture.
Fixes#41125.
git-svn-id: https://develop.svn.wordpress.org/trunk@56469 602fd350-edb4-49c9-b593-d223f7449a82
Similar to other function in the `_deprecated_*` series, `_deprecated_class()` comes with two new hooks: `deprecated_class_run` and `deprecated_class_trigger_error`.
Support has also been added for setting class deprecation expectations in tests.
Props jrf, wvega, ohryan.
See #41125.
git-svn-id: https://develop.svn.wordpress.org/trunk@56467 602fd350-edb4-49c9-b593-d223f7449a82
Adds new tests to ensure that `wp_authenticate_email_password`, `wp_authenticate_username_password`, and `wp_authenticate_cookie` are better tested. This also unsets cookies properly between tests.
Props JordanPak, johnregan3.
Fixes#36476.
git-svn-id: https://develop.svn.wordpress.org/trunk@56454 602fd350-edb4-49c9-b593-d223f7449a82
WordPress's `get_option()` function generally relies on making individual database requests for each option, however with the majority of options (in most cases) being autoloaded, i.e. fetched once with a single database request and then stored in (memory) cache.
As part of a greater effort to reduce the amount of options that are unnecessarily autoloaded, this changeset introduces an alternative way to retrieve multiple options in a performant manner, with a single database request. This provides a reasonable alternative for e.g. plugins that use several options which only need to be loaded in a few specific screens.
Specifically, this changeset introduces the following functions:
* `prime_options( $options )` is the foundation to load multiple specific options with a single database request. Only options that aren't already cached (in `alloptions` or an individual cache) are retrieved from the database.
* `prime_options_by_group( $option_group )` is a convenience wrapper function for the above which allows to prime all options of a specific option group (as configured via `register_setting()`).
* `get_options( $options )` is another wrapper function which first primes the requested options and then returns them in an associative array, calling `get_option()` for each of them.
Props mukesh27, joemcgill, costdev, olliejones.
Fixes#58962.
git-svn-id: https://develop.svn.wordpress.org/trunk@56445 602fd350-edb4-49c9-b593-d223f7449a82
Removes the foreach loops from the tests by moving the in-test data sets into data providers and combines the URL data sets into one data provider to test with one test method. By using a data providor, all the tests run rather than stopping at the first failure in this group.
Fixes#57660.
Props hellofromTonya.
git-svn-id: https://develop.svn.wordpress.org/trunk@56444 602fd350-edb4-49c9-b593-d223f7449a82
Fixes the error handling for when `WP_Classic_To_Block_Menu_Converter::convert()` returns an instance of `WP_Error`. `WP_Navigation_Fallback::create_classic_menu_fallback()` now checks for `is_wp_error()` and if `true`, returns the error. And the `@return` type is updated to `string|WP_Error`.
Also includes a fix in the return type in `WP_Classic_To_Block_Menu_Converter::convert()` to return an empty string instead of an array instead, i.e. when bailing out for no menu items returned by `wp_get_nav_menu_items()`. The return type is clearly documented as a `string`.
Follow-up to [56052].
Props dlh, get_dave, antonvlasenko, hellofromTonya.
Fixes#58823.
git-svn-id: https://develop.svn.wordpress.org/trunk@56422 602fd350-edb4-49c9-b593-d223f7449a82
[https://github.com/sebastianbergmann/phpunit/blob/9.6/ChangeLog-9.6.md#961---2023-02-03 PHPUnit 9.6.1] deprecated the `assertObjectHasAttribute()` and `assertObjectNotHasAttribute()` methods, leading to deprecation notices in a number of tests.
[https://github.com/sebastianbergmann/phpunit/blob/10.1.3/ChangeLog-10.1.md#1010---2023-04-14 PHPUnit 10.1.0] brought the methods back by popular request, though renamed as `assertObjectHasProperty()` and `assertObjectNotHasProperty()`, to prevent confusion with PHP 8.0 attributes.
This meant that users which cannot (yet) upgrade to PHPUnit 10.1+ would always have deprecation notices for these methods without recourse. So, after much discussion, the new methods have been backported to [https://github.com/sebastianbergmann/phpunit/blob/9.6/ChangeLog-9.6.md#9611---2023-08-19 PHPUnit 9.6.11], leaving just the 10.0.x series with a deprecation notice and no recourse.
What does this mean for WordPress?
WordPress uses the [https://github.com/Yoast/PHPUnit-Polyfills PHPUnit Polyfills] to be able to write tests for the most recent versions of PHPUnit, with the Polyfills taking care of polyfilling any new PHPUnit methods on older PHPUnit versions.
* The PHPUnit Polyfills 1.x series supports PHPUnit 4.x to 9.x.
* The PHPUnit Polyfills 2.x series supports PHPUnit 5.x to 10.x.
WordPress currently runs against PHPUnit 6.x to 9.x with PHPUnit Polyfills 1.x, while the new methods were previously only included in PHPUnit Polyfills 2.0.0+, as they were introduced in PHPUnit 10.x.
Since the `assertObjectHasProperty()` and `assertObjectNotHasProperty()` methods have been backported to PHPUnit 9.x, the PHPUnit Polyfills will now include these methods in the 1.x series as well.
By upgrading to the latest [https://github.com/Yoast/PHPUnit-Polyfills/releases/tag/1.1.0 PHPUnit Polyfills 1.1.0] release, we can get rid of the deprecation notices related to the use of the `assertObjectHasAttribute()` and `assertObjectNotHasAttribute()` methods.
This could have implications for plugins or themes running integration tests with WordPress if they have set their PHPUnit Polyfills dependency to a fixed version or have a too strict version constraint (limiting the PHPUnit Polyfills to the 1.0.x series). The solution for those plugins or themes is to update their version constraints for the PHPUnit Polyfills to allow for the 1.1.x series.
Follow-up to [51559], [51598].
Props jrf, ayeshrajans.
Fixes#59150.
git-svn-id: https://develop.svn.wordpress.org/trunk@56421 602fd350-edb4-49c9-b593-d223f7449a82
Add functions `wp_get_admin_notice()` and `wp_admin_notice()` to create and output admin notices & tests for usage. New functions accept a message and array of optional arguments. This commit does not implement the functions. Include new filters: `wp_admin_notice_args`, `wp_admin_notice_markup` and action: `wp_admin_notice`.
Props joedolson, costdev, sakibmd, dasnitesh780, sabernhardt.
Fixes#57791.
git-svn-id: https://develop.svn.wordpress.org/trunk@56408 602fd350-edb4-49c9-b593-d223f7449a82
* Remove obsolete `load` event handler in `wp-embed` since IE10+ support `DOMContentLoaded`.
* Replace obsolete use of `document.createElement('a')` in favor of the newer `URL` class (supported in all browsers but obsolete IE11).
* Remove obsolete IE10/IE11 code.
* Combine conditionals.
* Use `substring()` instead of deprecated `substr()` method.
* Eliminate the stipulation that `wp-embed.js` not include ampersands, considering this was put in place for WP<4.3 which now accounts for only 1.43% of sites. This includes the elimination of the `verify:wp-embed` grunt task.
Props westonruter, swissspidy.
Fixes#58974.
git-svn-id: https://develop.svn.wordpress.org/trunk@56383 602fd350-edb4-49c9-b593-d223f7449a82
Most block feature checks are for a single feature string, and for such cases it is not intuitive to require an array for the `$feature` parameter of the `block_has_support()` function.
This changeset brings it in line with other functions like `post_type_supports()`, allowing to pass a string for the `$feature`. An array is still supported for more complex cases where support for sub-features needs to be determined. This change furthermore includes a very minor performance tweak by avoiding calls to the `_wp_array_get()` function if a single feature string is being checked for.
Props thekt12, nihar007, mukesh27, swissspidy.
Fixes#58532.
git-svn-id: https://develop.svn.wordpress.org/trunk@56382 602fd350-edb4-49c9-b593-d223f7449a82
If `$blog_id` equals `0`, it should be treated as the current site ID, and there is no need to switch to a different site.
This commit prevents an unnecessary call to `switch_to_blog()` on single site to avoid a fatal error when using `'orderby' => 'post_count'` and the deprecated `'who' => 'authors'` parameter:
{{{
Uncaught Error: Call to undefined function switch_to_blog() in wp-includes/class-wp-user-query.php:1077
}}}
Follow-up to [55657].
Props dd32, austinginder, RavanH, mukesh27.
Fixes#59011.
git-svn-id: https://develop.svn.wordpress.org/trunk@56381 602fd350-edb4-49c9-b593-d223f7449a82
This patch adds support to process the BUTTON element. This requires adding some additional semantic rules to handle situations where a BUTTON element is already in scope.
Also included is a fixup to enforce that `WP_HTML_Processor::next_tag()` never returns for a tag closer. This is useful with the Tag Processor, but not for the HTML Processor. There were tests relying on this behavior to assert that internal processes were working as they should, but those tests have been updated to use the semi-private `step()` function, which does stop on tag closers.
This patch is one in a series of changes to expand support within the HTML API, moving gradually to allow for more focused changes that are easier to review and test. The HTML Processor is a work in progress with a certain set of features slated to be ready and tested by 6.4.0, but it will only contain partial support of the HTML5 specification even after that. Whenever it cannot positively recognize and process its input it bails, and certain function stubs and logical stubs exist to structure future expansions of support.
Props dmsnell.
Fixes#58961.
git-svn-id: https://develop.svn.wordpress.org/trunk@56380 602fd350-edb4-49c9-b593-d223f7449a82
Changes "define" to "declare" in the deprecation message in `WP_List_Table` magic methods.
Why is "declare" better?
It aligns well to:
* the topic of and published information about dynamic properties.
* the act of explicitly listing the variable as a property on the class.
The goal of this message is guide developers to change their code. Changing the term to "declare" hopefully will aid in the understanding of what is being asked of developers when this deprecation is thrown.
Follow-up [56349].
Props hellofromTonya, antonvlasenko.
Fixes#58896.
git-svn-id: https://develop.svn.wordpress.org/trunk@56356 602fd350-edb4-49c9-b593-d223f7449a82
The unknown use of unknown dynamic property within the `WP_Text_Diff_Renderer_Table` property magic methods is now deprecated. A descriptive deprecation notice is provided to alert developers to declare the property on the child class extending `WP_Text_Diff_Renderer_Table`.
Changes in this commit:
* Adds a deprecation notice to the `__get()`, `__set()`, `__isset()`, `__unset()` magic methods, i.e. to alert and inform developers when attempting to get/set/isset/unset a dynamic property.
* Fixes `__get()` to explicitly returns `null` when attempting to get a dynamic property.
* Fixes `__set()` by removing the value return after setting a declared property, as (a) unnecessary and (b) `__set()` should return `void` [https://www.php.net/manual/en/language.oop5.overloading.php#object.set per the PHP handbook].
* Fixes `__isset()` to return `false` if not in the `$compat_fields`, as `isset()` and `__isset()` should always return `bool`:
* [https://www.php.net/manual/en/language.oop5.overloading.php#object.isset `__isset()` in the PHP manual]
* [https://www.php.net/manual/en/function.isset.php `isset()` in the PHP manual]
* Adds a test class with happy and unhappy paths for these changes.
For backward compatibility, no changes are made to the internal declared properties listed in `$compat_fields` and accessed through the magic methods.
For example:
A child class uses a property named `$data` that is not declared as a property on the child class. When getting its value, e.g. `$user_query->data`, the `WP_Text_Diff_Renderer_Table::__get()` magic method is invoked, the following deprecation notice thrown, and `null` returned:
>The property `data` is not declared. Setting a dynamic property is deprecated since version 6.4.0! Instead, declare the property on the class.
=== Why not remove the magic methods, remove the `$compat_fields` property, and restore the properties `public`?
tl;dr Backward compatibility.
If a plugin adds a property to `$compat_fields` array, then sites using that plugin would experience (a) an `Undefined property` `Warning` (PHP 8) | `Notice` (PHP 7) and (b) a possible change in behavior.
=== Why not limit the deprecation for PHP versions >= 8.2?
tl;dr original design intent and inform
The magic methods and `$compat_fields` property were added for one purpose: to continue providing external access to internal properties declared on `WP_Text_Diff_Renderer_Table`. They were not intended to be used for dynamic properties.
Deprecating that unintended usage both alerts developers a change is needed in their child class and informs them what to change.
References:
* Dynamic (non-explicitly declared) properties are deprecated as of PHP 8.2 and are expected to become a fatal error in PHP 9.0.
* A [https://www.youtube.com/live/vDZWepDQQVE?feature=share&t=10097 live open public working session] where these changes were discussed and agreed to.
* [https://wiki.php.net/rfc/deprecate_dynamic_properties PHP RFC: Deprecate dynamic properties.]
Follow-up to [28525], [31135].
Props antonvlasenko, rajinsharwar, jrf, markjaquith, hellofromTonya, SergeyBiryukov, desrosj, peterwilsoncc, audrasjb, costdev, oglekler, jeffpaul.
Fixes#58898.
See #56034.
git-svn-id: https://develop.svn.wordpress.org/trunk@56354 602fd350-edb4-49c9-b593-d223f7449a82
The unknown use of unknown dynamic property within the `WP_User_Query` property magic methods is now deprecated. A descriptive deprecation notice is provided to alert developers to declare the property on the child class extending `WP_User_Query`.
Changes in this commit:
* Adds a deprecation notice to the `__get()`, `__set()`, `__isset()`, `__unset()` magic methods, i.e. to alert and inform developers when attempting to get/set/isset/unset a dynamic property.
* Fixes `__get()` to explicitly returns `null` when attempting to get a dynamic property.
* Fixes `__set()` by removing the value return after setting a declared property, as (a) unnecessary and (b) `__set()` should return `void` [https://www.php.net/manual/en/language.oop5.overloading.php#object.set per the PHP handbook].
* Fixes `__isset()` to return `false` if not in the `$compat_fields`, as `isset()` and `__isset()` should always return `bool`:
* [https://www.php.net/manual/en/language.oop5.overloading.php#object.isset `__isset()` in the PHP manual]
* [https://www.php.net/manual/en/function.isset.php `isset()` in the PHP manual]
* Adds unit tests for happy and unhappy paths.
For backward compatibility, no changes are made to the internal declared properties listed in `$compat_fields` and accessed through the magic methods.
For example:
A child class uses a property named `$data` that is not declared as a property on the child class. When getting its value, e.g. `$user_query->data`, the `WP_User_Query::__get()` magic method is invoked, the following deprecation notice thrown, and `null` returned:
>The property `data` is not declared. Setting a dynamic property is deprecated since version 6.4.0! Instead, declare the property on the class.
=== Why not remove the magic methods, remove the `$compat_fields` property, and restore the properties `public`?
tl;dr Backward compatibility.
If a plugin adds a property to `$compat_fields` array, then sites using that plugin would experience (a) an `Undefined property` `Warning` (PHP 8) | `Notice` (PHP 7) and (b) a possible change in behavior.
=== Why not limit the deprecation for PHP versions >= 8.2?
tl;dr original design intent and inform
The magic methods and `$compat_fields` property were added for one purpose: to continue providing external access to internal properties declared on `WP_User_Query`. They were not intended to be used for dynamic properties.
Deprecating that unintended usage both alerts developers a change is needed in their child class and informs them what to change.
References:
* Dynamic (non-explicitly declared) properties are deprecated as of PHP 8.2 and are expected to become a fatal error in PHP 9.0.
* A [https://www.youtube.com/live/vDZWepDQQVE?feature=share&t=10097 live open public working session] where these changes were discussed and agreed to.
* [https://wiki.php.net/rfc/deprecate_dynamic_properties PHP RFC: Deprecate dynamic properties.]
Related to #14579, #27881, #30891.
Follow-up to [15491], [28528], [31144].
Props antonvlasenko, rajinsharwar, jrf, markjaquith, hellofromTonya, SergeyBiryukov, desrosj, peterwilsoncc, audrasjb, costdev, oglekler, jeffpaul.
Fixes#58897.
See #56034.
git-svn-id: https://develop.svn.wordpress.org/trunk@56353 602fd350-edb4-49c9-b593-d223f7449a82
This is a micro-optimization that removes a few unnecessary function calls.
Follow-up to [31188], [34369], [38986], [41159], [43211], [43230], [44606], [45757].
Props ayeshrajans, jrf, rajinsharwar, costdev, mukesh27, SergeyBiryukov.
Fixes#58943.
git-svn-id: https://develop.svn.wordpress.org/trunk@56352 602fd350-edb4-49c9-b593-d223f7449a82
The unknown use of unknown dynamic property within the `WP_List_Table` property magic methods is now deprecated. A descriptive deprecation notice is provided to alert developers to declare the property on the child class extending `WP_List_Table`.
Changes in this commit:
* Adds a deprecation notice to the `__get()`, `__set()`, `__isset()`, `__unset()` magic methods, i.e. to alert and inform developers when attempting to get/set/isset/unset a dynamic property.
* Fixes `__get()` to explicitly returns `null` when attempting to get a dynamic property.
* Removes returning the value when setting a declared property, as (a) unnecessary and (b) `__set()` should return `void` [https://www.php.net/manual/en/language.oop5.overloading.php#object.set per the PHP handbook].
* Adds unit tests for happy and unhappy paths.
For backward compatibility, no changes are made to the internal declared properties listed in `$compat_fields` and accessed through the magic methods.
For example:
A child class uses a property named `$data` that is not declared / defined as a property on the child class. When getting its value, e.g. `$list_table->data`, the `WP_List_Table::__get()` magic method is invoked, the following deprecation notice thrown, and `null` returned:
>The property `data` is not defined. Setting a dynamic (undefined) property is deprecated since version 6.4.0! Instead, define the property on the class.
=== Why not remove the magic methods, remove the `$compat_fields` property, and restore the properties `public`?
tl;dr Backward compatibility.
Several plugins, one of which has over 5M installs, add a property to the `$compat_fields` array. Removing the property would cause an `Undefined property` `Warning` (PHP 8) | `Notice` (PHP 7) to be thrown. Removing the associated code would change the functionality.
=== Why not limit the deprecation for PHP versions >= 8.2?
tl;dr original design intent and inform
The magic methods and `$compat_fields` property were added for one purpose: to continue providing external access to internal properties declared on `WP_List_Table`. They were not intended to be used for dynamic properties.
Deprecating that unintended usage both alerts developers a change is needed in their child class and informs them what to change.
References:
* Dynamic (non-explicitly declared) properties are deprecated as of PHP 8.2 and are expected to become a fatal error in PHP 9.0.
* A [https://www.youtube.com/live/vDZWepDQQVE?feature=share&t=10097 live open public working session] where these changes were discussed and agreed to.
* [https://wiki.php.net/rfc/deprecate_dynamic_properties PHP RFC: Deprecate dynamic properties.]
Related to #14579, #22234, #30891.
Follow-up to [15491], [28493], [28521], [28524], [31146].
Props antonvlasenko, jrf, markjaquith, hellofromTonya, SergeyBiryukov, desrosj, peterwilsoncc, audrasjb, costdev, oglekler, jeffpaul.
Fixes#58896.
See #56034.
git-svn-id: https://develop.svn.wordpress.org/trunk@56349 602fd350-edb4-49c9-b593-d223f7449a82
Fixes `WP_List_table` tests leaking into other tests by:
* Restores the original `$hook_suffix` global value.
Rather than modifying the global for all tests, it now restores the original value between tests. Why? To ensure each test starts at a known state.
* Uses a new instance of `WP_List_Table` for each test.
A test may modify the `$list_table` object. If it does, it could impact tests yet to run. By instantiating a new instance in the `set_up()` test fixture, each test is isolated from the others.
Follow-up to [53868], [54215].
Props hellofromTonya, antonvlasenko.
See #58955, #58896.
git-svn-id: https://develop.svn.wordpress.org/trunk@56348 602fd350-edb4-49c9-b593-d223f7449a82
While the `wp_get_loading_optimization_attributes()` function was only recently introduced in 6.3, its code was mostly ported over from the now deprecated `wp_get_loading_attr_default()` function introduced in 5.5.
That function started out in a simple way, but over time was expanded with more and more conditionals on when to avoid lazy-loading, which ended up making the logic extremely complex and hard to follow.
This changeset refactors the logic to simplify it, in a way that allows to follow it more sequentially, and without making any functional changes, ensuring that the extensive existing unit test coverage still passes. This will facilitate future enhancements to the function to be less error-prone and make it more accessible to new contributors.
Props flixos90, joemcgill.
Fixes#58891.
git-svn-id: https://develop.svn.wordpress.org/trunk@56347 602fd350-edb4-49c9-b593-d223f7449a82
In this patch we're introducing support for the SPAN element, which is the first
in the class of "any other tag" in the "in body" insertion mode.
This patch introduces the mechanisms required to handle that class of tags but
only introduces SPAN to keep the change focused. With the tests and mechanisms
in place it will be possible to follow-up and add another limited set of tags.
It's important that this not use the default catch-all in the switch handling
`step_in_body` because that would catch tags that have specific rules in previous
case statements that aren't yet added. For example, we don't want to treat the
`TABLE` element as "any other tag".
Props dmsnell.
Fixes#58907.
git-svn-id: https://develop.svn.wordpress.org/trunk@56331 602fd350-edb4-49c9-b593-d223f7449a82
In order to comply with the test class naming scheme set forth in #56846, rename the test classes covering the HTML API by changing the `wp` infix to `Wp`.
Props dmsnell, costdev.
Fixes#58899. See #56846.
git-svn-id: https://develop.svn.wordpress.org/trunk@56299 602fd350-edb4-49c9-b593-d223f7449a82
Adds raw title property when loading the navigation fallback with an embed context.
Props ramonopoly, get_dave, scruffian, mukesh27, audrasjb.
Fixes#58557.
git-svn-id: https://develop.svn.wordpress.org/trunk@56296 602fd350-edb4-49c9-b593-d223f7449a82
This addresses a `new stdClass()` instance in `_get_non_cached_ids()` tests.
Follow-up to [55543].
Props jrf.
See #58831.
git-svn-id: https://develop.svn.wordpress.org/trunk@56281 602fd350-edb4-49c9-b593-d223f7449a82
This patch introduces the //first// of //many// iterations on the evolution of the HTML API, the HTML Processor, which is built in order to understand HTML structure including nesting, misnesting, and complicated semantic rules.
In the first iteration, the HTML Processor is arbitrarily limited to a minimal subset of functionality so that we can review it, ship it, test it, and collect feedback before moving forward. This means that this patch is more or less an extension to the Tag Processor query language, providing the ability not only to scan for a tag of a given name, but also to find an HTML element in a specific nesting path.
The HTML Processor also aborts any time it encounters:
- a tag that isn't a `P`, `DIV`, `FIGURE`, `FIGCAPTION`, `IMG`, `STRONG`, `B`, `EM`, `I`, `A`, `BIG`, `CODE`, `FONT`, `SMALL`, `STRIKE`, `TT`, or `U` tag. this limit exists because many HTML elements require specific rules and we are trying to limit the number of rules introduced at once. this work is targeted at existing work in places like the image block.
- certain misnesting constructs that evoke complicated resolution inside the HTML spec. where possible and where simple to do reliably, certain parse errors are handled. in most cases the HTML Processor aborts.
The structure of the HTML Processor is established in this patch. Further spec-compliance comes through filling out //more of the same// kind and nature of code as is found in this patch. Certain critical HTML algorithms are partially supported, and where support requires more than is present, the HTML Processor acknowledges this and refuses to operate.
In this patch are explorations for how to verify that new HTML support is fully added (instead of allowing for partial updates that leave some code paths non-compliant). Performance is hard to measure since support is so limited at the current time, but it should generally follow the performance of the Tag Processor somewhat close as the overhead is minimized as much as practical.
Props dmsnell, zieladam, costdev.
Fixes#58517.
git-svn-id: https://develop.svn.wordpress.org/trunk@56274 602fd350-edb4-49c9-b593-d223f7449a82
Previously, Imagick uploads of PDF files with non-opaque alpha channels would result in a black background replacing alpha in the generated thumbnail. This patch adds a `remove_pdf_alpha_channel()` function in the Imagick classes to use a white background instead.
Props gitlost, joemcgill, joedolson, launchinteractive, emirpprime, mwtsn, ceer, maysi, madejackson, 6adminit, costdev, oglekler.
Fixes#39216.
git-svn-id: https://develop.svn.wordpress.org/trunk@56271 602fd350-edb4-49c9-b593-d223f7449a82
Test that `commentId` context is correctly set and made available by the Comment Template block to the `render_block_context` filter (at priority 2 and higher), and to the `render_block` filter (important when programmatically inserting child blocks into the Comment Template block).
Furthermore, test that child blocks inserted via the `render_block_data` filter are retained and thus present at `render_block` filter stage.
Props andrewserong, ramonopoly, peterwilsoncc, costdev, mukesh27, flixos90.
Fixes#58839.
git-svn-id: https://develop.svn.wordpress.org/trunk@56262 602fd350-edb4-49c9-b593-d223f7449a82
This changeset resolves a bug where WordPress would only allow HTML elements within core's own blocks to be styled in `theme.json`. Prior to this change, any `theme.json` rules applying to elements in custom blocks were ignored. With this fix it is now possible to style third-party block elements in `theme.json`.
Props flixos90, azaozz, costdev, glendaviesnz, spacedmonkey, oandregal.
Fixes#57868.
git-svn-id: https://develop.svn.wordpress.org/trunk@56254 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@56249 602fd350-edb4-49c9-b593-d223f7449a82
This changeset fixes a PHP notice appearing when a template part is created in the site editor. It also adds a unit test case to cover
`WP_REST_Templates_Controller::prepare_item_for_database`.
Props wildworks, dunhakdis, Rahmohn, oglekler, audrasjb, mukesh27, costdev, dunhakdis.
Fixes#57851.
git-svn-id: https://develop.svn.wordpress.org/trunk@56248 602fd350-edb4-49c9-b593-d223f7449a82
This is a follow-up to [56092], which further improves PHPUnit test coverage and inline docs for ensuring `async` and `defer` attributes are being properly handled for scripts that are printed without being enqueued.
Props peterwilsoncc, azaozz, westonruter, joemcgill.
See #58648.
git-svn-id: https://develop.svn.wordpress.org/trunk@56246 602fd350-edb4-49c9-b593-d223f7449a82
