The theme includes styles for the spacer block for the front which appears to be unnecessary:
* It adds `display: block` even though that is the default.
* It removes top and bottom margin, even though this is not needed in the post content because of collapsing margins between blocks.
* It uses a custom CSS property to force a specific height on mobile. This affects the patterns in the theme negatively.
It also causes styling problems:
* When the spacer block has a height set to `0` in the navigation block, as the theme forces this to be larger on smaller screens.
* When the block is horizontal. Horizontal was not an option when this style was added.
Consequences of removal:
* Removing the use of the custom CSS property will cause a style change for websites that have adjusted the spacing property.
Follow-up to [49216], [49574].
Props poena, mukesh27.
Fixes#56222.
Built from https://develop.svn.wordpress.org/trunk@54103
git-svn-id: http://core.svn.wordpress.org/trunk@53662 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Adds support for the following CSS properties considered safe for inline CSS:
* `flex-wrap`
* `gap`
* `column-gap`
* `row-gap`
Extends support for `margin` and `padding` to include logical properties:
* `margin-block-start`
* `margin-block-end`
* `margin-inline-start`
* `margin-inline-end`
* `padding-block-start`
* `padding-block-end`
* `padding-inline-start`
* `padding-inline-end`
Follow-up to [46235].
Props andrewserong, peterwilsoncc, ramonopoly, bernhard-reiter.
Fixes#56122.
Built from https://develop.svn.wordpress.org/trunk@54102
git-svn-id: http://core.svn.wordpress.org/trunk@53661 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Additionally, this commit updates `safecss_filter_attr()` to add support for nested `var()` functions, so that a fallback value can be another CSS variable.
Follow-up to [50923].
Props johnregan3, noisysocks, cbravobernal, uxl, isabel_brison, andrewserong, ramonopoly, joyously, bernhard-reiter, peterwilsoncc.
Fixes#55966.
Built from https://develop.svn.wordpress.org/trunk@54100
git-svn-id: http://core.svn.wordpress.org/trunk@53659 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The existing filter `image_editor_output_format` receives an additional parameter `$size_name` which is populated whenever it controls the output format for a specific registered image size to create. Otherwise, it remains empty. In order to achieve this, a low level change has been added in bringing a new `$size_name` class property to the `WP_Image_Editor` base class, which is introduced in a backward compatible way that will not cause conflicts with custom implementations.
This parameter is then used in new logic inside the `wp_default_image_output_mapping()` callback function for the filter, controlling whether `image/jpeg` should map to `image/webp` output or not. By default, this is enabled for all WordPress core image sizes by default, and this list can be modified using a new `wp_image_sizes_with_additional_mime_type_support` filter, e.g. to remove core sizes or add custom sizes.
The customization per image size may be further enhanced by providing a more declarative API via a new parameter on the `add_image_size()` function.
Props eugenemanuilov, flixos90, adamsilverstein, joegrainger.
Fixes#56526.
See #55443, #56288.
Built from https://develop.svn.wordpress.org/trunk@54097
git-svn-id: http://core.svn.wordpress.org/trunk@53656 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The `amd64/mysql` and `amd64/mariadb` official images from Docker are also compatible with an x64 host machine which means they can be used by default instead of only when the host uses ARM64.
Props bernhard-reiter, czapla, gmovr, withinboredom
Fixes#56528
Built from https://develop.svn.wordpress.org/trunk@54096
git-svn-id: http://core.svn.wordpress.org/trunk@53655 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This is a test fixture (dummy class only used in a test context), which incorrectly implements the magic methods.
With the deprecation of dynamic properties in PHP 8.2, this needs to be fixed.
The new implementation represents a “proper” implementation of the magic methods for a class without non-`public` or typed properties.
Notes:
* Instead of relying on dynamic properties, the magic methods now store properties in a `private` `$arbitrary_props` array and retrieve them from there as well.
* The original `$foo` property, even though declared as `private`, was never `private` in practice due to the way the magic methods were originally implemented. In effect, it was fully publicly retrievable and modifiable without any (type) restrictions. With that in mind, the `foo` property has been moved into the `$arbitrary_props` array to keep the implementation of the magic methods as clean and straightforward as possible. With the adjusted magic methods, access to and modification of `$foo` will (on the surface) continue to work in the same way as before, while under the hood, it is no longer affected by the dynamic properties deprecation.
* Take note of the use of `array_key_exists()` instead of `isset()` in the `__get()` method. This is intentional and allows for `null` values to be stored and retrieved.
* Also take note of `__set()` method no longer returning. `__set()` is supposed to be a `void` method. In practice, the return value would always be ignored due to how PHP handles magic methods, so in effect, this change will not make any difference and does not constitute a backward compatibility break.[[BR]][[BR]]
> The return value of `__set()` is ignored because of the way PHP processes the assignment operator.
Alternatives considered:
* Instead of fixing the magic methods, they could have been removed instead and the class be made to `extend` `stdClass`. It has been chosen not to do so for two reasons:
1. It’s kind of nice to have at least ''one'' correct implementation of magic methods in WP, which can be used as an example to point to as well.
2. Extending `stdClass` would change the class hierarchy, which ''may'' or ''may not'' affect the tests using this fixture (depending on what’s being done with the class). Extending `stdClass` would also obfuscate what’s going on in the class and would require extensive documentation to prevent the extension being inadvertently removed at a future point in time.
* Instead of fixing the magic methods, the test fixture could have been deprecated and/or removed, with the few tests which use the fixture being updated to use `stdClass` for their test fixture instead. It has been chosen not to do so as there may well be external (plugin/theme) tests relying on this test fixture and evaluating whether that is so would be hard, as WP Directory cannot be used, since test code is normally not included in the code published on wp.org. Also note, there is still a (deprecated) `Basic_Subclass` fixture in the test suite, which extends this class.
These magic methods and the `Basic_Object` test fixture were originally introduced in [28480] and [28523]. The fixture was deprecated in [42381] and undeprecated again in [45807].
At this time, the test fixture is used in the `WP_Test_REST_Post_Meta_Fields` and the `Tests_REST_API` test classes.
References:
* [https://www.php.net/manual/en/language.oop5.overloading.php#object.set PHP Manual: Overloading: __set()]
* [https://wiki.php.net/rfc/deprecate_dynamic_properties PHP RFC: Deprecate dynamic properties]
* [https://github.com/php/php-src/issues/7786 php-src: #7786 PHP 8.2: unexpected deprecation for dynamic property set via magic method]
Follow-up to [28480], [28493], [28523], [42381], [45807].
Props jrf, costdev.
See #56514.
Built from https://develop.svn.wordpress.org/trunk@54095
git-svn-id: http://core.svn.wordpress.org/trunk@53654 1a063a9b-81f0-0310-95a4-ce76da25c4cd
While the `image_editor_output_format` filter is primarily used in WP Admin, it can also be executed in frontend scope, as the related `WP_Image_Editor` class and `wp_unique_filename()` function are being loaded in that scope.
Follow up to [54086].
See #55443, #56526.
Built from https://develop.svn.wordpress.org/trunk@54094
git-svn-id: http://core.svn.wordpress.org/trunk@53653 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This replaces all references to the `WP_UnitTestCase_Base::$factory` property with static function calls to the `WP_UnitTestCase_Base::factory()` method.
This is a consistency improvement for the test suite.
Follow up to [35225], [35242], [49603], [54087], [54088].
Props jrf.
See #55652.
Built from https://develop.svn.wordpress.org/trunk@54090
git-svn-id: http://core.svn.wordpress.org/trunk@53649 1a063a9b-81f0-0310-95a4-ce76da25c4cd
In [53164] the `clipboard.js` library was updated to from version 2.0.8 to 2.0.10, and in doing so caused a TypeError JavaScript error to be thrown when the copy button for debug information was used.
With the update, the `clipboard.js` library introduced an enhancement to its `.copy()` API, which now removes the fake DOM element used for copying content, which Site Health previously had to remove manually.
As this fake DOM element is now removed automatically, the copy function within the debug information screen can rely on the library performing the removal, instead of WordPress needing to do so manually.
Props hiren1094, costdev.
Fixes#56515.
Built from https://develop.svn.wordpress.org/trunk@54089
git-svn-id: http://core.svn.wordpress.org/trunk@53648 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This replaces all non-static calls to the `WP_UnitTestCase_Base::factory()` method with static function calls, since the method is declared as static.
This is a consistency improvement for the test suite.
Follow up to [35225], [35242], [49603], [54087].
Props jrf.
See #55652.
Built from https://develop.svn.wordpress.org/trunk@54088
git-svn-id: http://core.svn.wordpress.org/trunk@53647 1a063a9b-81f0-0310-95a4-ce76da25c4cd
These magic methods were introduced to prevent a backward compatibility break, but in actual fact:
1. ''Caused'' a backward compatibility break. The original `$factory` property was a `static` property and this declared property was replaced by the magic methods. Unfortunately, it was not realized at the time that these magic methods **''are not called for static property access''**.[[BR]][[BR]]
> Property overloading only works in object context. These magic methods will not be triggered in static context.
And as approaching a static property in a non-static manner is [https://3v4l.org/93HQL not supported in PHP], this effectively created a backward compatibility break instead of preventing it.
2. Were hiding errors in tests, as the magic methods would be invoked for non-existent properties and would return `null` (get) or `false` (isset). See [54040], [54041], and [54077] for bug fixes related to this.
3. Are problematic in relation to PHP 8.2, as the implementation is incomplete, does not protect against dynamic properties and hides PHP notices about undefined properties.
Now, there were several options to mitigate this:
1. Revert the original commit. This would be problematic, as the ''non-static'' version of these properties has now been supported for 7 years, so this would create a new backward compatibility break.
2. Improve the magic methods. With all the issues with magic methods (see the discussion in the [https://www.youtube.com/watch?v=vDZWepDQQVE livestream from August 16, 2022], this would probably cause more problems than it’s worth and would make for a much more complex implementation, which is over the top for this relatively simple functionality, especially in the context of a test suite.
3. Remove the magic methods without adding the property. This would again cause a backward compatibility break, though one for which the mitigation solution would be relatively straightforward, i.e. to replace property access using `$this->factory` with a function call `$this->factory()` (or `self::factory()`, as the method is declared as static). While we can (and have in a subsequent commit) mitigate this for the WP Core test suite, mitigating this for plugin or theme integration tests is outside of our purview and they would still need to deal with this backward compatibility break.
4. The current solution: removing the magic methods, explicitly declaring the (non-static) property and setting it in the `set_up()` method. This does not constitute a backward compatibility break with the functionality as it was over the past 7 years. Setting the property in `set_up()` may be “late”, but that is the earliest place in which the property can be set as non-static. If the factory would be needed prior to `set_up()`, the (static) `WP_UnitTestCase_Base::factory()` method should be called directly. This is no different from how this functionality behaved over the past 7 years.
Note: The property is straight away marked as “deprecated”, since the method should be favored over the use of the property.
Reference: [https://www.php.net/manual/en/language.oop5.overloading.php#object.get PHP Manual: Property overloading: __get()]
Follow-up to [35225], [35242].
Props jrf, costdev.
See #56514.
Built from https://develop.svn.wordpress.org/trunk@54087
git-svn-id: http://core.svn.wordpress.org/trunk@53646 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Uploaded JPEGs will automatically be converted to WebP sub-sizes instead of JPEG, saving space and making sites faster.
The original JPEG upload is always retained and can be accessed by calling `wp_get_original_image_url`.
Props azaozz, flixos90.
Fixes#55443.
Built from https://develop.svn.wordpress.org/trunk@54086
git-svn-id: http://core.svn.wordpress.org/trunk@53645 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
This affects:
* `Tests_Rewrite_OldDateRedirect`
* `Tests_Rewrite_OldSlugRedirect`
This commit updates the latter test class to create a post in the `wpSetUpBeforeClass()` method, for consistency with the former class. This ensures that both classes declare the `$post_id` property as `static`, to avoid a situation where non-static access is accidentally used when copying similar test cases from one class to the other.
Follow-up to [34659], [42587], [54077].
See #55652.
Built from https://develop.svn.wordpress.org/trunk@54078
git-svn-id: http://core.svn.wordpress.org/trunk@53637 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This affects:
* `Tests_Rewrite_OldDateRedirect::test_old_date_redirect_cache_invalidation()`
* `Tests_Rewrite_OldSlugRedirect::test_old_slug_redirect_cache_invalidation()`
In the former test, the `$post_id` property is declared as `static`, so can only be approached as static, even when used within the same class in which the property is declared.
Using non-static access will result in `null`. See: https://3v4l.org/93HQL
This PHP notice was hidden so far, due to the existence of magic methods in the `WP_UnitTestCase_Base class`.
All the same, the magic methods as they were, would also return `null` for this property. All in all, the post being updated for this test would never get the correct `post_id`.
Fixed by using static access to approach the `static` property.
On a related note, the described bug fix (using the actual `$post_id` instead of `null`) exposed that this test was as a matter of fact failing. This was just hidden by the first bug.
Based on the original commit introducing the test, an adjustment is now made which appears to be what the test actually ''intended'' to test. A similar change is made to the cache invalidation test for old slug redirects. While not strictly required, it brings some consistency between the two tests and ensures that both tests use a unique `post_name` value to avoid collisions with the previous values.
This bug was discovered while fixing (removing) the magic methods in the `WP_UnitTestCase_Base` class in an effort to improve compatibility with PHP 8.2.
Follow-up to [53549].
Props jrf, costdev, SergeyBiryukov.
See #55652.
Built from https://develop.svn.wordpress.org/trunk@54077
git-svn-id: http://core.svn.wordpress.org/trunk@53636 1a063a9b-81f0-0310-95a4-ce76da25c4cd
These tests should check the initial `$mysql_recommended_version` and `$mariadb_recommended_version` properties, as `WP_Site_Health::prepare_sql_data()` redefines the former with the latter to simplify further processing if MariaDB is used, leading to a test failure:
{{{
Tests_Site_Health::test_mysql_recommended_version_matches_readme_html
Failed asserting that two strings are identical.
--- Expected
+++ Actual
@@ @@
-'5.7'
+'10.3'
}}}
This commit uses the initial property values to ensure the correct versions are being compared.
Follow-up to [54069].
See #55791.
Built from https://develop.svn.wordpress.org/trunk@54076
git-svn-id: http://core.svn.wordpress.org/trunk@53635 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This test verifies that the WordPress `readme.html` file recommends a PHP version that is actively supported. However, WordPress currently still recommends PHP 7.4 due to PHP 8.0/8.1 compatibility not being fully achieved, even though PHP 7.4 is end-of-life.
As things were, the assertion in the test was commented out, leading to this test being marked as “risky” for not performing any assertions.
Instead, let’s skip the test with a clear skip notification.
Follow-up to [52260].
Props jrf.
See #55652.
Built from https://develop.svn.wordpress.org/trunk@54074
git-svn-id: http://core.svn.wordpress.org/trunk@53633 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This affects `Tests_Ajax_MediaEdit::testImageEditOverwriteConstant()`.
In case the `$files_that_should_not_exist` file list is empty, the test would be marked as risky, since it would not perform any assertions.
This small tweak prevents that from happening.
Follow-up to [38113].
Props jrf.
See #55652.
Built from https://develop.svn.wordpress.org/trunk@54073
git-svn-id: http://core.svn.wordpress.org/trunk@53632 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This affects the following test groups:
* Ajax tests
* ms-files tests
* External HTTP tests
* Xdebug tests
The tests being run in these particular test groups are passing on PHP 8.1, however, the test runs are still allowed to “continue on error”. This creates the risk that new PHP 8.1 incompatibilities will be introduced without anyone noticing.
By no longer allowing these test runs to “continue on error”, that risk is removed.
Follow-up to [51588], [51604], [53922].
Props jrf.
See #55656, #55652.
Built from https://develop.svn.wordpress.org/trunk@54072
git-svn-id: http://core.svn.wordpress.org/trunk@53631 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This renames some variables for clarity, per the [https://developer.wordpress.org/coding-standards/wordpress-coding-standards/php/#naming-conventions Naming Conventions]:
> Don’t abbreviate variable names unnecessarily; let the code be unambiguous and self-documenting.
* `$out` is renamed to `$output` in various list table methods and admin functions.
* `$sep` is renamed to `$separator` in various list table methods and admin functions.
This affects:
* `WP_Comments_List_Table::handle_row_actions()`
* `WP_List_Table::row_actions()`
* `WP_Media_List_Table::column_default()`
* `WP_MS_Sites_List_Table::site_states()`
* `WP_MS_Users_List_Table::column_blogs()`
* `WP_Terms_List_Table::column_name()`
* `_wp_dashboard_recent_comments_row()`
* `image_align_input_fields()`
* `image_size_input_fields()`
* `wp_doc_link_parse()`
* `_post_states()`
* `_media_states()`
Follow-up to [8653], [8692], [8864], [8910], [8911], [8916], [9103], [9153], [10607], [15491], [17793], [32644], [54070].
Props mukesh27, costdev.
See #56448, #55647.
Built from https://develop.svn.wordpress.org/trunk@54071
git-svn-id: http://core.svn.wordpress.org/trunk@53630 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* MySQL 5.6 has reached EOL (“End of Life”) in February 2021. The recommended minimum is bumped to 5.7 for now.
* MariaDB 10.2 has reached EOL in May 2022. The recommended minimum is bumped to 10.3 for now.
This commit brings the Site Health recommendations in line with `readme.html`.
Includes:
* Adding two unit tests to ensure the SQL server versions recommended by Site Health match `readme.html`.
* Consistently declaring the recommended and required versions as the `WP_Site_Health` class properties.
* Renaming some pre-existing private properties for clarity.
Follow-up to [44986], [52319], [52358], [52420], [52424], [53431], [53433], [53435], [meta11407], [meta11866].
See #55791, #meta5999, #meta6322.
Built from https://develop.svn.wordpress.org/trunk@54069
git-svn-id: http://core.svn.wordpress.org/trunk@53628 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This affects:
* `test_user_without_publish_posts_cannot_affect_sticky()`
* `test_user_without_publish_posts_cannot_affect_sticky_with_edit_post()`
In both tests, the user is now set after creating the post, not before. This aims to better match the intention of the tests, as they ensure that a sticky status is unaffected for a post that is ''edited'' by a user without the `publish_posts` capability, not necessarily ''created'' by that user.
Includes minor documentation updates for consistency.
Follow-up to [33096], [35183].
See #55652.
Built from https://develop.svn.wordpress.org/trunk@54068
git-svn-id: http://core.svn.wordpress.org/trunk@53627 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This avoids a "Sorry, you are not allowed to edit this post" error further in the test. The test is currently skipped on GitHub Actions, as only runs on older MySQL versions specifically with the `utf8` character set.
The user was previously set for all tests in the file in the `set_up()` method, however that is no longer the case, as it was not required for the majority of the tests. It is, however, necessary for the `edit_post()` call in this particular test.
Follow-up to [30346], [53785].
See #55652.
Built from https://develop.svn.wordpress.org/trunk@54067
git-svn-id: http://core.svn.wordpress.org/trunk@53626 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Introduces the filter `wp_post_class_taxonomies` to allow developers to bypass the generation of term based classes with the `get_post_class()` function.
Developers can use this filter to reduce the number of taxonomies for which classes term classes are generated. This can improve performance on sites with a large number of custom taxonomies.
Props boonebgorges, bordoni, davidbaumwald, desrosj, invelity, mukesh27, sebastianpisula, steveo2000, swissspidy, system909, tlovett1, xparham.
Fixes#37114.
Built from https://develop.svn.wordpress.org/trunk@54066
git-svn-id: http://core.svn.wordpress.org/trunk@53625 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This updates an older fragment in `WP_Site_Health::prepare_sql_data()` to use a dedicated `$wpdb` method introduced later in WordPress 5.5 specifically for retrieving the database server information.
Follow-up to [44986], [47451].
Props hilayt24, mukesh27, Clorith, SergeyBiryukov.
Fixes#56484.
Built from https://develop.svn.wordpress.org/trunk@54065
git-svn-id: http://core.svn.wordpress.org/trunk@53624 1a063a9b-81f0-0310-95a4-ce76da25c4cd
These tags were previously removed to avoid notices when generating the code coverage report on PHP versions where these functions are natively available and not user-defined:
{{{
"@covers ::array_key_first" is invalid
"@covers ::array_key_last" is invalid
"@covers ::hash_hmac" is invalid
"@covers ::is_countable" is invalid
"@covers ::is_iterable" is invalid
"@covers ::mb_strlen" is invalid
"@covers ::mb_substr" is invalid
"@covers ::str_contains" is invalid
"@covers ::str_ends_with" is invalid
"@covers ::str_starts_with" is invalid
}}}
It has been pointed out that those tests do cover the WP implementation of those functions and should be marked as such with a `@covers` tag. The reason PHPUnit displays notices about it, is that code coverage is only run on PHP 7.4 instead of multiple PHP versions.
For those PHP versions which don't natively contain the function, the WP polyfill is being tested and should be seen as covered by tests. The reason the tests are also run on PHP versions in which the function already exists in PHP natively, is to make sure that the polyfill test expectations line up with the PHP native behaviour, even though at that point, they are no longer testing the WP polyfill, but the PHP native function.
With the above in mind, while those PHPUnit notices add some noise to the code coverage report, in this case, they should be ignored and the `@covers` tags should be brought back.
As a potential future enhancement, the code coverage script could be updated to run against the highest and lowest supported PHP versions and with some variations of extensions enabled or disabled to ensure those tests actually test the polyfills.
Follow-up to [51852], [52038], [52039], [52040], [54049], [54060].
Props jrf.
See #39265, #55652.
Built from https://develop.svn.wordpress.org/trunk@54064
git-svn-id: http://core.svn.wordpress.org/trunk@53623 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* Some assertions were unnecessarily duplicated. They aim to test the function behavior both when passing a term ID and term object, however that is already handled via the `$use_id` parameter of the `get_term()` helper in the same test class. The data providers already supply test cases both with a term ID and term object, so there is no need for a second assertion or a whole second test method with a term object.
* One `get_term_feed_link()` test was unnecessarily skipped half of the time, when term object was passed instead of term ID. Instead, it can use a dedicated data provider and avoid skipping.
Includes:
* Using more descriptive test method names to clarify the intention of the tests.
* Some documentation updates for clarity.
Follow-up to [52180], [52255], [52258], [52305], [53833], [53836].
See #55652.
Built from https://develop.svn.wordpress.org/trunk@54061
git-svn-id: http://core.svn.wordpress.org/trunk@53620 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The `@covers` tags for these tests were previously removed to avoid notices when generating the code coverage report on PHP versions where these functions are natively available and not user-defined:
{{{
"@covers ::array_key_first" is invalid
"@covers ::array_key_last" is invalid
"@covers ::hash_hmac" is invalid
"@covers ::is_countable" is invalid
"@covers ::is_iterable" is invalid
"@covers ::mb_strlen" is invalid
"@covers ::mb_substr" is invalid
"@covers ::str_contains" is invalid
"@covers ::str_ends_with" is invalid
"@covers ::str_starts_with" is invalid
}}}
Explicitly including a `@coversNothing` annotation in this case appears to be a more appropriate option than not including any annotation at all.
Follow-up to [51852], [52038], [52039], [52040], [54049].
See #39265, #55652.
Built from https://develop.svn.wordpress.org/trunk@54060
git-svn-id: http://core.svn.wordpress.org/trunk@53619 1a063a9b-81f0-0310-95a4-ce76da25c4cd
WordPress core test suite uses PHPUnit's `beStrictAboutTestsThatDoNotTestAnything` option set to true, which marks a test as risky when no assertions are performed.
REST API test classes have some empty tests for non-implemented methods because these test classes extend the abstract `WP_Test_REST_Controller_Testcase` class, which requires several methods to be implemented that don't necessarily make sense for all REST API routes.
As these tests are intentionally empty, they were previously marked as skipped, so that they are not reported as risky.
This commit aims to further reduce noise in the test suite and effectively ignores these empty tests altogether, which seems like a more appropriate option at this time.
The `@doesNotPerformAssertions` annotation can be reconsidered in the future when the tests are either removed as unnecessary or updated to actually perform assertions related to their behavior.
Follow-up to [40534], [41176], [41228], [53921].
See #40538, #41463, #55652.
Built from https://develop.svn.wordpress.org/trunk@54058
git-svn-id: http://core.svn.wordpress.org/trunk@53617 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This addresses a notice when generating the code coverage report:
{{{
"@covers WP_REST_URL_Details_Controller::get_routes" is invalid
}}}
The `WP_REST_URL_Details_Controller` class does not have a `get_routes()` method, `WP_REST_Server` does.
Follow-up to [51973].
See #55652.
Built from https://develop.svn.wordpress.org/trunk@54056
git-svn-id: http://core.svn.wordpress.org/trunk@53615 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This addresses a notice when generating the code coverage report:
{{{
"@covers WP_REST_Request::create_item" is invalid
}}}
The `WP_REST_Request` class does not have a `create_item()` method, `WP_REST_Posts_Controller` is the class being tested here.
Includes fixing a typo in the test method name.
Follow-up to [53813].
See #52422, #55652.
Built from https://develop.svn.wordpress.org/trunk@54055
git-svn-id: http://core.svn.wordpress.org/trunk@53614 1a063a9b-81f0-0310-95a4-ce76da25c4cd
