Author Archives: John Blackbourn

John Blackbourn 9:14 am on April 9, 2025
Tags: , ,   

PHP 8 support clarification

tl;dr: Use of the “compatible with exceptions” label for PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher 8 support has been retired and has been retroactively removed from all versions. WordPress 6.3 and later is now documented as fully supporting PHP 8.0 and 8.1, and WordPress 6.6 and later is now documented as fully supporting PHP 8.2. Support for PHP 8.3 and 8.4 remains in betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. as of WordPress 6.7 and the upcoming 6.8.

WordPress has supported PHP 8 since version 5.6 back in 2020, but due to the acknowledgement that WordPress is rarely used in isolation (without any theme or plugins) this support has been labelled as “beta support”, and later as “compatible with exceptions” following the guidelines that were adopted as a result of the proposal for criteria for removing the “beta support” label from each PHP 8+ version.

In order to provide clarity and confidence to users and to encourage web hosts and users to continue updating to the latest versions of PHP, use of the “compatible with exceptions” label has now been retired. Documented support for any given version of PHP will now go straight from “beta support” to fully supported once the agreed criteria for removing that label have been met. The label has been removed retroactively from all versions.

PHP compatibility of all WordPress versions is documented here in the handbook and has been updated to reflect this change.

What prompted this change?

The criteria for removing the “beta support” label were adopted in 2023 just prior to the release of WordPress version 6.3. In that version a significant amount of work was done to resolve remaining PHP compatibility issues and to switch to using the “compatible with exceptions” label for PHP 8.0 and 8.1. The same was done in WordPress 6.6 for PHP 8.2, and the number and significance of these documented compatibility exceptions is now very low.

Since then it’s become apparent that some end users and web hosts remain reluctant to update to PHP 8 when the documented support in WordPress is still labelled as “compatible with exceptions”, despite the actual support being complete as far as most sites are concerned (over 60% of WordPress sites run PHP 8+). The label has served its purpose over the last 18 months but now risks being detrimental to the continued adoption of newer versions of PHP.

Removing this label — while still documenting the exceptions where necessary — will help continue the adoption of newer and fully supported versions of PHP and provide confidence to the remaining 40% of sites to update.

What are the criteria for removing the “beta support” label?

These criteria have not changed. The criteria are:

  • Enough sites: At least 10% of all WordPress sites running on a specific or newer PHP version for at least 3 months.
  • Issues:
    • All reported and known compatibility issues are resolved.
    • All accepted incompatibilities are documented as exceptions from full compatibility.
  • BC: Full backward compatibility is maintained for all older PHP versions WordPress supports, demonstrated with automated tests for each compatibility change.

Usage of PHP 8.3 and higher is at 8.9% of all WordPress sites as of April 2025. Once this surpasses 10% and assuming no further compatibility issues are reported then it’s expected that the beta label for PHP 8.3 support will be removed in the subsequent major releasemajor release A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope. of WordPress.

What’s the minimum supported version?

The minimum supported version of PHP remains unchanged at 7.2.24+.

Props to @desrosj @joemcgill @garyj for input on this change.

#php, #php-8-0, #php-compatibility

John Blackbourn 2:01 pm on February 17, 2025
Tags: , ,   

WordPress 6.8 will use bcrypt for password hashing

Note: This article has been updated with additional technical information about the structure of password hashes that may be relevant to developers of plugins that directly handle them.

The underlying algorithm that’s used to hash and store user passwords in the database will be changed in WordPress 6.8 from phpass portable hashing to bcrypt. The adoption of bcrypt hardens password security in WordPress by significantly increasing the computational cost of cracking a password hash.

In addition, application passwords, user password reset keys, personal data request keys, and the recovery mode key will switch from using phpass to the cryptographically secure but fast BLAKE2b hashing algorithm via Sodium.

No action needs to be taken by site owners or users as a result of these changes. Passwords and security keys that were saved in prior versions of WordPress will continue to work after updating to 6.8. Users don’t need to change or reset their passwords, logged in users will remain logged in, and their sessions will remain valid.

When a user first subsequently logs in after the update – or when they next change their password – their password will automatically get rehashed with bcrypt and resaved in the database. Application passwords and security keys will not get automatically rehashed, but an existing hash will remain valid if it was generated prior to WordPress 6.8 and used before it expires.

Note that post passwords will continue to use phpass portable hashing for now. This may change in the future after further investigation has been done on how best to improve the hashing and checking mechanism of post passwords.

Portability

Hashes that are generated by the phpass portable hashing algorithm are portable between different sites, environments, and servers. This portability doesn’t change with this switch to bcrypt and BLAKE2b, so you can move your database from one server to another and update to newer versions of PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher and WordPress and the password hashes will continue to function as expected.

Updates to password handling functions

The wp_hash_password() and wp_check_password() functions have been updated to use the PHP native password_hash() and password_verify() functions with the bcrypt algorithm and SHA-384 pre-hashing. Both functions retain support for the $wp_hasher global object in case that’s being used to implement an alternative hashing mechanism.

The wp_check_password() function retains support for passwords that were hashed using phpass, which means existing password hashes won’t be invalidated.

A new wp_password_needs_rehash() function has been introduced as a wrapper for password_needs_rehash(). If a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party needs to adjust its logic then the password_needs_rehash filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. can be used. The function is also pluggable, so it can be overridden if absolutely necessary.

Pre-hashing with SHA-384 is implemented in order to avoid the 72 byte length limit imposed on passwords by bcrypt. Password hashes are therefore stored with a $wp prefix to distinguish them from vanilla bcrypt hashes which may be in use via a plugin. By default this means the full prefix will be $wp$2y$.

New fast hashing functions

The following functions have been introduced as wrappers for the cryptographically secure but fast BLAKE2b algorithm via Sodium:

  • wp_fast_hash()
    Used to hash a string that is randomly generated using sufficiently high entropy, preferably over 128 bits for values that don’t have a corresponding expiry mechanism.
  • wp_verify_fast_hash()
    Used to verify a hash generated via wp_fast_hash(), with fallback support for phpass portable hashes.

Do developers need to do anything?

Code that calls wp_hash_password() and wp_check_password() will continue to work as expected and does not need to change.

Code that directly handles phpass hashes may need to be updated, for example:

  • Code that assumes the existence of the $P$ prefix on hashes. The code will need to be updated so it either doesn’t need to inspect the prefix of the hash at all, or updated to handle both the new prefixes and hashing algorithms and legacy hashes:
    • The $wp$2y$ prefix will be the new default for user passwords in WordPress and represents a SHA-384 pre-hashed bcrypt hash.
    • The plain $2y$ prefix may be used by existing plugins that use bcrypt hashes without pre-hashing.
    • The $generic$ prefix for a BLAKE2b hash used for application passwords and security keys.
    • A hash starting with $argon2 if a site opts in to using an Argon2 algorithm (see below). Note that any non-bcrypt algorithm won’t use pre-hashing and therefore won’t include $wp at the start of the prefix.
    • The old $P$ prefix for a phpass portable hash which will remain in wide use.
    • A legacy plain MD5 hash, which is a 32 character hexadecimal string.
  • Code that otherwise directly interacts with the hashed value of a user password. If such hashes are validated directly, this should be done via wp_check_password().
  • Code that otherwise directly interacts with the hashed value of an application password, password reset key, personal data request key, or the recovery mode key. If such hashes are validated directly, this should be done via the new wp_verify_fast_hash() function.
  • Any plugin that overwrites the pluggable wp_hash_password() and wp_check_password() functions. Unless these functions specifically implement another hashing algorithm, they can be removed in order to allow the bcrypt implementation in 6.8 to take effect.

Alternative authentication mechanisms such as single sign-on (SSO), social login, or one-time login are unlikely to be affected by this change, however you should still verify whether your specific implementation includes any handling of password hashes or security keys. Multi-factor (MFA and 2FA) implementations are also unlikely to be affected by this change.

What about Argon2?

Servers that support Argon2 can enable its usage with this single line of code in WordPress 6.8 and later:

add_filter( 'wp_hash_password_algorithm', fn() => PASSWORD_ARGON2ID );

If necessary, the password_algos() function should be used to first check for argon2id support. Unfortunately it’s not possible to rely on Argon2 being available on all servers because it requires both libargon2 to be available on the server and for PHP to be built with Argon2 support enabled. The sodium_compat library does not provide an implementation of Argon2.

Acknowledgements

We can’t pretend that switching to bcrypt for user-generated passwords is a recent proposal. Ideally the switch would have been made back when the increase to the minimum supported version of PHP facilitated this change. However, this change has now been made and it helps future-proof further improvements to password hashing, including increases to the bcrypt cost in newer versions of PHP.

Many thanks go to the Roots team for maintaining their bcrypt password hashing package for WordPress as well as the many contributors on the TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets and GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ pull requests.

Further technical information

Further technical information, technical FAQs, and implementation details can be seen on the GitHub pull request for this change and in the discussion on the Trac ticket.

In case you need to know:

  • User passwords are stored as a hash in the wp_users.user_pass field in the database.
  • Application passwords are stored as a hash in a JSONJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. serialized object in the wp_usermeta table using the _application_passwords key.
  • User password reset keys are stored as a hash in the wp_users.user_activation_key field in the database.
  • Personal data request keys are stored as a hash in the wp_posts.post_password field in the database against the post that represents the personal data request.
  • The recovery mode key is stored as a hash in the recovery_keys option in the wp_options database table.

Thanks to @desrosj and @joehoyle for helping review this post.

#6-8, #dev-notes, #dev-notes-6-8

John Blackbourn 9:24 pm on April 8, 2024
Tags: , ,   

Dropping support for PHP 7.0 and 7.1

Support for PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher 7.0 and 7.1 will be dropped in WordPress 6.6, scheduled for release in July 2024. The new minimum supported version of PHP will be 7.2.24. The recommended version of PHP remains at 7.4 or greater.

WordPress currently supports PHP version 7.0 or greater. The minimum supported version was last adjusted in WordPress 6.3 in August 2023, and since then usage of PHP 7.0 and 7.1 has dropped to a combined 2.45% of monitored WordPress installations as of April 2024.

There’s no concrete usage percentage that a PHP version must fall below before support in WordPress is dropped, but historically the project maintainers have used 5% as the baseline. Now that usage of PHP 7.0 and 7.1 combined is well below that at 2.45%, the process to increase the minimum supported PHP version in this release can move forward.

The benefits to increasing the minimum supported PHP version manifest over time and in multiple places, including within the pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party and theme ecosystem, within the long term perception of the WordPress project, within developer relations, and over time within the WordPress codebase and its developer tooling.

Discussion around this minimum version bump can be found here on the Trac ticket.

What about PHP 8?

WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. is compatible with PHP 8.0 and 8.1 with exceptions. Support for PHP 8.2 and PHP 8.3 is considered betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. since WordPress 6.4. Please see the PHP Compatibility and WordPress Versions page in the handbook for full information.

What about security support?

Sites that are running PHP 7.0 or 7.1 will remain on the 6.5 branchbranch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch". of WordPress which will continue receiving security updates as it does currently. The current security policy is to support WordPress versions 4.1 and greater.

What about the GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ plugin?

The Gutenberg plugin, which is used for development of the blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor, has a separate release schedule from WordPress core and officially supports the two most recent releases of WordPress. The Gutenberg development team will likely also increase the minimum supported version of PHP to 7.2 in time for WordPress 6.6. See this issue on the Gutenberg repo for when this was last changed in WordPress 6.3.

Going forward

There are no plans to bump the minimum supported PHP version on a schedule. The core team will continue to monitor usage of PHP versions and work with the hosting team to encourage users and hosting companies to upgrade their versions of PHP as swiftly as possible. The 5% usage baseline will continue to be used for the foreseeable future.

The PHP usage stats as of April 2024 look like this:

  • 8.3: 1.20%
  • 8.2: 12.07%
  • 8.1: 16.34%
  • 8.0: 12.25%
  • 7.4: 42.80%
  • 7.3: 4.79%
  • 7.2: 3.80%
  • 7.1: 0.95%
  • 7.0: 1.50%

Update PHP today

If you need more information about PHP or how to update it, check out this support article that explains more and guides you through the process.

Props to all those that have contributed to this discussion recently. Thanks to @chanthaboune for feedback and proof-reading this post.

#6-6, #dev-notes, #php

John Blackbourn 5:45 pm on July 5, 2023
Tags:   

Dropping support for PHP 5

Support for PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher 5 will be dropped in WordPress 6.3, scheduled for release on August 8th 2023. The new minimum supported version of PHP will be 7.0.0. The recommended version of PHP remains at 7.4 or greater.

WordPress currently supports PHP version 5.6.20 or greater. The minimum supported version was last adjusted in WordPress 5.2 in 2019, and since then usage of PHP 5.6 has dropped to 3.9% of monitored WordPress installations as of July 2023.

There’s no concrete usage percentage that a PHP version must fall below before support in WordPress is dropped, but historically the project maintainers have used 5% as the baseline. Now that usage of PHP 5.6 is well below that at 3.9% and dropping by around 0.1% every few weeks, plans to increase the minimum supported PHP version can move forward.

The benefits to increasing the minimum supported PHP version manifest over time and in multiple places, including within the pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party and theme ecosystem, within the long term perception of the WordPress project, within developer relations, and over time within the WordPress codebase and its developer tooling.

Discussion around this minimum version bump can be found here on the Trac ticket.

What about PHP 8?

Support for PHP 8.0, 8.1, and 8.2 in WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. is very good, and a proposal for the criteria for removing the “beta” support label for each new PHP version has been published.

What about security support?

Sites that are running PHP 5.6 will remain on the 6.2 branchbranch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch". of WordPress which will continue receiving security updates as it does currently. The current security policy is to support WordPress versions 4.1 and greater.

What about the GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ plugin?

The Gutenberg plugin, which is used for development of the blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor, has a separate release schedule from WordPress core and officially supports the two most recent releases of WordPress. This means that the Gutenberg plugin will continue to support PHP 5.6 for the time being, most likely until WordPress 6.4 is released. See this issue on the Gutenberg repo for further information.

Going forward

There are no plans to bump the minimum supported PHP version on a schedule. The core team will continue to monitor usage of PHP versions and work with the hosting team to encourage users and hosting companies to upgrade their versions of PHP as swiftly as possible. The 5% usage baseline will continue to be used for the foreseeable future.

The PHP usage stats as of July 2023 look like this:

  • 8.2: 2.11%
  • 8.1: 9.37%
  • 8.0: 14.05%
  • 7.4: 51.13%
  • 7.3: 7.92%
  • 7.2: 6.29%
  • 7.1: 1.38%
  • 7.0: 2.05%
  • 5.6: 3.93%

Update PHP today

If you need more information about PHP or how to update it, check out this support article that explains more and guides you through the process.

Props to all those that have contributed to this discussion recently. Thanks to those who provided feedback and proof-reading of this post: @azaozz @chanthaboune @flixos90 @hellofromtonya @javiercasares @joemcgill @jorbin @jrf @peterwilsoncc @sergeybiryukov

#php

John Blackbourn 6:16 pm on November 28, 2017
Tags:   

WordPress 4.9.1 beta

As mentioned earlier today, WordPress 4.9.1 has been scheduled for release tomorrow, November 29th, 20:00 UTC. Please have a read of that post for details of the fixes.

The beta package for 4.9.1 is now ready for testing. Please help us by testing this betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. to ensure 4.9.1 fixes the reported issues and doesn’t introduce any new ones.

#4-9-1

John Blackbourn 3:53 pm on November 28, 2017
Tags:   

WordPress 4.9.1 scheduled for November 29th

WordPress 4.9 has been downloaded over 6 million times since its release two weeks ago.

A small number of bugs have been identified which are impactful enough that the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. team has decided to release 4.9.1 with fixes for those issues. The release is scheduled for tomorrow, November 29th, 20:00 UTC. A betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. release will be packaged later today and made available for testing.

The issues that have been fixed are:

  • #42573: File caching affecting users’ ability to use the pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party and theme file editors.
  • #42574: MediaElement upgrade causing JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. errors when certain languages are in use.
  • #42579: Incorrect logic in extract_from_markers().
  • #42454: Unable to translate Codex URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org in theme editor.
  • #42609: Theme editor cannot edit files when running on a Windows server.
  • #42628: flatten_dirlist() doesn’t play nice with folders with numeric names.
  • #42634: DB_HOST socket paths with colons not parsed correctly.
  • #42641: On multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site upgrade the wp_blog_versions table doesn’t get updated
  • #42673: Themes page throws console error when there is only one installed theme.

In addition, one fix for a bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. introduced in WordPress 4.7 will be included in 4.9.1:

  • #42242: lang attribute in the adminadmin (and super admin) area doesn’t reflect a user’s language setting.

Stay tuned for the announcement of a beta package.

#4-9-1

John Blackbourn 7:50 pm on October 13, 2017
Tags: ,   

Account Security Improvements in WordPress 4.9

A few account security enhancements have gone into WordPress 4.9. The intention is to make it more difficult for an attacker to take over a user account or a site by changing the email address associated with the user or the site, and also to reduce the chance of a mistaken or erroneous change causing you to get locked out.

  • In order to change your user account email address, the site adminadmin (and super admin) email address, or the networknetwork (versus site, blog) admin email address on Multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site, a link now needs to be clicked in a confirmation email that gets sent to the new email address. This behaviour has existed for years on sites within a Multisite network — the functionality has now been ported to single site installations too. See #16470, #39118, and #39119.
  • The old site admin email address now gets notified of a change to the address (this includes the network admin email address on Multisite too). See #39117.
  • The email that’s sent to a user’s old email address when their email address is changed now includes the new email address. See #39112.

#4-9, #dev-notes

John Blackbourn 7:45 pm on May 25, 2017  

HHVM no longer part of WordPress core’s testing infrastructure

WordPress has never officially supported HHVM, but since WordPress 4.0 it has been compatible, largely thanks to the efforts of @wonderboymusic in #27881 and other tickets.

Many large scale sites which switched to HHVM around 2014 have since switched to PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher 7, and usage numbers of HHVM according to the wordpress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ update statistics indicate that HHVM powers only several dozen WordPress websites as of April 2017.

CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.’s unit testunit test Code written to test a small piece of code or functionality within a larger application. Everything from themes to WordPress core have a series of unit tests. Also see regression. suite when run on HHVM never actually passed (this may not be completely accurate, memories are hazy), often errored completely, and was always marked as an allowed failure. All of this, coupled with the disproportionately high amount of effort required to maintain the test and CI infrastructure for HHVM, means that WordPress core is no longer tested on HHVM as part of the Travis CI build. See #40548 for details.

If you’re running a WordPress website on HHVM, you should consider switching to PHP 7+ which is far more widely supported and tested, and offers all of the memory and performance benefits that HHVM pushed forward.

John Blackbourn 11:16 pm on April 23, 2017
Tags:   

Recent updates to the unit testing infrastructure

Several changes have made their way into WordPress’ unit testunit test Code written to test a small piece of code or functionality within a larger application. Everything from themes to WordPress core have a series of unit tests. Also see regression. suite and its infrastructure recently. If you maintain a WordPress project (such as a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party or website) that has its own test coverage, you may be interested in porting some of these changes to your test suite too. Here’s a round-up:

  • Tests which require Multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site to be enabled, or tests which should be excluded from running when Multisite is enabled, can now be placed into the new ms-required and ms-excluded groups to skip them automatically when the test requires Multisite to be in use, or when it requires Multisite to not be in use, respectively. In addition, the default configuration in phpunit.xml now excludes such test groups as appropriate without them being marked as skipped, which removes unwanted noise from PHPUnit’s reporting when run in verbose mode. See #40531.

Please note that this usage example has been updated from a previous version of this post.

Example usage:

/**
 * @group ms-required
 */
function test_something_on_multisite() {
	// Run your Multisite-only assertions here
}

/**
 * @group ms-excluded
 */
function test_something_without_multisite() {
	// Run your single-site-only assertions here
}
  • XDebug is now disabled when running tests on Travis in order to speed up the builds. This resulted in a huge reduction in build times, up to 40% in some cases. See #39978.
  • The PHPUnit version used when running tests on Travis is now explicitly coupled to the PHP version in order to avoid incompatibilities such as the one caused when PHPUnit 6 was rolled out. See [40269] for the main change and #40100 and #40086 for more info.
  • A compatibility shim for PHPUnit 6+ has been added, which means the test suite will no longer cause fatal errors if you want to update to PHPUnit 6+ locally or, for example, you want to require it through a Composer dependency. See #39822.
  • Several tests which were previously skipped when the environment wasn’t suitable will now cause failures, for example tests which depend on constants such as DISALLOW_FILE_MODS not being set. This is to avoid hiding tests that never run and therefore never fail if the assertions contained within them would otherwise fail. If the core test suite begins failing on your local environment as a result, you should address the cause. See #40533.
  • The number of PHP versions which older branches are tested against on Travis has been significantly reduced in order to speed up build times for patch releases. This is most beneficial when security fixes are released and backported. As a general rule, branch builds except the latest branch are now only tested on the oldest supported version (5.2), the latest in the 5.x branch, and the latest in the 7.x branch. See #40407.

#dev-notes

John Blackbourn 10:54 am on October 28, 2016
Tags: ,   

Fine grained capabilities for taxonomy terms in 4.7

WordPress 4.7 introduces new capabilities for individual taxonomyTaxonomy A taxonomy is a way to group things together. In WordPress, some common taxonomies are category, link, tag, or post format. https://codex.wordpress.org/Taxonomies#Default_Taxonomies. terms, allowing developers to implement more fine grained control over management of terms (including categories, tags, and custom taxonomy terms). The new capabilities are metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. capabilities that ultimately map back to existing capabilities, so there is no change in behaviour for existing functionality and users.

New Singular Capabilities

  • edit_term
  • delete_term
  • assign_term
In the same way that capabilities such as edit_post and delete_user are used to check that a user can perform the action for a specific post or user, these new capabilities can be used to check that a user can perform the action for a specific term. If you’re currently checking the edit_terms, delete_terms, and assign_terms capabilities, you can switch these over to the singular form and include the term ID as the second parameter. Example: 
if ( current_user_can( 'edit_term', $term_id ) ) {
	printf( '<a href="%s">Edit This</a>', get_edit_term_link( $term_id ) );
}
The new capabilities are meta capabilities — which means they ultimately map back to the existing manage_categories capability by default, or whichever capability has been specified in the corresponding capability arguments when registering the taxonomy. The actual required capabilities can be filtered using the map_meta_cap filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. like so: 
add_filter( 'map_meta_cap', function( $required_caps, $cap, $user_id, $args ) {
	switch ( $cap ) {

		case 'delete_term':
			$term_id = $args[0];
			// Prevent a "protected" term from being deleted:
			if ( get_term_meta( $term_id, 'protected', true ) ) {
				$required_caps[] = 'do_not_allow';
			}
			break;

		case 'edit_term':
			// Introduce some anarchy:
			if ( rand( 1, 6 ) == 3 ) {
				$required_caps[] = 'do_not_allow';
			}
			break;

	}

	return $required_caps;
}, 10, 4 );

Separate Capabilities for Tags and Categories

A related change is that the post tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) taxonomy now uses separate capabilities from the categoryCategory The 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging. taxonomy by default (it previously used the same capabilities as the category taxonomy). This doesn’t alter existing behaviour (custom or otherwise), but it does mean that you can target capabilities for tags separately from categories. Example: 
add_filter( 'map_meta_cap', function( $required_caps, $cap, $user_id, $args ) {
	switch ( $cap ) {

		case 'manage_post_tags':
		case 'edit_post_tags':
		case 'delete_post_tags':
		case 'assign_post_tags':
			// Allow Authors to manage tags:
			$required_caps = array(
				'publish_posts',
			);
			break;

	}

	return $required_caps;
}, 10, 4 );
See TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticketticket Created for both bug reports and feature development on the bug tracker. #35614 for more information.

#4-7, #dev-notes