Add an error notice if a user attempts to apply bulk edits with no items selected. Applies to post lists, comments, taxonomies, and plugins screens.
Props garrett-eclipse, nrqsnchz, sumitsingh, nihar007, royho, sabernhardt, oglekler, quadthemes, ankit-k-gupta, fnpen, ukdrahul, joedolson.
Fixes#45006, #58479.
Built from https://develop.svn.wordpress.org/trunk@59134
git-svn-id: http://core.svn.wordpress.org/trunk@58530 1a063a9b-81f0-0310-95a4-ce76da25c4cd
r59091 introduced a backward compatibility (BC) break for a static homepage that includes a shortcode's or block's with paginated content that uses the `'paged'` query var, e.g. bbPress.
In this use case, attempting to navigate the shortcode / block's pagination causes a canonical redirect, rather than navigating to the next page of content within that shortcode or block.
Follow-up to [59091].
Props davidbinda, jjj.
See #50163, #meta5184.
Built from https://develop.svn.wordpress.org/trunk@59133
git-svn-id: http://core.svn.wordpress.org/trunk@58529 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Typically, when registering a new block type, its metadata is read from the provided `block.json` file. The more block types are registered on a site, the more costly becomes this process, as it involves filesystem reads and parsing JSON.
WordPress Core's built-in blocks have in the past worked around that by having a auto-generated PHP manifest file that includes the already parsed JSON data for all blocks. This changeset effectively allows plugins to do the same, by introducing a new API function `wp_register_block_metadata_collection()`. The WordPress Core block manifest is now handled using this API as well, rather than custom logic baked into `register_block_type_from_metadata()`.
The `wp_register_block_metadata_collection()` function requires two parameters:
* `$path`: The base path in which block files for the collection reside.
* `$manifest`: The path to the manifest file for the collection.
Every `block.json` file that is supposed to be part of the collection must reside within the provided `$path`, within its own block-specific directory matching the block name (without the block namespace). For example, for a collection `$path` of `/wp-content/plugins/test-plugin` and a block `test-plugin/testimonial`, the block file could be `/wp-content/plugins/test-plugins/blocks/testimonial/block.json`.
It is recommended that plugins use the new API function for enhanced performance, especially if they register several block types. However, the use of the function is entirely optional. Not using it will not result in any difference in user-facing behavior.
Props mreishus, flixos90, gziolo, spacedmonkey, azaozz, mukesh27.
Fixes#62002.
Built from https://develop.svn.wordpress.org/trunk@59132
git-svn-id: http://core.svn.wordpress.org/trunk@58528 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Introduces the `wp_interactivity_get_element()` function to the Interactivity API, analogous to the `getElement()` function in the `@wordpress/interactivity` JavaScript module. This function allows access to the current element being processed during directive processing.
The function returns an array containing the `attributes` property, which includes only the originally defined attributes present on the element. Attributes added or modified by directive processing are not included. This is intended for use in derived state properties inside `wp_interactivity_state()`, similar to how `wp_interactivity_get_context()` is used.
Example usage:
```php
wp_interactivity_state( 'myPlugin', array(
'buttonText' => function() {
$context = wp_interactivity_get_context();
$element = wp_interactivity_get_element();
return isset( $context['buttonText'] )
? $context['buttonText']
: $element['attributes']['data-default-button-text'];
},
) );
```
Includes unit tests to cover the new functionality.
Props darerodz, swissspidy, cbravobernal, czapla.
Fixes#62136.
Built from https://develop.svn.wordpress.org/trunk@59131
git-svn-id: http://core.svn.wordpress.org/trunk@58527 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Moves the 'loading' and 'loaded' i18n strings for the `interactivity-router` to the script module data via the `script_module_data_@wordpress/interactivity-router` filter.
Key changes:
- Add the `filter_script_module_interactivity_router_data()` method, hooked into the `script_module_data_@wordpress/interactivity-router` filter, to set the `i18n` data with the 'loading' and 'loaded' messages.
- Rename the `print_router_loading_and_screen_reader_markup()` method to `print_router_markup()` and remove the screen reader markup from it because it's no longer needed.
- Deprecate the `print_router_loading_and_screen_reader_markup()` method.
- Remove the `loading` and `loaded` strings from the `core/router` store state because they're no longer needed.
- Initialize the `core/router` store with a minimal navigation object to prevent errors in the interactivity-router script module when the store is not properly initialized.
- Update corresponding unit tests to reflect these changes.
This change ensures that the `interactivity-router` i18n messages are localized in a single place and removes the need to initialize them in the `core/router` store state.
Props jonsurrell, swissspidy, czapla, gziolo.
See #60647.
Built from https://develop.svn.wordpress.org/trunk@59130
git-svn-id: http://core.svn.wordpress.org/trunk@58526 1a063a9b-81f0-0310-95a4-ce76da25c4cd
If sending an email to the site administrator's email address, look up if a user with the same email exists and switch to that user's locale.
If not, falls back to the site locale as usual.
Props benniledl, swissspidy, mukesh27.
Fixes#61518.
Built from https://develop.svn.wordpress.org/trunk@59128
git-svn-id: http://core.svn.wordpress.org/trunk@58524 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Some plugins and themes load translations too early, before the current user is known.
This happens either explicitly or through just-in-time translation loading.
If the current user (and thus their locale) is not known, WordPress might attempt to load translations in the wrong locale.
This change adds `_doing_it_wrong` messages to warn about such cases. It also helps avoiding accidentally trying to load translations twice (once just-in-time and once manually).
Projects triggering such a message are encourage to load translations no earlier than the `after_setup_theme` hook.
Props garrett-eclipse, Kau-Boy, swissspidy, johnbillion, alanfuller. rodelgc.
Fixes#44937.
Built from https://develop.svn.wordpress.org/trunk@59127
git-svn-id: http://core.svn.wordpress.org/trunk@58523 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Remove hardcoded path added in [57922] which ignored the fact that themes can also use script translations.
They should not be affected even if plugins are installed outside the typical `wp-content/plugins` location.
Props itapress, swissspidy.
Fixes#62016.
Built from https://develop.svn.wordpress.org/trunk@59126
git-svn-id: http://core.svn.wordpress.org/trunk@58522 1a063a9b-81f0-0310-95a4-ce76da25c4cd
If a prospective hooked block has its `multiple` block-supports field set to `false` (thus allowing only one instance of the block to be present), ensure that:
1. Only one instance of the block will be inserted if it's not yet present in the current context.
2. The block will not be inserted at all if an instance of it is already present in the current context.
As always in Block Hooks parlance, "context" denotes the containing template, template part, pattern, or navigation post that a hooked block is supposed to be inserted into.
The markup of a webpage that uses a Block Theme typically comprises a number of such contexts -- one template and any number of template parts, patterns, and navigation posts. Note that the limitation imposed by this changeset only applies on a per-context basis, so it's still possible that the resulting page contains more than one instance of a hooked block with `"multiple": false` set, as each context could contribute up to one such instance.
Props bernhard-reiter, jonsurrell, gziolo.
Fixes#61902.
Built from https://develop.svn.wordpress.org/trunk@59124
git-svn-id: http://core.svn.wordpress.org/trunk@58520 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Adds a `canUpdateBlockBindings` editor setting that allows to decide if the user is able to create and modify bindings through the UI. By default, only admin users can do it, but it can be overridden with `block_editor_settings_all` filter.
Props santosguillamot, gziolo, jorbin, noisysocks, matveb, cbravobernal, youknowriad, mamaduka, timothyblynjacobs, peterwilsoncc, drivingralle.
Fixes#61945.
Built from https://develop.svn.wordpress.org/trunk@59122
git-svn-id: http://core.svn.wordpress.org/trunk@58518 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Removes the automatic addition of `rel="noopener noreferrer"` from links targeting a new tab or window, `target='_blank'`. Since this was introduced, supported browsers have changed their security policies and no longer allow the opened link to have JavaScript access to the previous tab.
Deprecates:
* `wp_targeted_link_rel()`
* `wp_targeted_link_rel_callback()`
* `wp_init_targeted_link_rel_filters()`: converted to a noop function
* `wp_remove_targeted_link_rel_filters()`: converted to a noop function
The deprecated functions are retained in `formatting.php` as in `SHORTINIT` mode the file is included while `deprecated.php` is not.
This also removes the `noopener` from links hard coded within the WordPress dashboard linking to documentation and other resources.
Props audrasjb, azaozz, dhruval04, dorzki, neo2k23, presskopp, sabernhardt, swissspidy, tobiasbg.
Fixes#53843.
Built from https://develop.svn.wordpress.org/trunk@59120
git-svn-id: http://core.svn.wordpress.org/trunk@58516 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Introduces the filter `pre_attachment_url_to_postid` to allow developers to short-circuit the function `attachment_url_to_postid()`.
The return values are expected to be an attachment ID, zero (`0`) to indicate no attachment was found or `null` to indicate the function should proceed as usual.
The function performs an expensive database query so developers making use of the function frequently may wish to use a custom table with appropriate indexes to reduce the load on their database server.
Props antpb, apermo, audrasjb, joedolson.
Fixes#61383.
Built from https://develop.svn.wordpress.org/trunk@59118
git-svn-id: http://core.svn.wordpress.org/trunk@58514 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Adds a check for `ABSPATH` to the top of the `/wp-includes/blocks/index.php` file and prevents the file from loading if it is not defined.
This prevents the file from throwing errors when accessed directly.
Props khokansardar, mukesh27.
Fixes#62108.
See #60352.
Built from https://develop.svn.wordpress.org/trunk@59117
git-svn-id: http://core.svn.wordpress.org/trunk@58513 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Introduces post format support for both the Query Block with the new parameter `format`. In the `build_query_vars_from_query_block()` function, this is converted to a `post_format` taxonomy query passed to `WP_Query`.
Also introduces the `format` parameter to the REST API's Posts controller to support the feature in the Query block. The parameter type is an enumerated string accepted the post formats supported by each post type.
Props poena, mukesh27, mamaduka, noisysocks, TimothyBlynJacobs.
Fixes#62014.
Built from https://develop.svn.wordpress.org/trunk@59115
git-svn-id: http://core.svn.wordpress.org/trunk@58511 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This aims to make it easier to enter digits in datetime text fields on mobile devices, instead of opening the full keyboard.
Follow-up to [43], [1506], [2998], [3648], [6078], [6989], [7285], [7338], [20168], [20217], [28730], [32945], [49283].
Props sabernhardt.
Fixes#62109.
Built from https://develop.svn.wordpress.org/trunk@59114
git-svn-id: http://core.svn.wordpress.org/trunk@58510 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Change posts and comments pagination `nav` regions to have an aria-label of "Posts pagination" and "Comments pagination", respectively. This provides improved context for the numeric links contained within these regions and differentiates between posts navigation regions and posts pagination regions.
Props michaelbourne, sabernhardt, afercia, xyulex, webmandesign, tirth03, joedolson.
Fixes#54260.
Built from https://develop.svn.wordpress.org/trunk@59113
git-svn-id: http://core.svn.wordpress.org/trunk@58509 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Add `get_user()` as an alias for `get_user_by( 'id', $user_id )`. Add `get_user()` to `user.php` so it is not a pluggable function. Bring parity with other standard `get_` functions for a more intuitive developer experience.
Props sc0ttkclark, kushang78, joedolson, peterwilsoncc.
Fixes#35124.
Built from https://develop.svn.wordpress.org/trunk@59111
git-svn-id: http://core.svn.wordpress.org/trunk@58507 1a063a9b-81f0-0310-95a4-ce76da25c4cd
PHP 8.4 deprecates the use of `trigger_errror()` with `E_USER_ERROR` as the error level, as there are a number of gotchas to this way of creating a `Fatal Error` (`finally` blocks not executing, destructors not executing).
The recommended replacements are either to use exceptions or to do a hard `exit`.
As this is a test-only class, do not have to take BC-breaks into account.
Also, as this is a test helper, throwing a exception is the most appropriate solution.
Reference:
* https://wiki.php.net/rfc/deprecations_php_8_4#deprecate_passing_e_user_error_to_trigger_error
Follow-up to [25002].
Props jrf.
See #62061.
Built from https://develop.svn.wordpress.org/trunk@59109
git-svn-id: http://core.svn.wordpress.org/trunk@58505 1a063a9b-81f0-0310-95a4-ce76da25c4cd
PHP 8.4 deprecates the use of `trigger_errror()` with `E_USER_ERROR` as the error level, as there are a number of gotchas to this way of creating a `Fatal Error` (`finally` blocks not executing, destructors not executing).
The recommended replacements are either to use exceptions or to do a hard `exit`.
As this is a test-only class, do not have to take BC-breaks into account.
Also, as this is a test helper, throwing a exception is the most appropriate solution.
Reference:
* https://wiki.php.net/rfc/deprecations_php_8_4#deprecate_passing_e_user_error_to_trigger_error
Follow-up to [49230].
Props jrf.
See #62061.
Built from https://develop.svn.wordpress.org/trunk@59108
git-svn-id: http://core.svn.wordpress.org/trunk@58504 1a063a9b-81f0-0310-95a4-ce76da25c4cd
PHP 8.4 deprecates the use of `trigger_errror()` with `E_USER_ERROR` as the error level, as there are a number of gotchas to this way of creating a `Fatal Error` (`finally` blocks not executing, destructors not executing). The recommended replacements are either to use exceptions or to do a hard `exit`.
WP has its own `wp_trigger_error()` function, which under the hood calls `trigger_error()`. If passed `E_USER_ERROR` as the `$error_level`, this will hit the PHP 8.4 deprecation.
Now, there were basically three options:
* Silence the deprecation until PHP 9.0 and delay properly solving this until then. This would lead to an awkward solution, as prior to PHP 8.0, error silencing would apply to all errors, while, as of PHP 8.0, it will no longer apply to fatal errors. It also would only buy us some time and wouldn't actually solve anything.
* Use `exit($status)` when `wp_trigger_error()` is called with `E_USER_ERROR`. This would make the code untestable and would disable handling of these errors via custom error handlers, which makes this an undesirable solution.
* Throw an exception when `wp_trigger_error()` is called with `E_USER_ERROR`. This makes for the most elegant solution with the least BC-breaking impact, though it does open it up to the error potential being "caught" via a `try-catch`. That's not actually a bad thing and is likely to only happen for those errors which can be worked around, in which case, it's a bonus that that's now possible.
The third option is implemented which:
* Introduces a new `WP_Exception` class.
* Starts using `WP_Exception` in the `wp_trigger_error()` function when the `$error_level` is set to `E_USER_ERROR`.
This change is covered by pre-existing tests, which have been updated to expect the exception instead of a PHP error.
Why not use `WP_Error`?
Well, for one, this would lead to completely different behaviour (BC).
As `WP_Error` doesn't extend `Exception`, the program would not be stopped, but would continue running, which would be a much bigger breaking change and carries security risks. `WP_Error` also doesn't natively trigger displaying/logging of the error message, so in that case, it would still need an `exit` with the error message, bringing us back to point 2 above.
Introducing `WP_Exception` provides (essentially) the same behaviour in that it retains the fatal error and error message displaying/logging behaviors. It also introduces a base Exception class, from which future exception classes can extend.
References:
* https://wiki.php.net/rfc/deprecations_php_8_4#deprecate_passing_e_user_error_to_trigger_error
* https://www.php.net/manual/en/migration80.incompatible.php
Follow-up to [56530].
Props jrf, hellofromTonya.
See #62061.
Built from https://develop.svn.wordpress.org/trunk@59107
git-svn-id: http://core.svn.wordpress.org/trunk@58503 1a063a9b-81f0-0310-95a4-ce76da25c4cd
PHP 8.4 deprecates the use of `trigger_errror()` with `E_USER_ERROR` as the error level, as there are a number of gotchas to this way of creating a `Fatal Error` (`finally` blocks not executing, destructors not executing).
The recommended replacements are either to use exceptions or to do a hard `exit`.
This is an unmaintained external dependency; thus, the fix is made in the WP specific copy of the dependency.
As `trigger_error()` call looks to be a remnant of the PHP 4 era before a class could be declared as `abstract`, fixed by making both the method as well as the class `abstract` and removing the call to `trigger_error()`.
Ref:
* https://wiki.php.net/rfc/deprecations_php_8_4#deprecate_passing_e_user_error_to_trigger_error
* https://www.php.net/manual/en/migration80.incompatible.php
Follow-up to [7747].
Props jrf.
See #62061.
Built from https://develop.svn.wordpress.org/trunk@59106
git-svn-id: http://core.svn.wordpress.org/trunk@58502 1a063a9b-81f0-0310-95a4-ce76da25c4cd
PHP 8.4 deprecates the use of `trigger_errror()` with `E_USER_ERROR` as the error level, as there are a number of gotchas to this way of creating a `Fatal Error` (`finally` blocks not executing, destructors not executing). The recommended replacements are either to use exceptions or to do a hard `exit`.
This is an unmaintained external dependency; thus, the fix is made in the WP specific copy of the dependency.
Now, there were basically three options:
* Silence the deprecation until PHP 9.0 and delay properly solving this until then.
This would lead to an awkward solution, as prior to PHP 8.0, error silencing would apply to all errors, while, as of PHP 8.0, it will no longer apply to fatal errors.
It also would only buy us some time and wouldn't actually solve anything.
* Use `exit($status)`.
This would make the code untestable and would disable handling of these errors via custom error handlers, which makes this an undesirable solution.
* Throw an exception.
This makes for the most elegant solution with the least BC-breaking impact.
The third option is implemented which:
* Introduces a new `Text_Exception` class.
* Starts using that in the `Text_Diff::_check()` method in all applicable places.
* Adds tests for the first two error conditions.
References:
* https://wiki.php.net/rfc/deprecations_php_8_4#deprecate_passing_e_user_error_to_trigger_error
* https://www.php.net/manual/en/migration80.incompatible.php
Follow-up to [59070], [52978], [7747].
Props jrf.
See #62061.
Built from https://develop.svn.wordpress.org/trunk@59105
git-svn-id: http://core.svn.wordpress.org/trunk@58501 1a063a9b-81f0-0310-95a4-ce76da25c4cd
In the Patterns registry, use `apply_block_hooks_to_content` (introduced in [58291]) instead of the `WP_Block_Patterns_Registry` class's private `get_content` method. (The latter is removed as part of this changeset.)
In a similar vein, use `apply_block_hooks_to_content` in the `_build_block_template_result_from_file` and `_build_block_template_result_from_post` functions, respectively.
For that to work, `apply_block_hooks_to_content` is amended to inject the `theme` attribute into Template Part blocks, even if no hooked blocks are present.
This kind of centralization is required as a preparation for #61902.
Props bernhard-reiter, jonsurrell.
See #61902.
Built from https://develop.svn.wordpress.org/trunk@59101
git-svn-id: http://core.svn.wordpress.org/trunk@58497 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This is the seventh part in a larger modularization of the data in `WP_Debug_Data`. Previously this was a single massive method drawing in debug data from various groups of related data, where the groups were independent from each other.
This patch separates the seventh of twelve groups, the `wp-dropins` info, into a separate method focused on that data.
This work precedes changes to make the `WP_Debug_Data` class more extensible for better use by plugin and theme code.
Developed in https://github.com/wordpress/wordpress-develop/pull/7418
Discussed in https://core.trac.wordpress.org/ticket/61648
Props apermo.
See #61648.
Built from https://develop.svn.wordpress.org/trunk@59100
git-svn-id: http://core.svn.wordpress.org/trunk@58496 1a063a9b-81f0-0310-95a4-ce76da25c4cd
When encountering inline SVG and MathML content in an HTML document, there are certain "integration points" which transition back into the HTML parsing ruleset. Previously, the HTML API was incorrectly switching into the namespace of the element transitioning into that ruleset.
In this patch, the correct transition is made, where all integration points refer to HTML rules, while non-integration points refer to the rules of the namespace corresponding to the token itself.
Developed in https://github.com/wordpress/wordpress-develop/pull/7425
Discussed in https://core.trac.wordpress.org/ticket/61576
Props dmsnell, jonsurrell.
See #61576.
Built from https://develop.svn.wordpress.org/trunk@59099
git-svn-id: http://core.svn.wordpress.org/trunk@58495 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Moves the 'loading' and 'loaded' i18n strings for the `interactivity-router` to the script module data via the `script_module_data_@wordpress/interactivity-router` filter.
Key changes:
- Add the `filter_script_module_interactivity_router_data()` method, hooked into the `script_module_data_@wordpress/interactivity-router` filter, to set the `i18n` data with the 'loading' and 'loaded' messages.
- Rename the `print_router_loading_and_screen_reader_markup()` method to `print_router_markup()` and remove the screen reader markup from it because it's no longer needed.
- Remove the `loading` and `loaded` strings from the `core/router` store state because they're no longer needed.
- Initialize the `core/router` store with a minimal navigation object to prevent errors in the interactivity-router script module when the store is not properly initialized.
- Update corresponding unit tests to reflect these changes.
This change ensures that the `interactivity-router` i18n messages are localized in a single place and removes the need to initialize them in the `core/router` store state.
Props jonsurrell, swissspidy, czapla.
See #60647.
Built from https://develop.svn.wordpress.org/trunk@59097
git-svn-id: http://core.svn.wordpress.org/trunk@58493 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Fixes an issue with the image block when using pattern overrides, where the image block with overrides enabled was not outputting all the expected image attributes. Ensures that the `process_block_bindings` method returns any updates to the block's binding metadata along with other computed attributes.
Props talldanwp, cbravobernal, santosguillamot, mukesh27, gziolo.
Fixes#62069.
Built from https://develop.svn.wordpress.org/trunk@59095
git-svn-id: http://core.svn.wordpress.org/trunk@58491 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Ensures that the default values defined in the schema for block attributes are used when rendering the output of the block with `get_block_wrapper_attributes` helper.
Props gziolo, jonsurrell, youknowriad, ryelle.
Fixes#62114.
Built from https://develop.svn.wordpress.org/trunk@59093
git-svn-id: http://core.svn.wordpress.org/trunk@58489 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Perform a canonical redirect for an invalid pagination request of a static front page.
When a site has a static front page assigned and that page has a `<!--nextpage-->` within its content, previously accessing non-existing pages (e.g. `example.com/page/3/`) did not redirect or return a 404 or 301. This changeset resolves that issue by performing a canonical redirect.
Unit tests are also included for this specific use case and to ensure the fix does not affect a blog listing home page.
Follow-up to [47738], [47727], [34492].
Props dd32, audrasjb, chaion07, hellofromTonya, joemcgill, lukecarbis, Mte90, mukesh27, peterwilsoncc, rajinsharwar, SergeyBiryukov.
Fixes#50163.
See meta#5184.
Built from https://develop.svn.wordpress.org/trunk@59091
git-svn-id: http://core.svn.wordpress.org/trunk@58487 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The Script Module has the same API as the `wp-a11y` WP Script.
Key changes:
- Add `@wordpress/a11y` to the list of Script and Module dual packages.
- Update `script-modules-packages.min.php` to include the a11y module.
- Modify `WP_Script_Modules` class to track and handle a11y module availability.
- Add method to print required HTML markup for a11y `speak()` functionality.
See #60647.
Props jonsurrell, gziolo, czapla.
Built from https://develop.svn.wordpress.org/trunk@59089
git-svn-id: http://core.svn.wordpress.org/trunk@58485 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This allows other users of the WordPress unit test suite framework to run their own unit tests without needing the WordPress Importer plugin, which should only be a requirement if running core tests.
Follow-up to [59085].
Props bjorsch.
Fixes#62106.
Built from https://develop.svn.wordpress.org/trunk@59086
git-svn-id: http://core.svn.wordpress.org/trunk@58482 1a063a9b-81f0-0310-95a4-ce76da25c4cd
If a hard requirement for the test suite is not fulfilled, running the tests should be blocked from the test bootstrap. A test should only fail when it doesn't produce the expected result.
Since the WordPress Importer plugin is considered a hard requirement for the test suite at this time, this commit moves the check whether the plugin is installed from individual tests to the test bootstrap.
Includes defining a global constant for the path to the file for reuse in the tests.
Reference: [https://make.wordpress.org/core/handbook/contribute/git/#unit-tests Core Contributor Handbook: The Code Repository (Git): Unit Tests].
Follow-up to [40531], [40532], [41090], [41169], [48592], [49535], [49571].
Props jrf, hellofromTonya.
See #61530.
Built from https://develop.svn.wordpress.org/trunk@59085
git-svn-id: http://core.svn.wordpress.org/trunk@58481 1a063a9b-81f0-0310-95a4-ce76da25c4cd
joedolson
hellofromTonya
Felix Arntz
czapla
desrosj
Pascal Birchler
Sergey Biryukov
Bernhard Reiter
John Blackbourn
cbravobernal
Peter Wilson
noisysocks
dmsnell
audrasjb
gziolo
Andrew Ozz