__group__ ticket summary owner component _version priority severity milestone type _status workflow _created modified _description _reporter Comments
Commit Candidates 57774 Add some initial PHPUnit tests for `WP_Filesystem_Direct` hellofromTonya Build/Test Tools 2.5 normal normal 6.5 task (blessed) reopened commit 2023-02-21T00:22:57Z 2024-03-18T09:26:06Z "This is a tests-only ticket.
`WP_Filesystem_Direct` is, by far, the most used filesystem abstraction class.
While some PHPUnit tests exist for a `WP_Filesystem_MockFS` class, this ticket aims to add PHPUnit tests for the `WP_Filesystem_Direct` class itself.
The other filesystem abstraction classes, `WP_Filesystem_FTPext`, `WP_Filesystem_ftpsockets` and `WP_Filesystem_SSH2`, do not have PHPUnit test runner configurations. While in future, we may reuse many of the same tests across filesystem abstraction classes, this ticket specifically targets `WP_Filesystem_Direct`." costdev 29
Needs Dev / Bug Wrangler Feedback 52610 Consider removing many of the default test group exclusions Build/Test Tools normal normal Awaiting Review task (blessed) new dev-feedback 2021-02-22T19:57:39Z 2021-04-29T15:46:12Z "When the tests are run with `composer test`, the following groups are excluded:
* `ajax`
* `ms-files`
* `ms-required`
* `external-http`
When the tests are run with Multisite enabled with `composer test -- -c tests/phpunit/multisite.xml`, the following groups are excluded:
* `ajax`
* `ms-files`
* `ms-excluded`
* `external-http`
* `oembed-headers`
The `ms-required` and `ms-excluded` group exclusions are needed so that the Multisite-specific tests and single-site-specific tests don't run when they don't need to.
It's less clear why the other groups in these lists are excluded by default.
The `ajax` and `ms-files` groups are not slow, so excluding them for performance reasons doesn't make sense. I think the `ajax` exclusion should be removed from both the single site and Multisite configuration. The `ms-files` exclusion should be removed too because the tests in the `ms-files` group don't get registered on a non-Multisite test run so the exclusion is redundant.
The `external-http` tests are excluded because they are somewhat slow, taking around 10-15 seconds on GitHub Actions and around 40 seconds on my local, highly dependent on network connection speed. Let's keep these excluded by default.
The `oembed-headers` group is excluded by default because it requires Xdebug, however this is already covered by the `@requires function xdebug_get_headers` tag on the only test in this group, along with being in the `debug` group which runs separately on GitHub Actions. The `oembed-headers` group exclusion can be removed as it's redundant.
Here's my proposed new config for `phpunit.xml.dist`:
{{{
ms-requiredexternal-http
}}}
and for `multisite.xml`:
{{{
ms-excludedexternal-http
}}}" johnbillion 5
Needs Dev / Bug Wrangler Feedback 59900 Measure performance with a persistent object cache in performance tests swissspidy Build/Test Tools normal normal 6.6 task (blessed) assigned dev-feedback 2023-11-13T21:55:31Z 2024-03-02T12:28:31Z "Similar to #59815: Whether or not a persistent object cache is used makes a major difference on server-side performance of a WordPress site. While there are several factors impacting server-side performance and we cannot benchmark for every single one of them, object caching is a quite significant one and therefore should probably be covered, similar to internationalization.
It is common for certain performance optimizations to only apply for sites with a persistent object cache, so we should be able to monitor the impact of such changes over time." flixos90 11
Needs Dev / Bug Wrangler Feedback 53010 Tests: introduce namespacing for the test classes hellofromTonya Build/Test Tools normal normal Future Release task (blessed) assigned dev-feedback 2021-04-09T15:51:13Z 2024-03-15T08:10:07Z "Introducing namespaces in the production code for WordPress Core is a hot topic, so I very purposely do NOT want to touch that in this ticket.
However, for the test suite, which doesn't get shipped with the WordPress production code, it's a whole other matter.
== Benefits
Using namespaces in the test suite provides us with the following benefits:
1. If used consistently and providing they follow a set pattern (more about this below), they will make it very easy for contributors to find the test files/classes they are looking for.
2. It will allow for shorter file and test class names, while those will still be descriptive.
3. And... it will allow for mocking PHP native functions by declaring a namespaced version of that same function in the test class.
4. It will also allow more easily for multiple test classes to be created to test one particular feature/function, which the current naming scheme does not allow for. This will allow for tests for the same functionality, but which need different fixtures (setup/teardown) to be encapsulated in their own test classes.
== Caveats:
As the WordPress Core test suite is used not only by Core, but also by plugins and themes for integration tests, the test class namespacing should be reserved for actual test classes and - for now - not be applied to test utility classes / Abstract base test classes (i.e. the `tests/phpunit/includes` directory should NOT be touched for now).
== Proposed pattern
The current directory structure for tests is, to put it mildly, confusing and inconsistent.
To solve that, I would like to propose the following pattern:
* File paths: `tests/phpunit/tests/wp-[includes|admin]/[SubFolder/]*Class_Under_Test/FunctionUnderTest[OptionalSubsetIndicator]Test.php`
* Namespace: `WordPress\Tests\WP_[Includes|Admin]\[SubFolder\]*Class_Under_Test`
* Classname: `FunctionUnderTest[OptionalSubsetIndicator]Test`
For WP Core files which only contain functions outside of a class structure, the following pattern is proposed:
* File paths: `tests/phpunit/tests/wp-[includes|admin]/[SubFolder/]*Functions_FileName/FunctionUnderTest[OptionalSubsetIndicator]Test.php`
* Namespace: `WordPress\Tests\WP_[Includes|Admin]\[SubFolder\]*Functions_FileName`
* Classname: `FunctionUnderTest[OptionalSubsetIndicator]Test`
The pattern I'm proposing does imply a re-organisation of the test suite directory and file structure, but that IMO is for the better.
It also follows a PSR4-like pattern which will be more intuitive for new contributors to work with, as well as follow the PHPUnit recommended test class name pattern with having the `Test` as the end of the class name.
This will also allow for using PSR-4 autoloading for the tests classes and adding the `autoload-dev` directive to the `composer.json` file.
== Planning
This should be regarded as a small project and not all renaming needs to be done at the same time.
New tests should start following the above proposed pattern as soon as consensus has been reached about this proposal.
Existing tests can be gradually switched over to the new pattern over time.
== Additional tasks associated with this project
- [ ] Updating the contributors handbook for Core.
- [ ] Verify that the WordPressCS sniffs will validate this pattern correctly.
- [ ] Write a Make post about the decision once consensus has been reached." jrf 20
Needs Dev / Bug Wrangler Feedback 56070 Use a consistent order of annotations in the test suite Build/Test Tools normal normal Future Release task (blessed) new dev-feedback 2022-06-24T22:18:01Z 2023-10-17T00:41:32Z "WordPress core has an [https://developer.wordpress.org/coding-standards/inline-documentation-standards/php/#docblock-formatting established DocBlock format] for inline documentation:
{{{
/**
* Summary.
*
* Description.
*
* @since x.x.x
*
* @see Function/method/class relied on
* @link URL
*
* @global type $varname Description.
* @global type $varname Description.
*
* @param type $var Description.
* @param type $var Optional. Description. Default.
* @return type Description.
*/
}}}
This is more or less consistently applied in core, which is helpful for reusing this template for newly added functions without the guesswork of where to put each particular tag.
Unit tests also use some of these tags:
* `@since`
* `@see`
* `@global`
* `@param`
* `@return` (for tests with dependencies)
as well as some [https://make.wordpress.org/core/handbook/testing/automated-testing/writing-phpunit-tests/#annotations test-specific annotations]:
* [https://phpunit.readthedocs.io/en/9.5/annotations.html#ticket `@ticket`]
* [https://phpunit.readthedocs.io/en/9.5/annotations.html#group `@group`]
* [https://phpunit.readthedocs.io/en/9.5/annotations.html#covers `@covers`]
* [https://phpunit.readthedocs.io/en/9.5/annotations.html#depends `@depends`]
* [https://phpunit.readthedocs.io/en/9.5/annotations.html#requires `@requires`]
* [https://phpunit.readthedocs.io/en/9.5/annotations.html#dataprovider `@dataProvider`]
* `@expectedDeprecated`
* `@expectedIncorrectUsage`
However, the order of these annotations differs in various test classes and can be almost random even in test methods of the same class. These inconsistencies increase cognitive load when writing new tests or reviewing test PRs to bring them in line with existing tests.
I would like to propose a DocBlock template that can be consistently applied across the test suite. Something like:
{{{
/**
* Summary.
*
* Description.
*
* @since x.x.x
* @ticket 12345
*
* @group group_name_1
* @group group_name_2
*
* @covers function_name_1
* @covers function_name_2
*
* @requires function function_name
*
* @expectedDeprecated
* @expectedIncorrectUsage
*
* @see Function/method/class relied on
* @link URL
*
* @depends test_name
* @dataProvider data_provider_name
*
* @global type $varname Description.
* @global type $varname Description.
*
* @param type $var Description.
* @param type $var Optional. Description. Default.
* @return type Description.
*/
}}}
Notes:
* All of these annotations are optional and may not be present on a particular test, so most of the time the DocBlock would be much shorter. But if they are present, the order should be consistent across the test suite.
* `@since` and `@ticket` are grouped together because they are both related to when a test was introduced.
* `@group` and `@covers` are separated into their own sections for better readability when a test belongs to multiple groups and/or covers multiple functions.
* `@depends` and `@dataProvider` are grouped together and moved closer to globals and parameters, because they are both related to passing data to the test. When reviewing the current usage of `@depends` in the test suite, I found some instances that don't pass any data but seem to (incorrectly) assume that this annotation defines the order in which the tests are executed. That can be addressed separately.
Any thoughts on using this DocBlock format or any suggestions for improving it are welcome." SergeyBiryukov 15
Needs Dev / Bug Wrangler Feedback 43733 Replace Underscores.js with Lodash.js adamsilverstein External Libraries normal normal Awaiting Review task (blessed) assigned dev-feedback 2018-04-10T14:30:08Z 2023-07-17T23:20:28Z "Should we replace Underscores.js with Lodash.js?
[https://wordpress.slack.com/archives/C5UNMSU4R/p1523367735000195 Discussed in Slack today (April 10th, 2018)].
It was suggested for converting WP Core to lodash, [https://github.com/facebook/jscodeshift jscodeshift] could be leveraged.
Here is a list of [https://github.com/lodash/lodash/wiki/Migrating API pairings between lodash and underscores].
Concerns:
Lodash 5.0 is set to have some [https://github.com/lodash/lodash/wiki/Roadmap backwards incompatible changes] that could make the migration awkward.
General backwards compatibility concerns as well. How do we want to handle Backwards Compat? Most likely only core will be changed, and a migration path/tool will be offered out to theme/plugin authors." ChopinBach 16
Needs Dev / Bug Wrangler Feedback 55604 Update SimplePie to version 1.7.0 External Libraries 6.0 normal normal Future Release task (blessed) new needs-unit-tests 2022-04-21T20:05:26Z 2024-02-05T20:11:34Z "A new version of SimplePie has just been released.
This version contains a few enhancements and some bug fixes.
The most notable change, however, is that this release contains a ''forward-compatibility'' layer for the change to PSR-4 namespaced classes which is targetted for SimplePie 2.0.0.
With some similarity to Requests - the namespaced versions of the classes are in a different base directory (`src`) from the original versions (`library`).
As WP currently only includes the files in the `library` directory, I would like to suggest to continue doing so for now.
This still makes the ''forward-compatibility'' layer available as all files in the `library` directory now create a ''class alias'' to their namespaced version.
Once 2.0.0 has been released, the files included in WP, should be switched to the files from the `src` directory (which is currently in place mostly to allow for Composer autoloading) and should start using the namespaced names for the SimplePie classes.
I'd recommend for this update to be mentioned in a dev-note, so plugins/themes directly using SimplePie can decide for themselves when they want to change to using the namespaced names for SimplePie classes.
Refs:
* https://github.com/simplepie/simplepie/releases/tag/1.6.0
* https://github.com/simplepie/simplepie/blob/1.6.0/CHANGELOG.md#160---2022-04-21
* https://github.com/simplepie/simplepie/compare/1.5.8...1.6.0
I've done a cursory check of the changes and they look sane to me, but would very much like to invite a second opinion and I'd recommend testing this change (more thoroughly than usually done for upgrades like these).
I'd also like to recommend for a few cursory tests to be added to the WP test suite to ensure that both the PSR-0 as well as the PSR-4 class names load correctly when only including the `library` directory in WP.
I'd recommend for this update to be applied in WP 6.1 **early**.
Previous: #36669, #51521, #54659" jrf 31
Needs Dev / Bug Wrangler Feedback 59233 Improve error handling for unserialize() General normal normal 6.6 task (blessed) new dev-feedback 2023-08-28T23:47:32Z 2024-02-26T22:05:20Z "From https://core.trac.wordpress.org/ticket/59231:
> === [https://wiki.php.net/rfc/unserialize_warn_on_trailing_data Make unserialize() emit a warning for trailing bytes]
>
> While based on the current test suite, WP is not ''directly'' affected by this, the [https://developer.wordpress.org/reference/functions/maybe_unserialize/ `maybe_unserialize()`] function could still be confronted by data with trailing bytes.
>
> However, the call to the PHP native `unserialize()` within `maybe_unserialize()` silences all (PHP 8.0+: non-fatal) errors, so this new warning will not affect WP or its ecosystem as long as the `maybe_unserialize()` function is used.
>
> Having said that, a critical look at `maybe_unserialize()` may be warranted as the new warning in PHP is related to security issues discovered in other projects, so WP may want to consider rejecting unserialization for data throwing this warning.
>
> Also note that there are 7 uses of `unserialize()` in total within WP Core, one within `maybe_unserialize()`, but the function is also used in 6 other places and 5 of those do not use error silencing.
>
>
> === [https://wiki.php.net/rfc/improve_unserialize_error_handling Improve unserialize() error handling]
>
> This, again, affects the [https://developer.wordpress.org/reference/functions/maybe_unserialize/ `maybe_unserialize()`] function and this time, the code should probably be adjusted to handle the new errors which `unserialize()` can now throw.
>
> The change does not affect unserializing valid data, but in the case of invalid data, the type of and severity of the notices/warnings/catchable exceptions have been changed.
>
> All 7 uses of `unserialize()` in WP Core should be reviewed and for the 6 uses outside of the `maybe_unserialize()` function, it should be reviewed whether they can/should switch to using `maybe_unserialize()` and/or whether they should get their own (improved) error handling.
" jrf 4
Needs Dev / Bug Wrangler Feedback 55603 PHP 8.2: address deprecation of the utf8_encode() and utf8_decode() functions hellofromTonya General 6.0 normal normal 6.6 task (blessed) assigned dev-feedback 2022-04-21T19:24:21Z 2024-03-06T17:40:19Z "== Context
The [https://wiki.php.net/rfc/remove_utf8_decode_and_utf8_encode PHP RFC to remove the `utf8_encode()` and `utf8_decode()` functions] from PHP in PHP 9.0 has recently been accepted.
This means in effect that as of PHP 8.2, those functions will be deprecated and a deprecation notice will be thrown whenever they are called.
The reasoning behind the deprecation and removal is that these functions are confusing and rarely used correctly.
See the [https://wiki.php.net/rfc/remove_utf8_decode_and_utf8_encode#usage Usage section] of the RFC for an analysis of the various (mostly incorrect) uses of the functions.
== The Problem
The [https://wiki.php.net/rfc/remove_utf8_decode_and_utf8_encode#alternatives_to_removed_functionality typical replacements for these functions] are using the [https://www.php.net/manual/en/book.mbstring.php MBString extension] and/or the [https://www.php.net/manual/en/book.iconv.php Iconv extension].
As these extensions are both ''optional'' extensions in PHP, they cannot be relied on to be available in an open source context.
WordPress uses the `utf8_encode()` function a few times in the codebase:
* 1 x `utf8_encode()` in `src/wp-admin/includes/export.php`
* 2 x `utf8_encode()` in `src/wp-admin/includes/image.php`
* 1 x `utf8_encode()` in `tests/phpunit/tests/kses/php`
Aside from that the external dependency [https://github.com/JamesHeinrich/getID3 GetID3] also uses both these functions a number of times.
A search of the plugin and theme directory shows more worrying results with a plenitude of matches:
* [https://wpdirectory.net/search/01G16P0SWHB37G2965MP8R4ZYK 11247 matches in 3315 plugins], including 15 plugins with over a million installs.
* [https://wpdirectory.net/search/01G16P2K39TQ538M9KRTVXT4CA 40 matches in 22 themes].
== Options
So, what are the options we have ?
In my opinion, especially seeing how these functions are used so often in plugins, there are only two realistic options:
=== 1. We could polyfill these functions.
While some functions which may not be available are polyfilled by WP, this is generally only done to have access to ''new'' PHP functionality or to allow for using functions which require certain optional extensions to be enabled.
As far as I know, no PHP native function has ever been polyfilled due to it being removed from PHP.
**Pro**:
Relatively simple solution and everything keeps working (deprecation notices will still show when running on PHP 8.x, though these could silenced).
**Con**:
As most uses of these functions are likely to be incorrect usage (especially in plugins), these ""bugs"" will remain and not be reviewed or addressed, undercutting the improvement PHP is trying to make.
=== 2. We could make the MbString (or the Iconv) extension a requirement
At this moment, [https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes/class-wp-site-health.php#L876 both the MbString as well as the Iconv extension are recommended, but not required by WP].
A couple of MbString functions are also polyfilled in WP, so now might be a good time to make the MbString extension a requirement for WP.
**Pro**:
MbString being available will allow for fixing the deprecations in a forward-compatible manner. It will also allow for other code improvements to be made to improve WPs support for languages using non-latin based scripts.
**Con**:
A new requirement would be added to WP which should not be taken lightly. At the same time, it should be noted that MbString is generally enabled already anyway, so this will impact only a small percentage of users.
==== Why MbString instead of Iconv ?
While both are included (though not enabled) by default with PHP, Iconv [https://www.php.net/manual/en/iconv.requirements.php requires the `libiconv` library], which may not be available, while MbString has [https://www.php.net/manual/en/mbstring.requirements.php no external dependencies].
MbString is [https://www.php.net/manual/en/mbstring.installation.php not enabled by default in PHP], but generally ''is'' enabled in practice.
[https://www.php.net/manual/en/mbstring.installation.php Iconv is enabled by default] in PHP, but can be disabled.
Having said that, MbString offers much more functionality than the limited functionality offered by Iconv and - as indicated by a number of functions being polyfilled - is already in use in WP.
Still, it would be helpful if someone with access to the underlying statistics data collected by WP could add figures to this issue showing how often either extension is enabled on systems running WP.
== Recommendation
I'd strongly recommend option 2, but would like to hear the opinions of additional Core devs.
== Action lists
=== General
- [ ] Report the issue to GetID3
=== Action list for option 1
- [ ] Polyfill the functions.
- [ ] Review the uses of the functions in WP Core anyhow to see if those could/should be removed/the code using them should be refactored.
- [ ] Add a note about the polyfills in a dev-note with a recommendation for plugin/theme authors to review their use of these functions anyhow.
=== Action list for option 2
- [ ] Make the MbString a requirement for installing WP/in the WP bootstrapping.
- [ ] Change the MbString extension from optional to required in the Site Health component.
- [ ] Remove the current MbString related polyfills from the `compat.php` file.
- [ ] Review the uses of the functions in WP Core and replace with more appropriate alternatives.
- [ ] Add a note about the deprecation in the PHP 8.2 dev-note with a recommendation for plugin/theme authors to review their use of these functions and noting that the MbString extension can be relied upon to be available (as of WP 6.1).
" jrf 66
Needs Dev / Bug Wrangler Feedback 40365 Introduce a REST API endpoint for sites REST API normal normal Future Release task (blessed) new needs-unit-tests 2017-04-05T00:18:18Z 2020-04-03T05:00:47Z "It should be possible to manage sites in a multisite configuration through the REST API.
* List sites: `GET wp/v2/sites/`
* Retrieve a site: `GET wp/v2/sites/`
* Create a site: `POST wp/v2/sites/`
* Update a site: `PUT wp/v2/sites/`
* Delete a site: `DELETE wp/v2/sites/`
Data included in a site object should at least mirror the data available for the site in `wp_blogs`. Additional ideal pieces of data for a site include `blogname`, `blogdescription`, `home`, and `siteurl`. It's possible that creating a new meta table for sites can help developers register meta for inclusion with a site object (See #37923).
Sites should be accessible by default for authenticated users only. Network (global) admins should have access to all sites. Site users should have access to the sites they are members of. The ""My Sites"" list is a great candidate for exploring how this will work. See #15317.
As of the introduction of `get_sites()` in 4.6.0, retrieving sites is a much better experience. The methods used to create, update, and delete sites in multisite are not as pleasant right now. We should investigate each of these and determine what can be done to streamline the process. The first improvement is probably in creating a site. See #40364." jeremyfelt 14
Needs Dev / Bug Wrangler Feedback 56017 Check the required PHP extensions during WordPress installation and updates Upgrade/Install normal normal Future Release task (blessed) new dev-feedback 2022-06-20T15:59:16Z 2022-10-11T12:50:49Z "Background: #55603
Currently, marking a PHP extension as required in Site Health displays a warning on existing sites if the extension is unavailable, but it does not block the WP installation for new sites, nor the updates to the new version for older sites.
To avoid fatal errors, WordPress core should check for the required PHP extensions both during installation and updates, similar to how we check for the required PHP and MySQL versions.
As also noted by @jrf in comment:2:ticket:55603:
> Might also be a good time to improve the code re-usability in that regards (have one master list of requirements and recommendations, which both the requirements checker on installation/load + the Site Health component draw from)." SergeyBiryukov 12
Needs Dev / Bug Wrangler Feedback 51928 Provide plugin/theme update failure data to dot org Upgrade/Install normal normal Future Release task (blessed) assigned dev-feedback 2020-12-03T19:44:16Z 2023-07-05T18:15:26Z "With plugin auto-updates in core there have been instances of update failures leaving the user's site without the update and without any idea why the update failed. We receive core auto-update failure data to dot org and receiving plugin/theme failure data would help significantly in determining the causes of these failures.
I'm mostly guessing from how `class-core-upgrader.php` sends failure data via `wp_version_check( $stats )` and I've added similar data and a call to `wp_update_{plugins|themes}( $stats )` in `class-wp-upgrader.php` Thanks @pbiron
If it actually does send the data to dot org it could be useful. This requires the return of `WP_Error`s at potential points of failure. I have added one of these in #51857.
Feedback from the dot org maintainers will be needed." afragen 72
Needs Early Attention 60096 Remove back-compat for database servers that don't support utf8mb4 johnbillion Database trunk normal normal 6.6 task (blessed) assigned has-patch 2023-12-18T19:45:03Z 2024-02-28T00:31:19Z Since [57173] the minimum supported version of MySQL is 5.5.5, which means the utf8mb4 charset is supported by all supported database servers. The back-compat code for handling servers that don't support it can therefore be removed, along with related tests and health checks. johnbillion 6
Needs Early Attention 51812 Update jQuery step three SergeyBiryukov External Libraries normal normal Future Release task (blessed) reviewing has-patch 2020-11-18T09:34:57Z 2024-01-27T08:55:38Z "Follow up from #37110 and #50564.
Remove jQuery Migrate 3.3.x.
This ticket represents step 3 in the following roadmap for updating jQuery to 3.x in Core: https://make.wordpress.org/core/2020/06/29/updating-jquery-version-shipped-with-wordpress/.
" azaozz 133
Needs Docs or Unit Tests 40538 Fix or remove useless PHPUnit tests johnbillion* Build/Test Tools normal normal Future Release task (blessed) accepted needs-unit-tests 2017-04-23T01:11:24Z 2022-09-01T22:54:20Z "There are 29 tests in the test suite which don't perform an assertion. They should be fixed or removed.
PHPUnit 6 has switched to being strict about useless tests by default, so that gives us an additional reason to address them. In addition, there's no reason for core's default PHPUnit configuration to not be strict about useless tests so the same behaviour is seen when running older versions of PHPUnit.
Previously: #36016" johnbillion 12
Needs Docs or Unit Tests 42093 Improve handling of SUBDOMAIN_INSTALL test coverage jeremyfelt Build/Test Tools normal normal Future Release task (blessed) assigned needs-unit-tests 2017-10-04T18:55:45Z 2023-10-20T14:15:29Z "We have a bunch of tests that run (or are skipped) based on `is_subdomain_install()`, but our Travis CI configuration never runs the tests in a subdomain configuration.
To run the tests now, you need to setup the environment manually. In its current state, 7 tests fail:
{{{
1) Tests_Multisite_Site::test_created_site_details
2) Tests_Multisite_Site::test_new_blog_url_schemes with data set #0 ('https', 'https', false)
3) Tests_Multisite_Site::test_new_blog_url_schemes with data set #1 ('http', 'https', false)
4) Tests_Multisite_Site::test_new_blog_url_schemes with data set #2 ('https', 'http', false)
5) Tests_WP_oEmbed::test_wp_filter_pre_oembed_result_multisite_sub_samesub
6) Tests_WP_oEmbed::test_wp_filter_pre_oembed_result_multisite_sub_othersub
7) Tests_WP_oEmbed::test_wp_filter_pre_oembed_result_multisite_preserves_switched_state
}}}
The first is a result of our site factory only creating new subdirectory sites. I believe the `test_new_blog_url_schemes` should be skipped for `is_subdomain_install()`, but I haven't verified. I'm not sure yet what the issue is with the oEmbed tests.
I'd like to:
* Clean up the existing tests so that they pass.
* Determine a good way of running these in our Travis CI configuration.
It'd be nice *not* to run the entire set of core/multisite tests again just to account for this. Hopefully there's a creative approach to run only the subdomain specific tests.
Previously: #36567, #36566.
" jeremyfelt 8
Needs Docs or Unit Tests 35857 Add QUnit tests for Customizer preview, including Selective Refresh Customize 3.4 normal normal Future Release task (blessed) assigned needs-unit-tests 2016-02-18T08:26:15Z 2023-03-17T17:06:23Z "Initial Customizer unit tests for PHP and JS were added in #28579. The QUnit tests were done specifically for the Customizer controls (pane) and not the Customizer preview. This was understandable since he preview was devoid of much unique JS functionality. With the introduction of the Selective Refresh component (#27355), this has changed. There needs to be a new QUnit test suite specifically for the Customizer preview.
See @valendesigns initial foundation work here: https://github.com/xwp/wp-customize-partial-refresh/pull/32/files#diff-6fcbfd120899db12c05cdb1f6142cd87 " westonruter 17
Needs Docs or Unit Tests 12706 Custom post status bugs Posts, Post Types 3.0 normal normal Future Release task (blessed) reopened needs-unit-tests 2010-03-25T14:41:39Z 2022-06-02T13:42:36Z "A developer should be able to register a custom post status using `register_post_status()`. The admin UI (including post submit box and quick edit) should reflect this new custom post status. Furthermore, there are many hard-coded references to 'draft' and 'pending' statuses in core that should properly use the post status API.
All existing arguments to `register_post_status()` should be fully implemented, should also support per-post-type arguments. As things get implemented across core, there will likely be a need for supporting capabilities and bits of API.
Related: #23169 (register_post_status_for_object_type), #23168 (unregister_post_status)." ptahdunbar 167
Needs Docs or Unit Tests 9824 make better use of stubs when verbose rules should apply Rewrite Rules normal normal task (blessed) reopened needs-unit-tests 2009-05-15T01:03:56Z 2019-06-04T21:05:28Z "Related to:
http://core.trac.wordpress.org/ticket/6603#comment:27
Problem fixed is:
> posts show up as www.apexprd.org/page/2 and not /news-and-events/page/2 as it should.
with permalinks set to /something/$postname%/
we arguably don't necessarily need verbose rules here, since there is a stub." Denis-de-Bernardy 16
Needs Docs or Unit Tests 43989 "Allow plugin searches to be filtered by ""Requires PHP"" version information" Site Health normal normal Future Release task (blessed) new needs-unit-tests 2018-05-07T14:24:41Z 2019-06-24T16:10:01Z "**Note: This ticket is a subtask for the overarching #40934 ticket.**
If plugins now start making use of the ""Requires PHP"" version information in their plugin header, we should make sure that plugin searches can be filtered by their required PHP version.
This might include changes to the indexing infrastructure (indexing that information and allowing indexed queries against it) as well as changes to the UI (giving users the possibility to either use search flags in text form or faceted search mechanisms to communicate such a query." schlessera 5
Needs Docs or Unit Tests 47880 Extend unit tests for Site Health component. Site Health 5.2 normal normal Future Release task (blessed) new needs-unit-tests 2019-08-15T00:49:49Z 2020-07-06T23:20:09Z "A file for site health check unit tests has been added in `tests/phpunit/tests/site-health.php`.
At the time of writing it only includes tests for various states of cron, expanding these would help with future development of the component." peterwilsoncc 9
Has Patch / Needs Testing 49715 Alternate views for WP List Tables audrasjb Administration normal normal Future Release task (blessed) reopened has-patch 2020-03-27T16:56:24Z 2020-12-01T19:19:16Z "Currently, the WP List Table supports two views: default and ""excerpts"". This distinction is confusing and doesn't easily allow for other differences between the two views.
As a way to create more flexibility in WP List Tables, we'd like to implement mechanisms for users to choose different views, similar to what's found in Gmail, e.g.: Compact, Default, Comfortable.
This would give us a lot more flexibility in being able to resolve issues where conflicts arise between design, space, and accessibility, because we could offer views where everything is spelled out in a spacious way and also views where information is more compact. As long as the user is able to choose a persistent view that gives them all the information they need, the alternate views can use designs that disclose less detail.
Example tickets that would be impacted include:
#48751
#32170
#35391
" joedolson 55
Has Patch / Needs Testing 40001 Replace wp-list.js with REST API-powered JavaScript Administration 4.7 normal normal Awaiting Review task (blessed) new has-patch 2017-03-01T07:06:00Z 2021-04-06T15:33:21Z "wp-list.js is used for ''some'' list tables in WordPress, but not all. We should switch everything it does over to the REST API, and simultaneously rethink list tables to ensure consistency.
(This is a stub ticket, longer post on make/core coming soon.)" rmccue 2
Has Patch / Needs Testing 40885 Update admin color scheme using the REST API Administration normal normal Awaiting Review task (blessed) new has-patch 2017-05-30T05:55:01Z 2017-05-31T13:05:44Z "Reasonably simple admin-ajax call (notably, with no significant filters) that can be replaced with a call to `/wp/v2/users`. Patch attached.
One thing we can't do is provide an enum of valid color schemes, since historically these have only been registered on `admin_init` (including in core). This also applies to the sanitization callback on the meta key, which can only remove invalid characters, not validate the scheme is valid." rmccue 1
Has Patch / Needs Testing 31823 Add ESLint integration swissspidy Build/Test Tools normal normal Future Release task (blessed) assigned has-patch 2015-03-31T20:19:57Z 2024-02-23T10:36:37Z "'''Update:''' The JSCS project has merged into ESLint. So now an ESLint config is needed to be developed for core as opposed to a JSCS one.
----
The [http://jscs.info/ JSCS] project has [https://github.com/jscs-dev/node-jscs/issues/1099 added] a [https://github.com/jscs-dev/node-jscs/blob/master/presets/wordpress.json wordpress] preset. This could be useful to be included in Core. All it needs is a `.jscsrc` file located in the root which contains:
{{{#!js
{
""preset"": ""wordpress"",
""excludeFiles"": [
""**/vendor/**"",
""**.min.js"",
""**/node_modules/**""
]
}
}}}
Related:
#30153 (PHP_CodeSniffer)
#25187 (JSHnt)
#28543 (Allow stricter JSHint checks for core files)" westonruter 30
Has Patch / Needs Testing 56150 Add GitHub Action job summaries to workflows Build/Test Tools normal normal Future Release task (blessed) new has-patch 2022-07-05T15:11:10Z 2023-09-01T17:24:57Z "In May, GitHub released [https://github.blog/2022-05-09-supercharging-github-actions-with-job-summaries/ Job Summaries for GitHub Actions], which allows markdown or raw HTML to be displayed on the workflow run summary page for jobs.
This ticket is for exploring ways to use this feature in the WordPress Core workflows to make it easier to understand the data and outcomes buried in each step's log output within a job." desrosj 10
Has Patch / Needs Testing 59416 Add a GitHub Action which alerts contributors to a WordPress Playground link to use for testing PRs Build/Test Tools normal normal 6.6 task (blessed) new has-patch 2023-09-20T20:53:28Z 2024-03-06T06:44:58Z "The following approach could help bring in many new folks to help with testing PRs as they no longer need to have a local set up and able to load patches/PRs locally and can quickly jump into a WordPress Playground environment to help test.
----
Gutenberg has a GitHub Action that builds a ZIP of the plugin ([https://github.com/WordPress/gutenberg/blob/trunk/.github/workflows/build-plugin-zip.yml workflow file], [https://github.com/WordPress/gutenberg/actions/runs/6250831688 example Gutenberg PR with built ZIP attached]) which then [https://developer.wordpress.org/playground/ WordPress Playground] makes use of in the [https://playground.wordpress.net/gutenberg.html Gutenberg PR Previewer].
Taking that above functionality a step further and integrating for Core:
1. Add a GitHub Action for [https://github.com/WordPress/wordpress-develop/ wordpress-develop] that builds a ZIP of core for a PR (similar to the Gutenberg action).
2. Have that same action also add a comment to the PR with a link to a WordPress Playground that's built using the ZIP from the PR. So a comment like:
> Thanks <@PR-author>! Here's a link to a site created from this PR that can be used for testing: .
In my quick review of the [https://wordpress.github.io/wordpress-playground/ WordPress Playground documentation] it does reference an ability to [https://wordpress.github.io/wordpress-playground/build-your-first-app/#preview-pull-requests-from-your-repositorypreview pull requests from your repository], but I think that's crafted more for plugin developers and not for WordPress core itself. I took a look at [https://wordpress.github.io/wordpress-playground/api/client/interface/ReplaceSiteStep/ ReplaceSiteStep], but I think that's just for loading in alternate content and not a full on separate WordPress ZIP. So, this functionality might require additional functionality within WordPress Playground but I'll try and chase down folks from that team to comment here on the topic.
" JeffPaul 58
Has Patch / Needs Testing 54510 Add a GitHub Action workflow which alerts contributors if they propose changes to third party files johnbillion Build/Test Tools normal normal 6.6 task (blessed) reviewing has-patch 2021-11-25T14:06:52Z 2024-02-22T10:25:50Z "WordPress core includes files from several third party libraries such as ID3, SimplePie, and Requests. Changes to these libraries shouldn't be made directly in core, they should be made upstream.
If a contributor opens a pull request proposing changes to these files it would be great if a comment was automatically posted to the PR explaining that they've proposed changes to a third party library and they should visit the corresponding project's repo for info about contributing to it.
While there's not much we can do about this when a contributor submits a patch to a file in an affected path, it should be possible to do this when a PR is submitted via GitHub. A GitHub Action workflow could use the `path` keyword to post a comment to the PR whenever a file in an affected path is changed.
There are also files that get copied from Gutenberg and can clobber those in core, I opened https://github.com/WordPress/gutenberg/issues/36868 to discuss that." johnbillion 7
Has Patch / Needs Testing 48086 Add required extensions and libraries to composer.json Build/Test Tools 5.2.3 normal normal 6.6 task (blessed) new has-patch 2019-09-20T12:00:49Z 2024-02-26T16:59:03Z "Composer offers a way to require or suggest certain platform packages: https://getcomposer.org/doc/01-basic-usage.md#platform-packages
Ticket 48081 addresses the PHP version, and this one covers the required libraries and extensions.
I've used the WP-CLI ext package (https://github.com/johnbillion/ext) to generate all the required and suggested extensions and libraries.
" dingo_d 14
Has Patch / Needs Testing 41870 Code Editor: Add grunt task for building new CodeMirror bundles from external dependencies adamsilverstein Build/Test Tools normal normal Future Release task (blessed) assigned has-patch 2017-09-13T18:06:08Z 2022-01-30T16:51:32Z "After [41376] for #12423, it would be ideal if the CodeMirror bundling logic (via browserify) could be added as part of core. In this way, the external dependencies (CodeMirror and the linter linraries) can be managed by NPM. For now, just the minified bundles are being included.
The logic used in the Better Code Editing plugin for creating the bundles can be seen here: https://github.com/WordPress/better-code-editing/pull/92/files
Depends on #40894 which replaces Browserify with Webpack in core.
See also #42424, where we need to fix line-endings for CSSLint.
Additionally, the linters are currently being included as separate assets. They are not being minified, other than they are already minified as distributed. These could either benefit from additional uglification or bundling with codemirror if they are not going to be enqueued separately. The same goes for the `htmlhint-kses` script." westonruter 45
Has Patch / Needs Testing 60129 Comment on a PR when no Trac ticket is included Build/Test Tools normal normal 6.6 task (blessed) new has-patch 2023-12-21T17:45:51Z 2024-03-02T11:21:06Z "When contributing to Core using a pull request on GitHub, a [https://make.wordpress.org/core/handbook/contribute/git/github-pull-requests-for-code-review/ Trac ticket is required for the contribution to be considered].
Even though the pull request template notes this, it's easy to forget or overlook.
Adding a job in the Pull Request Comments workflow to add a reminder comment when a Trac ticket link is missing is an easy way to help avoid contributions being lost in the shuffle." desrosj 5
Has Patch / Needs Testing 59779 "Consider testing against MySQL ""Innovation Releases""" Build/Test Tools normal normal 6.5 task (blessed) new has-patch 2023-10-31T18:40:24Z 2024-02-27T05:34:36Z "The [https://dev.mysql.com/blog-archive/introducing-mysql-innovation-and-long-term-support-lts-versions/ MySQL project has announced a new version release cadence] that it has begun following with version 8.1 (eleased on July 18, 2023), and has since been superseded with 8.2 (released on October 25, 2023).
I recommend reading their full post, but here are some important details I've extracted:
> Support for Innovation releases is limited until the next minor release (Innovation or LTS). The current cadence goal is to have an Innovation release every quarter, incrementing the minor version number (eg. 8.2, 8.3, etc.). Patch releases within Innovation releases are possible but are less likely to happen.
> About every 2 years a new Long Term Support version will be released (blue). An exception is the 8.x LTS release which will happen well before EOL of 8.0
> Innovation releases will also be Generally Available and are recommended to be used in production environments. Bugfixes and Security patches will generally be included in the next Innovation or LTS release and not as part of a patch release within that Innovation release. When using Innovation releases, it is necessary to upgrade to the latest innovation releases regularly to keep up with the latest bugfixes and security patches.
Because innovation versions are considered production safe, we should consider testing against these new versions of MySQL as they are released. However, since innovation releases are replaced more frequently, it's not clear how long we should consider testing against them.
For example, the current Innovation release is 8.2, which will be replaced by 8.3 in (approximately) January 2024. Because of backwards compatibility concerns, should 8.1 and 8.2 continue to be tested? Or is testing against the latest innovation release, and any supported LTS versions enough?" desrosj 13
Has Patch / Needs Testing 54334 E2E tests for Uploading New Version of Themes & Plugins Build/Test Tools normal normal Future Release task (blessed) new has-patch 2021-10-28T16:57:28Z 2022-10-17T10:23:56Z "This is the feature of showing notice when uploading a new version of an already installed theme/plugin
This ticket is to add E2E test for this feature" juhise 15
Has Patch / Needs Testing 60227 HTML API: Add external test suite Build/Test Tools normal normal 6.6 task (blessed) new has-patch 2024-01-10T15:31:28Z 2024-03-06T06:54:42Z "Problem:
The HTML API is a complex and important feature being implemented by a small group of developers. The implementation follows the HTML Standard https://html.spec.whatwg.org/.
The tests and the implementation of the HTML API both depend on the interpretation of the standard by the same small group of developers. This means there is a risk of misinterpretation or overlooked edge cases.
Needs:
A suite of tests that can serve to test the HTML API that does not depend on our own interpretation of the HTML Standard and is implementation agnostic.
Benefits:
Many software projects such as browsers implement the HTML Standard. We should be able to use a third-party implementation-agnostic test suite to validate our implementation of the HTML API. This mitigates the risk where our implementation and tests all derive from the same interpretation of the specification." jonsurrell 34
Has Patch / Needs Testing 59648 PHPUnit tests: Add/improve @covers annotations for WP 6.6 hellofromTonya Build/Test Tools 4.8 normal normal 6.6 task (blessed) reviewing has-patch 2023-10-17T12:08:13Z 2024-02-26T13:17:15Z "Previously:
* #58851 (6.4)
* #57958 (6.3)
* #56782 (6.2)
* #39265 (up to 6.1)
Continuation of ongoing work to add and/or improve the PHPUnit tests `@covers` annotations for more accurate coverage reporting." pbearne 22
Has Patch / Needs Testing 60306 PHPunit test for wp_enqueue_emoji_styles Build/Test Tools normal normal Awaiting Review task (blessed) new has-patch 2024-01-19T22:43:38Z 2024-02-28T17:41:04Z pbearne 3
Has Patch / Needs Testing 60705 Test tool and unit test improvements for 6.6 Build/Test Tools normal normal 6.6 task (blessed) new has-patch 2024-03-06T06:53:46Z 2024-03-06T06:58:16Z "Previously:
* #59647 (6.5)
* #58955 (6.4)
* #57841 (6.3)
* #56793 (6.2)
* #55652 (6.1)
* #54725 (6.0)
* #53363 (5.9)
* #52625 (5.8)
* #51802 (5.7)
* #51344 (5.6)
This ticket is for various fixes and improvements in PHPUnit tests that don't have a more specific ticket, as well as general improvements to the GitHub Actions workflows that run automated testing." SergeyBiryukov 2
Has Patch / Needs Testing 57844 Tests/Script Loader: Run build step in PHP Unit test actions. Build/Test Tools normal normal 6.6 task (blessed) new close 2023-03-02T04:00:26Z 2024-02-29T22:16:36Z "The files `src/wp-includes/assets/script-loader-react-*.php` are created during the NPM build and included within the script loader.
Unlike `src/wp-includes/assets/script-loader-packages.min.php`, these files are not included in the commit when updating WordPress packages.
As a result the PHP Unit actions are now throwing warnings due to the missing files:
{{{
Warning: include(/var/www/src/wp-includes/assets/script-loader-react-refresh-entry.php): failed to open stream: No such file or directory in /var/www/src/wp-includes/script-loader.php on line 243
Warning: include(): Failed opening '/var/www/src/wp-includes/assets/script-loader-react-refresh-entry.php' for inclusion (include_path='.:/usr/local/lib/php') in /var/www/src/wp-includes/script-loader.php on line 243
Warning: include(/var/www/src/wp-includes/assets/script-loader-packages.php): failed to open stream: No such file or directory in /var/www/src/wp-includes/script-loader.php on line 278
Warning: include(): Failed opening '/var/www/src/wp-includes/assets/script-loader-packages.php' for inclusion (include_path='.:/usr/local/lib/php') in /var/www/src/wp-includes/script-loader.php on line 278
Warning: Invalid argument supplied for foreach() in /var/www/src/wp-includes/script-loader.php on line 280
}}}
To resolve this, an `npm run build:dev` will need to be included in the phpunit actions." peterwilsoncc 31
Has Patch / Needs Testing 59482 Tests: Introduce Reflection API helper methods. costdev Build/Test Tools normal normal 6.6 task (blessed) assigned has-patch 2023-09-28T02:39:22Z 2024-02-26T11:05:32Z "In unit tests, the Reflection API is often used to get or set a `private` or `protected` property's value, or to invoke a `private` or `protected` method.
To do so, the `Reflection::setAccessible()` method must be called with `true` before use, then should be called again with `false` afterwards. There are quite a lot of instances in the test suite where the Reflection API is used, and for a decent number of these, accessibility is not reset.
For brevity, much like `assertSameSets()`, and to ensure that accessibility is always reset, this ticket aims to introduce new methods to the `WP_UnitTestCase_Base` class:
`::reflect_and_invoke( object $obj, string $method, mixed ...$args ) : mixed`
- Reflects a `private` or `protected` method and invokes it.
- Returns the method's return value.
`::reflect_and_get_value( object $obj, string $property ) : mixed`
- Reflects a `private` or `protected` property and gets its value.
- Returns the property's value.
`::reflect_and_set_value() : mixed`
- Reflects a `private` or `protected` property and sets its value.
- Returns the previous value for convenient resetting.
While this means the creation of new `Reflection` objects and two calls to `::setAccessible()` for each, I think that this is worthwhile as it helps us have a more robust test suite, with less code to write in test methods. Plus, we could also explore possible caching in future." costdev 5
Has Patch / Needs Testing 60706 Tests: Reduce usage of assertEquals for 6.6 Build/Test Tools normal normal 6.6 task (blessed) new has-patch 2024-03-06T06:55:52Z 2024-03-06T06:56:39Z "Follow-up to:
* #59655 (6.5)
* #58956 (6.4)
* #57855 (6.3)
* #56800 (6.2)
* #55654 (6.1)
* #54726 (6.0)
* #53364 (5.9)
* #52482 (5.8)
* #38266 (5.7)
The `assertEquals()` test method does not check that the types of the expected and actual values match. This can hide subtle bugs especially when the values are falsey.
Tasks:
* Switch to using `assertSame()` when the type of the value in the assertion is important
* Replace overall usage of `assertEquals()` with type-strict assertion methods, with the aim of potentially removing its usage altogether
To help ease the effort of merging tests, changes should also be made upstream in the Gutenberg repository." SergeyBiryukov 1
Has Patch / Needs Testing 54183 Tests: decide on how to handle deprecations in PHPUnit SergeyBiryukov Build/Test Tools normal normal Future Release task (blessed) assigned has-patch 2021-09-25T14:55:56Z 2022-10-05T09:42:35Z "PHPUnit just released version 9.5.10 and 8.5.21.
This contains a particular (IMO breaking) change which I believe we should have a think about how to handle:
> Changed
>
> * PHPUnit no longer converts PHP deprecations to exceptions by default (configure `convertDeprecationsToExceptions=""true""` to enable this)
> * The PHPUnit XML configuration file generator now configures `convertDeprecationsToExceptions=""true""`
== Let's unpack this:
Previously (PHPUnit < 9.5.10/8.5.21), if PHPUnit would encounter a PHP native deprecation notice, it would:
1. Show a test which causes a deprecation notice to be thrown as **""errored""**,
2. Show the **first** deprecation notice it encountered and
3. PHPUnit would exit with a **non-0 exit code** (2), which will fail a CI build.
[[Image(ticket:54183:deprecations-in-phpunit-9.5.9.png)]]
As of PHPUnit 9.5.10/8.5.21, if PHPUnit encounters a PHP native deprecation notice, it will no longer do so. Instead PHPUnit will:
1. Show a test which causes a PHP deprecation notice to be thrown as **""risky""**,
2. Show the **all** deprecation notices it encountered and
3. PHPUnit will exit with a **0 exit code**, which will show a CI build as passing.
[[Image(ticket:54183:deprecations-in-phpunit-9.5.10.png)]]
== Options
IMO, there are three options here:
==== 1. Leave as is. Deprecation notices means something will still work for the time being and will not change the behaviour of WordPress.
**Pro:**
- All deprecations caused by a particular test will be shown, not just the first.
**Con:**
- As CI builds pass, deprecations may go unnoticed, while they will eventually still need to be fixed as in the next PHP major will become errors.
- More deprecations will stay in WP, causing more churn from end-users reporting notices seen.
==== 2. Revert to the previous behaviour by adding `convertDeprecationsToExceptions=""true""` to the PHPUnit configuration.
**Pro:**
- Deprecation notices can not go unnoticed as CI builds will fail on them.
**Con:**
- You will only see the first deprecation notice for a test, there may be more issues hiding behind a deprecation.
- (minor) The PHPUnit configuration will no longer validate against the XSD scheme on PHPUnit 5/6/7.
==== 3. Add `failOnRisky=""true""` to the PHPUnit configuration.
**Pro:**
- All deprecations caused by a particular test will be shown, not just the first.
- Deprecation notices will cause the CI builds to fail, so can not go unnoticed.
**Con:**
- The WP test suite contains a number of other tests which are currently marked as ""risky"". These will now also cause a build to fail.
I personally favour option 2 or 3, but would love to see some more opinions on this.
Pinging @hellofromtonya @johnbillion @sergey @netweb for visibility.
Changelogs:
* https://github.com/sebastianbergmann/phpunit/blob/9.5/ChangeLog-8.5.md
* https://github.com/sebastianbergmann/phpunit/blob/9.5/ChangeLog-9.5.md
Related: #53363
" jrf 28
Has Patch / Needs Testing 53011 Tests: review all setUp() and tearDown() Build/Test Tools normal normal Awaiting Review task (blessed) new has-patch 2021-04-09T16:21:16Z 2022-06-04T15:32:27Z "The `setUpBeforeClass()`, `setUp()`, `tearDown()` and `tearDownAfterClass()` (and the WP test suite native variants of these) methods in test classes are used to set up fixtures which will be used by all tests in the test class.
Also see: https://phpunit.readthedocs.io/en/9.5/fixtures.html
For tests to properly be able to test just and only that which is being tested, we need to make sure that changes to the ""global state"" are undone after each test.
This includes:
* Changes to variables in `$GLOBALS`, changes to global variables via `global $var_name`.
* Changes to superglobals, like `$_GET`, `$_POST` or `$_REQUEST`.
* Filters being hooked or ''un''hooked to WordPress using `add_filter()`, `remove_filter()`, `add_action()`, `remove_action()` (and all their variations) calls in `setUp()` methods - or in the tests themselves.
* Changes in the file system - file being created by a test should be deleted after the test.
* And more contentiously: changes in the database ought to be undone after a test as well. This doesn't mean that any posts being created for a test and only being used by that test need to be deleted, but it does mean that any schema changes, any new tables created etc ''should'' be undone after the test.
At this time, the WP Core test suite does not consistently ""undo"" changes to the global state for each test, as @hellofromTonya and me found while reviewing tests for an unrelated patch.
We would like to recommend a full review of the test suite for best practices regarding global state resetting after each test.
Note: if a ""reset"" action is being done within the code of a test ''function'', it may not get executed when the tests fails. To that end, these type of ""reset""s should generally be done in the `tearDown()`, even when they only apply to one test in the test class.
The ""reset"", in that case, should be accompanied by a comment pointing to the test to which it applies." jrf 7
Has Patch / Needs Testing 53746 Tidy up the tearDown() methods Build/Test Tools normal normal Future Release task (blessed) new has-patch 2021-07-22T17:53:42Z 2022-06-04T15:32:47Z "The `tearDown()` method in several of the test classes perform redundant operations, for example removing or reinstating hooks, which are already taken care of in the base test class.
This means there's code that can be removed from these methods to tidy them up.
Related: #53011
Previously: [50463]" johnbillion 6
Has Patch / Needs Testing 43731 Use Webpack + NPM scripts to build all the things whyisjake* Build/Test Tools normal normal Future Release task (blessed) accepted has-patch 2018-04-10T12:44:12Z 2021-03-09T21:04:30Z "With [https://core.trac.wordpress.org/ticket/40894 the introduction of Webpack in WordPress core], we could consider using it to perform build tasks currently performed with Grunt.
The main advantage of having [https://webpack.js.org/ Webpack] build everything is that this would reduce the different tools developers would have to learn in the standard development process for WordPress core. NPM scripts would also make the available tools more discoverable and understandable through `package.json`.
Having a unified approach towards building / bundling also helps in other area's, such as general asset management and devtooling. It could for example be great if we could start using Webpack dev server at some point to serve assets in development and introduce [https://webpack.js.org/concepts/hot-module-replacement/ hot module replacement].
Webpack would be totally suitable for this goal, as can also be read from its documentation:
> Webpack is a module bundler. Its main purpose is to bundle JavaScript files for usage in a browser, yet it is also capable of transforming, bundling, or packaging just about any resource or asset.
Webpack provides a unified approach towards building. For example: It would be quite easy to configure Webpack to perform the following tasks:
- copying files: https://webpack.js.org/plugins/copy-webpack-plugin/
- uglification: https://webpack.js.org/plugins/uglifyjs-webpack-plugin/
- Sass to CSS compilation: https://github.com/webpack-contrib/sass-loader
- CSS post processing (autoprefixing) and linting: https://github.com/postcss/postcss-loader
- JS linting: https://github.com/webpack-contrib/eslint-loader
The above tasks are just some of the more prominent examples. But anything is possible really. NPM scripts can be used to invoke the separate tasks like linting, building etc." omarreiss 36
Has Patch / Needs Testing 59851 test for send_frame_options_header Build/Test Tools normal normal Awaiting Review task (blessed) new has-patch 2023-11-08T21:52:52Z 2024-03-03T18:16:50Z pbearne 3
Has Patch / Needs Testing 59816 Bump default theme versions for WordPress 6.5 Bundled Theme normal normal 6.5 task (blessed) new has-patch 2023-11-06T14:33:24Z 2024-03-12T05:39:55Z "All bundled themes from 2010 to 2024 will need a version bump for the 6.5 release.
Previously:
#58832 - 6.4
#57857 - 6.3
#57689 - 6.2
#56450 - 6.1
#55754 - 6.0
#54783 - 5.9
#53277 - 5.8
#52704 - 5.7
#51919 - 5.6
#50889 - 5.5
#49743 - 5.4" mukesh27 17
Has Patch / Needs Testing 60751 Add fallback for the default font folder path Editor trunk high normal 6.5 task (blessed) new has-patch 2024-03-11T20:34:57Z 2024-03-19T01:16:26Z "Implement this design decision:
> For installations that don’t support modification of the wp-content directory, the Font Library will use wp-content/uploads/fonts as a fallback location, ensuring we stay true to our project philosophy of designing for the majority while still making the feature available to anyone out of the box without extra steps from the user.
Reference: https://make.wordpress.org/core/2024/03/07/unblocking-wp6-5-font-library-and-synced-pattern-overrides/" mmaattiiaass 12
Has Patch / Needs Testing 60315 Editor: Update the WordPress packages to the latest versions for 6.5 Editor normal normal 6.5 task (blessed) assigned has-patch 2024-01-22T10:21:29Z 2024-03-19T08:06:35Z This ticket tracks updates to @wordpress npm packages for 6.5 release. youknowriad 77
Has Patch / Needs Testing 37486 Make emojis accessible Emoji 4.2 normal normal Future Release task (blessed) new has-patch 2016-07-27T15:01:59Z 2021-01-05T08:08:42Z "Splitting this out from #37432.
Currently, the WordPress Emojis are not accessible. The alt text contains the emoji character (vs a HTML encoded entity, or the emoji description) and that's a deliberate implementation choice, see [ticket:37433#comment:3] intended to allow copy and pasting the emojis.
We've discussed a bit this issue in the accessibility weekly meeting and agreed there's room for improvements. At least, starting a discussion about emojis accessibility would be very welcome.
Quickly checking how screen readers announce the WordPress emojis, there's no accessible name or description they can use:
[[Image(https://cldup.com/oioYLgdQ86.png)]]
Note: VoiceOver reads out ""group"" because the image is a `svg` file.
Just adding an `aria-label` attribute (I've quickly edited in the browser console) gives screen readers an accessible name to announce:
[[Image(https://cldup.com/xP0gzKlsnK.png)]]
Comparing with what others do, for example Twitter because they usually have great solutions for accessibility, they use `png` images and both an `aria-label` and a `title` attribute, so VoiceOVer in this example reads out both. I guess the title attribute is used just to show the browser's ""tooltip"" with the emoji name:
[[Image(https://cldup.com/MwMY0nHtoQ.png)]]
{{{
}}}
The aria-label solution is mentioned also on a related issue on the twemoji GitHub: https://github.com/twitter/twemoji/issues/41" afercia 19
Has Patch / Needs Testing 60700 Coding Standards fixes for WP 6.6 General normal normal 6.6 task (blessed) new has-patch 2024-03-06T05:03:13Z 2024-03-18T15:44:26Z "Previously:
- #59650 (6.5)
- #58831 (6.4)
- #57839 (6.3)
- #56791 (6.2)
- #55647 (6.1)
- #54728 (6.0)
- #53359 (5.9)
- #52627 (5.8)
- #51799 (5.7)
- #50767 (5.6)
- #49542 (5.5)
- #49222 (5.4)
- #47632 (5.3)
- #45934 (5.1)" mukesh27 6
Has Patch / Needs Testing 41121 Consistency of the _deprecated_function() calls and related documentation. SergeyBiryukov General 4.9 normal normal Future Release task (blessed) reviewing has-patch 2017-06-22T03:00:23Z 2023-07-06T11:14:14Z "While working on [https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards/pull/979 updating the `WP.DeprecatedFunctions` sniff] which is part of the [https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards/ WordPress Coding Standards] project, we've come across a number of inconsistencies in the application of the function and/or the related documentation.
@jdgrimes previously already reported this concerning three functions in #41094 (has its own patch in that ticket), however since then a lot more inconsistencies have been identified.
In a series of patches which I will add to this ticket I will address these:
=== Patch 1: Fix deprecation info in various docblocks
* Fix incorrect deprecation comment naming the deprecated function as its own alternative
* Fix typo in docblock `@deprecated` tag which meant that deprecation is not indicated on the dev ref website
* Add missing `@deprecated` tags for two functions
* Add missing alternative in `@deprecated` comment for `wp_get_sites()`
=== Patch 2: Add missing replacement functions to various `_deprecated_function()` calls
* Add missing parentheses to a few deprecated function replacement function strings to be consistent with how this is done everywhere else.
* Add missing alternative for the WP_Customize Widget deprecated methods.
* Add missing alternative for three deprecated ms functions
* Add missing alternative for deprecated `wp_cache_reset()` function
=== Patch 3: Add missing `_deprecated_function()` function calls to various functions
* Add missing `_deprecated_function()` call for `funky_javascript_callback()`
* Add missing `_deprecated_function()` call for `_save_post_hook()`.
* Add missing `_deprecated_function()` call for `default_topic_count_text()`.
* Add missing `_deprecated_function()` call for `screen_meta()`.
* Add missing `_deprecated_function()` call for two screen icon related functions
* Add missing `_deprecated_function()` call for nine wp_dashboard related functions
* Add missing `_deprecated_function()` call for `wp_ajax_wp_fullscreen_save_post()`.
* Add missing `_deprecated_function()` call for `ms_deprecated_blogs_file()`
=== Patch 4: Add missing `_deprecated_function()` calls to various deprecated class methods
* Add `_deprecated_function()` calls to all methods within the deprecated WP_User_Search class.
* Add missing `_deprecated_function()` call for four methods in WP_Customize_Image_Control
=== Patch 5: Add missing `_deprecated_function()` calls for four deprecated pluggable functions.
Not all functions complied with what the docblock at the top of the files states:
> Deprecated warnings are also thrown if one of these functions is being defined by a plugin." jrf 46
Has Patch / Needs Testing 52699 Flash is dead General low normal Future Release task (blessed) reopened has-patch 2021-03-03T06:08:42Z 2022-07-29T16:39:21Z "Hello,
since Adobe does not support Flash anymore and nearly all browsers and OS too, I think it does not make sense to include follow things:
- swfobject
- flash fallback for upload
- pupload flash
" mkeck 3
Has Patch / Needs Testing 53465 PHP 8.1.: the default value of the flags parameter for htmlentities() et all needs to be explicitly set hellofromTonya General normal normal 6.6 task (blessed) assigned has-patch 2021-06-20T18:19:22Z 2024-02-26T16:59:59Z "From the PHP 8.1 changelog:
> `htmlspecialchars()`, `htmlentities()`, `htmlspecialchars_decode()`,
> `html_entity_decode()` and `get_html_translation_table()` now use
> `ENT_QUOTES | ENT_SUBSTITUTE` rather than `ENT_COMPAT` by default. This means
> that `'` is escaped to `'` while previously it was left alone.
> Additionally, malformed UTF-8 will be replaced by a Unicode substitution
> character, instead of resulting in an empty string.
Ref: https://github.com/php/php-src/blob/28a1a6be0873a109cb02ba32784bf046b87a02e4/UPGRADING#L149-L154
If effect this means that the output of the above mentioned functions may be different depending on the PHP version and the passed text string, unless the `$flags` parameter is explicitly passed.
I've run an initial scan over WordPress core with a new (not yet published) sniff for PHPCompatibility and this flags 33 issues.
* 1 issue in GetID3 which should be fixed upstream and the copy of GetID3 used in WP should be updated once the issue is fixed.
* 1 issue in PHPMailer which should be fixed upstream and the copy of PHPMailer used in WP should be updated once the issue is fixed.
* 1 issue in SimplePie which should be fixed upstream and the copy of SimplePie used in WP should be updated once the issue is fixed.
* And 30 issues in WP Core native code or code from external dependencies which are no longer maintained externally.
Detailed issue list: https://gist.github.com/jrfnl/9d56b4053faa62a0fe91dea1b14839bf
To fix this issue, the `$flags` parameter should be explicitly passed in each of these function calls.
Some investigation will be needed for each of these instances to determine what will be the optimal value for `$flags`.
Take note that the ""old"" parameter default in the function signature is documented as `ENT_COMPAT`, while in the parameter detail documentation, it states that the default, in actual fact, is ` ENT_COMPAT | ENT_HTML401`.
However, by the looks of it, the full range of flag constants is available to us, which is at least one less problem.
There is no mention of any of the flags being added since PHP 5.6.
Ref: https://php-legacy-docs.zend.com/manual/php5/en/string.constants
It is **strongly** recommended to make sure that for each of these at least one unit test exists which exposes the difference in output between PHP < 8.1 and PHP 8.1 to safeguard the fixes which will be added for the future.
Also see:
* https://www.php.net/manual/en/function.htmlentities.php
* https://www.php.net/manual/en/function.html-entity-decode.php
* https://www.php.net/manual/en/function.htmlspecialchars.php
* https://www.php.net/manual/en/function.htmlspecialchars-decode.php
* https://www.php.net/manual/en/function.get-html-translation-table.php" jrf 25
Has Patch / Needs Testing 56009 Prepare for PHP 8.2 General normal normal 6.6 task (blessed) new has-patch 2022-06-19T23:09:04Z 2024-02-17T16:12:46Z "This is a meta ticket to track the efforts to prepare for PHP 8.2.
For PHP 8.0/PHP 8.1 specific fixes, please refer to the generic WP 6.1 PHP 8.x ticket: #55656
Please link patches related to a specific PHP 8.2 related task to the appropriate dedicated issue, if there is one (see the links in the description below).
Generic/one-off PHP 8.2 related patches can be linked to this ticket.
----
== PHP 8.2: Important dates
PHP 8.2 is [https://wiki.php.net/todo/php82 expected to be released on November 24 2022].
Other note-worthy dates:
* The first alpha was released on June 9th 2022.
* Feature freeze will be on July 19, 2022.
**Note**:
The below represents the status per June 20, 2022. As PHP 8.2 is not yet in feature freeze, these statuses can still deteriorate based on additional RFCs being accepted/implemented.
== Readiness of essential tooling
=== [https://github.com/composer/composer Composer]
Current status:
* CI for Composer itself is being run against PHP 8.2.
* No known issues in the last release (2.3.7).
=== [https://github.com/sebastianbergmann/phpunit PHPUnit]
Current status:
* CI for PHPUnit itself is being run against PHP 8.2.
* No known issues in the last release (9.5.21).
=== [https://github.com/Yoast/PHPUnit-Polyfills PHPUnit Polyfills]
Current status:
* CI for PHPUnit Polyfills itself is being run against PHP 8.2.
* No known issues in the last release (1.0.3).
=== [https://github.com/wp-cli/wp-cli WP-CLI]
Current status:
* CI for WP-CLI is NOT (yet) being run against PHP 8.2.
* **''Status unknown''**.
=== Other tooling
Other tooling doesn't necessarily have to run against PHP 8.2 (yet), so has not been evaluated.
== Initial DevOps Tasks
Typical tasks which need to be executed to allow WordPress to prepare for PHP 8.2:
=== [https://github.com/WordPress/wpdev-docker-images Docker]
* Add PHP 8.2 to the Docker images. A [https://github.com/WordPress/wpdev-docker-images/pull/87 PR for this] was merged on Jun 23, 2022
=== GitHub Actions
**TODO:**
* Add PHP 8.2 to the GitHub Actions `phpunit-tests.yml` configuration.
Status: Committed in [53922]
Notes:
- Test failures on PHP 8.2 should not (yet) fail the build.
- The `composer install` will most likely need to run with `--ignore-platform-req=php` as not all dependencies of PHPUnit 9.x have declared compatibility with PHP 8.2 yet.
== PHP 8.2 changes for which WordPress will need to prepare
Similar to the rest of this ticket, this list is based on the current status of PHP 8.2 and still subject to change.
=== [https://wiki.php.net/rfc/deprecate_dollar_brace_string_interpolation Deprecation of ${} string interpolation]
Only two small issues + one in the tests.
This was being tracked in #55787. Committed in [54134]
=== [https://wiki.php.net/rfc/remove_utf8_decode_and_utf8_encode Deprecation of utf8_encode and utf8_decode]
The issue will not affect WordPress Core much, but **will** have a significant impact on plugins/themes.
The recommendation is to make the MbString extension a requirement for WP Core to help plugins/themes mitigate this.
This is being tracked in #55603.
=== [https://wiki.php.net/rfc/deprecate_partially_supported_callables Deprecation of partially supported callables]
No significant problems expected in WP Core.
WordPress does use callables extensively, but the particular type of callables being deprecated are not typically used within WordPress.
=== [https://wiki.php.net/rfc/deprecate_dynamic_properties Deprecate dynamic properties]
This is the big one and I expect a HUGE amount of problems due to this.
In my opinion two groups of patches are needed to at least try and mitigate this. ~~I intend to write up the details for this in two separate tickets over the next week or so.~~
I have opened two tickets to track and address these issues:
* #56033 for ""known"" dynamic properties which should be declared on the class.
* #56034 for ""unknown"" dynamic properties
Ticket #55357 is related to this, but should not be actioned in isolation.
=== [https://wiki.php.net/rfc/strtolower-ascii Locale-independent case conversion]
Needs investigation if and if so, how extensive the impact will be on WordPress.
If there is any impact, making the MbString extension a requirement for WP Core would likely go a long way to mitigate this.
=== [https://wiki.php.net/rfc/mysqli_support_for_libmysql Remove support for libmysql from mysqli]
This is primarily an issue which may impact webhosts.
No direct impact on WordPress itself is expected.
== Status of External Dependencies
=== [https://github.com/JamesHeinrich/getID3 GetID3]
Current status:
* A [https://github.com/JamesHeinrich/getID3/pull/385 PR has been merged] to enable linting against PHP 8.2. The build passes without finding any PHP 8.2 related issues.
* **Important**: the project has no test suite, so the linting passing on PHP 8.2 is only a small comfort and does not provide any real security.
* In other words: **''status unknown''**.
* WordPress is using the latest version (1.9.21), see #54162
=== [https://github.com/PHPMailer/PHPMailer PHPMailer]
Current status:
* Linting and tests are being run against PHP 8.2.
* No known issues in the last release (6.6.2).
* WordPress is using the latest version, see #55976
=== [https://github.com/paragonie/random_compat Random Compat]
Current status:
* A [https://github.com/paragonie/random_compat/pull/180 PR has been merged] to enable running of the tests against PHP 8.2. The build passes without finding any PHP 8.2 related issues.
* No known issues in the last release (2.0.21).
* WordPress is using the latest version, see #55181
=== [https://github.com/WordPress/Requests Requests]
Current status:
* A [https://github.com/WordPress/Requests/pull/751 PR was opened] to enable running of linting and tests against PHP 8.2. The PR build found one, test-only, issue in Requests for PHP 8.2, which has no impact on the production code.
* No known issues in the last release (2.0.3).
* WordPress was upgraded to `2.0.0` via [54997] (see #54504)
I've done a test run of Requests 1.8.1 against PHP 8.2 and based on the tests and aside from the already known PHP 8.1 deprecations, there are no relevant PHP 8.2 issues known at this moment.
=== [https://github.com/simplepie/simplepie SimplePie]
Current status:
* A [https://github.com/simplepie/simplepie/pull/739 PR is open] to enable running of the tests against PHP 8.2. The PR build passes without finding any PHP 8.2 related issues.
* No known issues in the last release (1.6.0).
* WordPress is behind and is still using version `1.5.8`, while the latest release is `1.6.0`, see #55604
I've done a test run of SimplePie 1.5.8 against PHP 8.2 and based on the tests, there are no relevant PHP 8.2 issues known at this moment.
=== [https://github.com/paragonie/sodium_compat Sodium Compat]
Current status:
* A [https://github.com/paragonie/sodium_compat/pull/146 PR has been merged] to enable running of the tests against PHP 8.2. The build passes without finding any PHP 8.2 related issues.
* No known issues in the last release (1.17.1).
* WordPress is using the latest version, see #55453 / [52988].
" jrf 42
Has Patch / Needs Testing 59231 Prepare for PHP 8.3 General 6.4 normal normal 6.6 task (blessed) new has-patch 2023-08-28T23:15:51Z 2024-02-17T16:12:34Z "This is a meta ticket to track the efforts to prepare for PHP 8.3.
For PHP 8.0/8.1/8.2 specific fixes, please refer to the generic WP 6.4 PHP 8.x ticket: #58850
Please link patches related to a specific PHP 8.3 related task to the appropriate dedicated issue, if there is one (see the links in the description below).
Generic/one-off PHP 8.3 related patches can be linked to this ticket.
----
== PHP 8.3: Important dates
PHP 8.3 is [https://wiki.php.net/todo/php83 expected to be released on November 23 2023].
Other note-worthy dates:
* The first alpha was released on June 8th 2023.
* Feature freeze started on July 18, 2023.
**Note**:
The below represents the status per August 28, 2023. As PHP 8.3 is in feature freeze, these statuses should be reasonably reliable.
== Readiness of essential tooling
=== [https://github.com/composer/composer Composer]
Current status:
* CI for Composer itself was not yet being run against PHP 8.3. I've opened [https://github.com/composer/composer/pull/11601 a PR] for this. ''[JRF: this PR has since been merged]''
* I've ran linting, PHPCompatibility (bleeding edge) and the test suites against PHP 8.3 and found no problems for PHP 8.3 though.
* The only issues I've managed to identify are in the test suite of Composer, which has no impact on end-users of Composer.
=== [https://github.com/sebastianbergmann/phpunit PHPUnit]
Current status:
* CI for PHPUnit itself is being run against PHP 8.3.
* No known issues in the last release supported for the WP test suite (9.6.11).
=== [https://github.com/Yoast/PHPUnit-Polyfills PHPUnit Polyfills]
Current status:
* CI for PHPUnit Polyfills itself is being run against PHP 8.3.
* No known issues in the last release (1.1.0).
=== [https://github.com/wp-cli/wp-cli WP-CLI]
Current status:
* CI for WP-CLI was not (yet) being run against PHP 8.3. A [https://github.com/wp-cli/.github/pull/68 PR to change this has been opened and merged].
* **''Status unknown''**.
=== Other tooling
Other (PHP) tooling doesn't necessarily have to run against PHP 8.3 (yet), so has not been evaluated.
== Initial DevOps Tasks
Typical tasks which need to be executed to allow WordPress to prepare for PHP 8.3:
=== [https://github.com/WordPress/wpdev-docker-images Docker]
* Add PHP 8.3 to the Docker images. A [https://github.com/WordPress/wpdev-docker-images/pull/113 PR for this] was merged on July 26, 2023
=== GitHub Actions
* Add PHP 8.3 to the GitHub Actions `phpunit-tests.yml` configuration. [https://github.com/WordPress/wordpress-develop/pull/5106 GH PR #5106] ''[JRF: this PR has since been merged]''
Notes:
- Test failures on PHP 8.3 should not (yet) fail the build, but as the actual script to run the tests has been moved, it is currently impossible to use `continue-on-error` as that keyword is not supported when calling a reusable workflow... /cc @desrosj
== PHP 8.3 changes for which WordPress will need to prepare
=== [https://wiki.php.net/rfc/deprecations_php_8_3 Generic deprecations for PHP 8.3]
Based on initial (bleeding edge) PHPCompatibility scans + the tests, WP is not affected by the deprecations which passed from this RFC (not all of them did).
=== [https://wiki.php.net/rfc/deprecate_functions_with_overloaded_signature Deprecation of functions with overloaded signatures]
This RFC only partially affects PHP 8.3. If a replacement is readily available already, the deprecation of the overloaded signature takes place in PHP 8.3.
If no replacement was available, the replacement functions are being introduced in PHP 8.3 and the actual deprecation of the overloaded signature takes place in PHP 8.4.
Based on initial (bleeding edge) PHPCompatibility scans + the tests, WP is affected by two of the deprecations in PHP 8.3:
* `get_class()` and `get_parent_class()` - this is already being tracked in #58876, there is a patch available, which IMO is ready for commit. ''[JRF: the PR for this has since been merged]''
* `ReflectionProperty::setValue()` with static properties. [https://github.com/WordPress/wordpress-develop/pull/5105 GH PR #5105] ''[JRF: this PR has since been merged]''
The other deprecations in this RFC do not appear to affect WP Core at this time.
There is one - `stream_context_set_option()`, which will impact Requests, but only in PHP 8.4 and [https://github.com/WordPress/Requests/pull/822 a patch has already been pulled] for this.
=== [https://wiki.php.net/rfc/saner-inc-dec-operators Saner increment/decrement operators]
To my surprise, I have not found any issues in WP with this change based on the tests alone, but I would not be surprised if the odd issue around this gets reported over time.
=== [https://wiki.php.net/rfc/marking_overriden_methods Marking overridden methods]
This is a new feature with limited validation functionality attached. The attribute basically allows to mark methods in a (child) class/interface which overload a method in a parent class or from an interface, as doing so intentionally.
Per the RFC:
> ... being able to express if a method is intended to override another method or implement an interface would make it easier to debug a mistake, to refactor and to clean up existing code. Another possible use case is to easily detect a possibly breaking change in a parent class that was provided by a library without needing to read the changelog in detail or missing some item in the list of changes
I'd like to advocate for adding these attributes to WP Core in all the relevant places as it:
* Increases awareness of the method overload for contributors.
* Can serve as a warning that the method signature should not be touched (unless the parent method signature changes).
* Has no downside as attributes are ignored in older PHP versions and in PHP versions where the attribute referenced does not exist.
In the rare case that the attribute, once added, would result in a fatal error, that would be fantastic, as that means we have actually found a bug in WP before it got into a stable release.
Separate ticket to allow for discussing this proposal in more detail and for patches: #59232.
=== [https://wiki.php.net/rfc/unserialize_warn_on_trailing_data Make unserialize() emit a warning for trailing bytes]
While based on the current test suite, WP is not ''directly'' affected by this, the [https://developer.wordpress.org/reference/functions/maybe_unserialize/ `maybe_unserialize()`] function could still be confronted by data with trailing bytes.
However, the call to the PHP native `unserialize()` within `maybe_unserialize()` silences all (PHP 8.0+: non-fatal) errors, so this new warning will not affect WP or its ecosystem as long as the `maybe_unserialize()` function is used.
Having said that, a critical look at `maybe_unserialize()` may be warranted as the new warning in PHP is related to security issues discovered in other projects, so WP may want to consider rejecting unserialization for data throwing this warning.
Also note that there are 7 uses of `unserialize()` in total within WP Core, one within `maybe_unserialize()`, but the function is also used in 6 other places and 5 of those do not use error silencing.
=== [https://wiki.php.net/rfc/improve_unserialize_error_handling Improve unserialize() error handling]
This, again, affects the [https://developer.wordpress.org/reference/functions/maybe_unserialize/ `maybe_unserialize()`] function and this time, the code should probably be adjusted to handle the new errors which `unserialize()` can now throw.
The change does not affect unserializing valid data, but in the case of invalid data, the type of and severity of the notices/warnings/catchable exceptions have been changed.
All 7 uses of `unserialize()` in WP Core should be reviewed and for the 6 uses outside of the `maybe_unserialize()` function, it should be reviewed whether they can/should switch to using `maybe_unserialize()` and/or whether they should get their own (improved) error handling.
Separate ticket to allow for discussing this and the previously listed RFC in more detail and for patches: #59233.
=== [https://wiki.php.net/rfc/assert-string-eval-cleanup Deprecate remains of string evaluated code assertions]
As WP Core does not use assertions, it is not affected by the changes in this RFC.
Plugins/themes may still be affected, though I'd hope none of those would use `assert()`.*
* `assert()` is intended for dev-only use. The behaviour of `assert()` is heavily affected by ini settings which cannot be changed at runtime, which means that end-users may be confronted by unexpected fatal errors due to the use of `assert()` if they run on an incorrectly configured webhost.
=== [https://wiki.php.net/rfc/proper-range-semantics Define proper semantics for range() function]
This RFC adds a number of errors and warnings for incorrect use of the `range()` function.
WP Core has 8 uses of this function in `src`, 2 in `class-wp-text-diff-renderer-table.php` and 6 in various files from external dependencies.
I've visually reviewed each of these and they all look to be okay, though a check to safeguard that the WP native uses are covered sufficiently by tests would be prudent. [TODO]
=== [https://wiki.php.net/rfc/datetime-exceptions More Appropriate Date/Time Exceptions]
This RFC reclassifies warnings and errors from the DateTime extension to catchable Exceptions when the OO-interface is used (procedural use of the DateTime functionality is not affected).
Based on the tests, WP Core is not affected by this and as the DateTime use of WP Core is pretty well tested, I'm fairly confident, we'll be fine.
=== [https://wiki.php.net/rfc/json_validate New json_validate() function]
This function is a high-performance way to validate json prior to decoding it. This function cannot be polyfilled without a performance hit.
However, due to the potential for using json for Denial-of-Service attack vectors (via a HUGE file/stream), I would strongly recommend for WP Core to start using this new function in all appropriate places wrapped within an `if ( function_exists() ) {}`.
The `json_decode()` function is used 44 times within `src` (excluding external dependencies).
We may want to consider introducing a `wp_json_decode()` function to ensure the use of `json_validate()` (when available).
This would then mirror the already existing [https://developer.wordpress.org/reference/functions/wp_json_encode/ `wp_json_encode()`] function.
See: #59234
== Status of External Dependencies
=== [https://github.com/JamesHeinrich/getID3 GetID3]
Current status:
* Linting is enabled against PHP 8.3. The build passes without finding any PHP 8.3 related issues.
* **Important**: the project has no test suite, so the linting passing on PHP 8.3 is only a small comfort and does not provide any real security.
* In other words: **''status unknown''**.
* WordPress is using the latest version (1.9.22), see #56692
=== [https://github.com/PHPMailer/PHPMailer PHPMailer]
Current status:
* Linting and tests are being run against PHP 8.3.
* No known issues in the last release (6.8.0) (aside from something in the PHPMailer test suite, which doesn't affect WP).
* WordPress is using the latest version, see #57873
=== [https://github.com/WordPress/Requests Requests]
Current status:
* Linting and tests are being run against PHP 8.3.
* No known issues in the last release (2.0.7) (aside from something in the Requests test suite, which doesn't affect WP).
* WordPress is using the latest relevant version `2.0.6`, see #58079. Requests 2.0.7 only updated the certificates bundle, while WP uses its own)
=== [https://github.com/simplepie/simplepie SimplePie]
Current status:
* Tests are being run against PHP 8.3.
* No known issues in the current `master` branch.
* WordPress is behind and is still using version `1.5.8`, while the latest release is `1.6.0`, see #55604
I've done a test run of SimplePie 1.5.8 against PHP 8.3 and based on the tests, there are no relevant PHP 8.3 issues known at this moment.
=== [https://github.com/paragonie/sodium_compat Sodium Compat]
Current status:
* A [https://github.com/paragonie/sodium_compat/pull/160 PR has been opened] to enable running of the tests against PHP 8.3. The build passes without finding any PHP 8.3 related issues. ''[JRF: this PR has since been merged]''
* No known issues in the last release (1.20.0).
* WordPress is using the latest version, see #58224.
=== [https://github.com/openwall/phpass PHPass]
Current status:
* Tests are being run against PHP 8.3.
* No known issues in the current `main` branch, which translates to the `0.5.4` version.
* WordPress is using version `0.5.0`, but the script is a little out of sync with upstream, though not in a way that it impacts the running of WP on PHP 8.3." jrf 13
Has Patch / Needs Testing 52264 Rename `$array` when used in `@param` tags General normal normal Future Release task (blessed) new has-patch 2021-01-08T22:38:56Z 2022-02-25T18:55:08Z "Related: #52243
Several functions, filters and actions pass `$array` as a parameter.
Usage of `$array` in `@param` tags for actions and filters should be replaced with a more appropriate (and descriptive) variable name.
Example:
In `class-requests.php`
{{{
/**
* Convert a key => value array to a 'key: value' array for headers
*
* @param array $array Dictionary of header values
* @return string[] List of headers
*/
public static function flatten($array) {
}}}
Could be replaced with:
{{{
/**
* Convert a key => value array to a 'key: value' array for headers
*
* @param array $headers Dictionary of header values
* @return string[] List of headers
*/
public static function flatten( $headers ) {
}}}" audrasjb 10
Has Patch / Needs Testing 60648 Update the `$_old_files` array for 6.5 swissspidy* General normal normal 6.5 task (blessed) accepted has-patch 2024-02-27T16:43:31Z 2024-03-06T06:54:12Z "Updating from 6.4 to 6.5 Beta 3 results in the following files being removed:
{{{
File removed: wp-includes/ID3/license.commercial.txt
File removed: wp-includes/blocks/query/style-rtl.min.css
File removed: wp-includes/blocks/query/style.min.css
File removed: wp-includes/blocks/query/style-rtl.css
File removed: wp-includes/blocks/query/style.css
File removed: wp-admin/images/about-header-privacy.svg
File removed: wp-admin/images/about-header-about.svg
File removed: wp-admin/images/about-header-credits.svg
File removed: wp-admin/images/about-header-freedoms.svg
File removed: wp-admin/images/about-header-contribute.svg
File removed: wp-admin/images/about-header-background.svg
}}}
See also https://make.wordpress.org/core/handbook/about/release-cycle/releasing-major-versions/#dry-run
While there is an initial patch already, please double check before committing." swissspidy 4
Has Patch / Needs Testing 60303 About Page for 6.5 Release Help/About normal normal 6.5 task (blessed) new has-patch 2024-01-19T19:17:45Z 2024-03-12T15:00:41Z "This ticket will serve as a hub for the discussion, planning, design, and other related work for creating the WordPress 6.5 About page.
Anyone involved in the release is invited to follow this ticket as part of their release-related duties and offer their input. " laurlittle 63
Has Patch / Needs Testing 49631 Test coverage for media_sideload_image() _source_url meta killua99 Media 5.4 normal normal Future Release task (blessed) assigned has-patch 2020-03-12T14:38:46Z 2020-10-22T14:21:30Z "Since #48164 when an image is sideloaded we store the original attachment URL in `_source_url`. There should be test coverage across this feature that validates that the meta is being properly stored.
@pbiron mentioned in the Media meeting where this was discussed that there are currently no existing tests around the `media_sideload_image()` function. This would be a great start to getting that covered.
@joemcgill also mentioned that ""You may want to consider writing the test in a way that sideloads an image that is already available on the test site.""
Link to media meeting where this took place: https://wordpress.slack.com/archives/C02SX62S6/p1584022312111000" antpb 13
Has Patch / Needs Testing 55645 Docs: Improve the documentation for `plugins_api()`. Plugins 2.7 normal normal Future Release task (blessed) new has-patch 2022-05-02T02:23:02Z 2024-02-19T20:37:31Z "The docblock for [https://developer.wordpress.org/reference/functions/plugins_api/ plugins_api()] needs some improvement, including:
- it does not document the make-up of possible return values.
- it has a self-reference in the `@return` annotation.
Related ticket: #55480" costdev 14
Has Patch / Needs Testing 41459 Introduce a REST API endpoint for networks / network options REST API normal normal Future Release task (blessed) new has-patch 2017-07-27T16:55:56Z 2020-04-03T04:51:03Z "Similar to sites in #40365, there should be a networks endpoint as part of the REST API.
Through recent multisite discussions, we have come to the conclusion that, while multi-network should never be part of core, there should be basic and unopinionated APIs present that can be used by whoever wants to implement it.
A basic networks API in these terms implies that it's a simple CRUD API for the `wp_site` database table. #29411 will introduce the internal core functions that this endpoint will be able to use.
The endpoint should be able to do the following:
* List networks: `GET wp/v2/networks/`
* Retrieve a network: `GET wp/v2/networks/`
* Create a network: `POST wp/v2/networks/`
* Update a network: `PUT wp/v2/networks/`
* Delete a network: `DELETE wp/v2/networks/`
Once the changes in #25344 is in place, a network meta endpoint should be created as well. For now this will be part of this ticket too.
Note that this ticket is an early one and will lay around for a while. The other non-network-related roadmap items have a higher priority." flixos90 6
Has Patch / Needs Testing 18289 Direct link to plugin installation should have admin chrome Upgrade/Install normal normal Future Release task (blessed) reviewing has-patch 2011-07-29T06:02:19Z 2022-08-02T19:37:24Z "We should be able to provide a direct link to the page to install a plugin, based on the plugin's slug. This does it: wp-admin/plugin-install.php?tab=plugin-information&plugin=log-deprecated-notices. However, there's no admin chrome, no real indication which site you're on, and no name of the plugin.
If we're not loading that page inside an iframe request, it needs the admin around it, as well as a heading. Probably new styling too.
This would serve as a replacement for [http://coveredwebservices.com/wp-plugin-install/ Jaquith's bookmarklet], which broke in 3.2 (frame busting), as well as allow us to integrate a link on extend/plugins for plugin installation. Related, #16923, which is now closed." nacin 15
Changes Requested 51126 Document the update offer parameter for auto updates desrosj Upgrade/Install normal normal Future Release task (blessed) reviewing changes-requested 2020-08-24T21:37:54Z 2022-10-10T15:21:25Z "The ""update offer"" for auto updates gets retrieved from the updates API, passed between methods, stored in transients, and sent through filters. Its shape should be documented in all these places." johnbillion 36
Has Patch / Needs Testing 39309 Secure WordPress Against Infrastructure Attacks Upgrade/Install 4.8 normal critical Future Release task (blessed) assigned has-patch 2016-12-16T17:50:14Z 2022-05-26T22:30:44Z "(Similar to #25052 but much more focused on the implementation details)
== Background ==
Recommended reading:
1. http://seclists.org/oss-sec/2016/q4/478
2. https://www.wordfence.com/blog/2016/11/hacking-27-web-via-wordpress-auto-update/
3. https://paragonie.com/blog/2016/10/guide-automatic-security-updates-for-php-developers
Currently, if an attacker can compromise api.wordpress.org, they can issue a fake WordPress update and gain access to every WordPress install on the Internet that has automatic updating enabled. We're two minutes to midnight here (we were one minute to midnight before the Wordfence team found that vulnerability).
Given WordPress's ubiquity, an attacker with control of 27% of websites on the Internet is a grave threat to the security of the rest of the Internet. I don't know how much infrastructure could withstand that level of DDoS. (Maybe Google?)
The solution is to make the automatic update mechanism secure **even if the update server is totally owned up**. As published in the third link, the core elements of a totally secure automatic update system are:
1. Offline Cryptographic Signatures
2. Reproducible Builds
3. Decentralized Authenticity / Userbase Consistency Verification
4. Transport-Layer Security
5. Mirrors and Other Availability Concerns
6. Separation of Privileges
However, I'm mostly interested in 1, 2, and 3. I believe 4 is already implemented (if not, this just became a lot scarier).
== Proposed Solution ==
We're going to have to roll this out in phases, rather than all at once.
1. Offline Cryptographic Signatures
1. Decide on a digital signature algorithm and/or cryptography library to use.
2. Generate a keypair for the release managers to use.
3. Pin the public key in a major release (e.g. 4.8 or 4.9).
4. Add signature verification to the update process, but for the first release or two, **don't enforce it**. Just collect data until we're sure it works for everyone.
5. Enforce digital signatures. Then this is satisfied.
2. Reproducible Builds.
1. The update file should be easily reproduced by any end user.
2. The update file and update served by api.wordpress.org should be easily verifiable.
3. We wrote Pharaoh for auditing PHP Archives; something similar may be useful for WP updates: https://paragonie.com/project/pharaoh
3. Decentralized Authenticity / Userbase Consistency Verification
* See below.
4. Make plugin/theme updates secure.
Once core updates are secure, the next step is to allow plugin/theme developers to upload their own public keys which can be used to sign their own extensions.
If you want a reference implementation, we already have a working secure automatic update system built into CMS Airship (which is GPL 3):
* https://paragonie.com/blog/2016/05/keyggdrasil-continuum-cryptography-powering-cms-airship
* https://github.com/paragonie/airship/blob/master/src/Engine/Continuum.php
* https://github.com/paragonie/airship/blob/master/src/Engine/Keyggdrasil.php
=== Decentralized Authenticity ===
In CMS Airship, we're totally decentralized: Every Airship maintains its own record of every update file or new/revoked public key since its inception. (This is because CMS Airship aims for maximum security.)
For WordPress, I'm recommending a federated model instead, but the concepts are mostly the same:
1. Notaries (WordPress blogs or other services that opt in to hosting/verifying the updates) will mirror a Merkle tree which contains (with timestamps and signatures):
* Any new public keys
* Any public key revocations
* Cryptographic hashes of any core/extension updates
2. WordPress blogs will have a pool of notaries they trust explicitly. (This can be provided by your hosting provider, who runs the single source of truth for all their clients, so long as they themselves practice due diligence.)
3. When an update is received from the server, after checking the signature against the WP core's public key, they will poll at least one trusted Notary (send a challenge nonce, current timestamp, a checksum of the update file, and any other useful identifying metadata e.g. ""wp-core version 4.9.2""). The Notary will verify that the update exists and matches the checksum on file, and respond with a signed message containing:
* The challenge nonce
* The response timestamp
* Whether or not the update was valid
This will be useful in the event that the WP.org's signing key is ever compromised by a sophisticated adversary: If they attempt to issue a silent, targeted update to a machine of interest, they cannot do so reliably: To pull off their attack, they have to allow the Merkle tree (that is mirrored by every Notary) to record/broadcast evidence of their attack in order for it to succeed. So while targeted attacks may still be theoretically possible, it will no longer be possible to do them silently.
In addition to a security layer, it's a deterrent against the most sophisticated threats.
=== Securing Plugins and Themes ===
This will probably be the last piece tackled. Basically: Offer the same signing capabilities to theme/plugin developers that will already be in the hands of the core team.
This can be done piecemeal (i.e. optional field on WP.org that allows them to upload their public key, generated by some tooling we provide developers). We should incentivize packages that provide their own signature by, for instance, placing them higher in the listings and/or giving them an attractive and desirable UI element that says ""we're secure"".
If we one day reach near-100% coverage of the WP ecosystem with digital signing, we can discuss making it mandatory.
== Implementation Recommendations ==
Okay, this section is going to be technical so feel free to skip most of this if you're not into cryptography.
TL;DR - We need a libsodium polyfill, which Paragon Initiative Enterprises is willing to write for free if (and only if) the cost of an independent third party audit is covered by the community and/or the community's corporate sponsors.
=== Digital signatures ===
PHP, out of the box, only supports RSA signatures (via the OpenSSL extension), but doesn't support RSASSA-PSS+MGF1SHA256. PKCS1v1.5 padding is unacceptable.
It may be tempting to move towards something like ECDSA, but a mix of security concerns (the Sony ECDSA k-value reuse incident, invalid curve attacks against Weierstrass curves) makes us wary even of RFC 6979 (deterministic ECDSA).
We propose a standardized digital signature algorithm based on twisted Edwards curves. Namely, **Ed25519** or **Ed448** (EdDSA over the RFC 7748 curves).
=== Merkle Trees ===
The TrimmedMerkleTree in Halite is probably the best starting point: https://github.com/paragonie/halite/blob/master/src/Structure/TrimmedMerkleTree.php
Halite's Merkle tree implementations are based on the BLAKE2b hash function (a SHA3 finalist with great performance in software based on the ChaCha20 round function).
=== Checksums ===
One of the following algorithms should be used where ever a checksum is required:
* BLAKE2b
* SHA-512/256
* SHA-512/224
* SHA-384
At no point should MD5 or SHA1 be considered. SHA-256 and SHA-512 are vulnerable to length-extension attacks and are not recommended.
== Action Plan ==
First, if this plan is agreeable by WordPress's security team, we'll get to work on a libsodium polyfill that works as far back as PHP 5.2.4 (in the spirit of WordPress's backwards compatibility tradition).
Once that's finished, independently audited by cryptography experts, and released to the public, we'll work on getting the core cryptographically signed. This will require some additional tooling; the release managers will need to run a command to produce a valid signature of the update file before releasing it.
After core updates are signed and signatures are being verified, we'll build the decentralized verification layer.
Then, we can move forward with making everyone's plugins and extensions securely delivered.
---
Edit Jan 3, 2019: As noted in [comment:50 comment #50], adding the sodium_compat library has been split out to a separate ticket, #45806, as it can serve a wider purpose than protecting against infrastructure attacks. -- @peterwilsoncc" paragoninitiativeenterprises 104
Needs Patch 40330 Reconsider the usage of infinite scrolling across the admin Administration normal normal Future Release task (blessed) assigned 2017-04-01T14:24:24Z 2021-05-08T11:20:11Z "As accessibility team, we've often discussed and we're aware of some a11y issues in the WordPress admin but haven't formalized them in a Trac ticket yet. That's because they're general, broad, issues and they probably can't be solved soon, as they have a big impact on the way some relevant parts of the user interface are built. They would require some extensive discussion and research. Nevertheless, if we're not going to at least open a discussion, the solution is not going to happen 🙂 . During the last accessibility weekly meeting we've decided to open a series of tickets and use a special keyword to group them, something like `a11y-task`. This is the first ticket of the series.
Infinite scrolling (sometimes known as ""endless scrolling"") can be a serious accessibility barrier. It's used in the admin in a few places, for example:
- Media Grid
- Add Themes screens
- Customizer > Add menu items
- Editor > Insert/Edit link > Search
- any other places?
For a comprehensive view of all the potential issues, I'd refer to the list of resources below. I'd recommend everyone to have a look at those posts.
I'd say the issues can be grouped in three different categories: accessibility, usability, and performance. Just to mention some of the most relevant ones:
- a11y: it's impossible or very hard for keyboard users to reach content placed after an infinite scrolling region: think for example at the Media Grid, where tabbing through attachments loads more and more attachments (potentially hundreds or thousands of them) forcing users to keep tabbing indefinitely
- a11y: no audible feedback or instructions about how infinite scrolling works, the current and total number of items, or when new items get loaded
- usability: infinite scrolling often breaks the browser's history
- usability: there's no JS fallback
- performance: memory footprint can be huge, especially when loading hundreds of big images, see the Theme install screens
Resources mostly focused on accessibility:
http://adrianroselli.com/2014/05/so-you-think-you-built-good-infinite.html
http://simplyaccessible.com/article/infinite-scrolling/
http://www.webaxe.org/infinite-scrolling-and-accessibility/
http://www.ssbbartgroup.com/blog/infinite-scrolling-impact-on-assistive-technologies-series-1/
Resources mostly focused on usability:
https://webmasters.googleblog.com/2014/02/infinite-scroll-search-friendly.html
https://www.nngroup.com/articles/infinite-scrolling/
https://www.sitepoint.com/ux-infinite-scroll-good-bad-maybe/
http://www.webdesignerdepot.com/2015/11/how-infinite-scrolling-breaks-ux/
https://www.smashingmagazine.com/2016/03/pagination-infinite-scrolling-load-more-buttons/
https://www.smashingmagazine.com/2013/05/infinite-scrolling-lets-get-to-the-bottom-of-this/
Resources focused on memory footprint:
http://engineering.linkedin.com/linkedin-ipad-5-techniques-smooth-infinite-scrolling-html5
https://www.sencha.com/blog/the-making-of-fastbook-an-html5-love-story/
http://dannysu.com/2012/07/07/infinite-scroll-memory-optimization/
Maybe for the future: the ARIA role `feed`
https://www.w3.org/TR/wai-aria-1.1/#feed
(at the time of writing, ARIA 1.1 is still a Candidate Recommendation, and as far as I know, no assistive technologies support the role `feed`)
See also: http://www.ssbbartgroup.com/blog/differences-aria-1-0-1-1-additions-role/
See #19815, #28927, #28998.
" afercia 24
Needs Patch 40925 Review the usage of the change event on select elements joedolson* Administration normal normal Future Release task (blessed) accepted 2017-06-05T12:47:01Z 2023-09-22T16:09:18Z "See also #31634
The change event can be problematic when used on select elements because browsers fire the event in different ways across different platforms. In this ticket I'll try to clarify what this difference is, why it matters for keyboard users, and why some actions shouldn't be triggered when a select option gets selected.
On macOS, when using the keyboard to navigate content and a select element gets focused, using the arrow keys always opens the select ""drop-down"":
[[Image(https://cldup.com/rU6roN4wAO.png)]]
This behavior allows users to explore the content of the select, scroll through the options, and select an option pressing Enter or Spacebar. This way, the change event fires after an explicit user action.
Instead, on Windows using the arrow keys on a select doesn't automatically open the ""drop-down"". To clarify what happens, I've made a short video using the Archives and Categories widgets as an example: https://cloudup.com/iuFxQ7CkA7k
Historically, this behavior was typical of all browsers on Windows, except Firefox. However, a recent change made Firefox behave like all the other browsers. For more details, see https://bugzilla.mozilla.org/show_bug.cgi?id=1350700
Since the drop-down doesn't open (it does only when pressing Alt+Down arrow), it's hard to scroll the list of options without firing the event at each arrow keys press. Users would need to explore the content of the select before making a choice, and to do so they use the arrow keys. However, while exploring the select content, the action associated to the change event runs. In the case of these widgets, the action triggers a full page reload.
Actions that have a big impact like a full page reload or a complete change of context should only be triggered after an intentional choice of the user, i.e. when pressing a button close to the select. In other cases, when the action triggers minor changes, using the change event could be OK. The best option would probably be to evaluate the interaction on a case by case basis.
There are a few places in WordPress where the change event is used this way, not pretending to be a complete list, here's some of them:
Media views:
- Filter by type
- Filter by date
Customizer
- Menu > Menu locations
- Static front page > A static page" afercia 15
Needs Patch 23432 "Review usage of target=""_blank"" in the admin" sabernhardt* Administration 3.2 normal normal Future Release task (blessed) accepted 2013-02-09T15:26:25Z 2023-11-17T17:54:28Z "Some links in the Setting Pages (General, Discussion, Permalink) pages open in same window, which sometime can be awful. [[BR]]
While the users can press cmd/ctrl + click and click the link to open it in new tab but If the user does not open the link in new window, options (which are not saved) will be lost and one have to go through them again.[[BR]]
Also links in the Edit Profile page and all the links in the help tab open in new window except a few.(so it is possible that users may just click it thinking them to alike other links which open in new window)[[BR]]
So a consistency will be there and ux can be a little better." theadityajain 56
Needs Patch 26504 Semantic elements for non-link links joedolson* Administration 3.8 normal normal Future Release task (blessed) accepted 2013-12-09T14:29:18Z 2024-01-30T15:12:56Z "Using the [http://heydonworks.com/revenge_css_bookmarklet/ revenge.css bookmarklet] on the dashboard gives a very [http://d.pr/i/yVYh clear indication] that some of the links on there are semantically incorrect - they should be buttons, even if they should look like links.
The Actual Buttons Are Actual section of this [http://coding.smashingmagazine.com/2013/08/20/semantic-css-with-intelligent-selectors/ article] sums it up nicely why.
Unless the accessibility team have indicated otherwise, each of the 74+ occurrences (only counting PHP files, more in JS files) of links with `href=""#""` should probably be a `