CSS Chat Agenda: September 30, 2021

The next weekly CSSCSS Cascading Style Sheets. meeting is today Thursday, September 30 at 21:00 UTC in the #core-css channel in Making WordPress SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/..

Meeting Agenda

  • Announcements & Housekeeping
  • CSS Custom Properties (#49930)
  • Open Floor / CSS Link Share

See you there!

#agenda

X-post: 30 days of translation celebration!

X-comment from +make.wordpress.org/polyglots: Comment on 30 days of translation celebration!

Editor Chat Summary: 29th September 2021

This post summarises the weekly editor chat meeting (agenda here) held on 2021-09-29 14:00 UTC in Slack. Moderated by @get_dave.

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/ 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 releases

WordPress 5.9 “Go, no go” date and priorities

  • The “go, no go” review date for WordPress 5.9 is coming up on October 12, 2021.
  • Gutenberg 11.6.0 was the final full release of the Gutenberg Plugin prior to that date (although we’ll have an RC for 11.7.0 on the 6th October which can be used for the “go/no go”).
  • The main goal for 5.9 is getting full site editing to all WordPress users.
  • The key “candidate” features are listed in the suggested roadmap.

Updates based on the scope for Site Editing projects

Updates were requested for the key projects:

Global Styles

@youknowriad provided an async update on the agenda:

  • We’re making some good practice hoping to be in a good shape for 5.9.
  • We’ve been iterating on the designs proposed in this overview issue.
  • We’ve landed the drill down Navigation in the sidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. and we are iterating on the different panels and components. (you can follow the updates on the issue)

Also related to this, @mciampini provided an update from the folks working on the components package:

Shipping:

In Progress:

  • We’re now moving to use the NavigatorProvider components in other contexts in Gutenberg, including the preferences modal.
  • This will help us to validate the APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. of the component and reduce overlap with the existing Navigation components that specifically render the “W” sidebar in the full site editor.

Template Editor

No one was available to provide an update. I asked around and @kevin940726 let me know of progress on the Template Part Focus Mode:

  • Merged #34679 to add the “Edit template part” button in ellipsis menu.
  • Merged #34732 to add the back button in the focus mode (isolated template part mode)
  • Rob is working on #35170 to show the ellipsis menu in the list view
  • I just merged #35202 and opened #35239 to add template areas to top bar and the inspector

Patterns

No one was around at the time of the meeting, but having asked around, @ntsekouras provided an update for us:

Navigation Editor

@get_dave provided the update:

  • Discussion is ongoing on the best way to ensure interoperability and compatibility between Nav 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. and Nav Editor.
  • Proposal to utilise a new classic Menu block in the Nav Editor continues. Any feedback welcomed.
  • Folks (particularly @spacedmonkey / @Jonny Harris) have been working hard on backwards compatibility. Any more feedback on this Issue would be a great help.
  • Lots of 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. fixes continue to roll in for the Editor. Great work by everyone involved.

Would particular like to highlight the need to provide feedback on the ongoing discussion regarding the proposal to utilise a dedicated classic Menu block in the Editor.

Navigation Block

@joen provided the update:

  • Working on navigation things around improving the setup state for url-less menu items (ultimately to help enable nav block patterns).
  • Continuing with light navigation related things such as URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org dialog improvements for the basic mode of the menu, and mockups for transforms to switch to advanced building.

Block based Widgets Editor

No one was around to provide an update but one improvement I’m aware of is that you can now edit the title of the Widget Group block directly.

Seems like a small change but it really helps improve the flow of a block which is critical for solid backwards compatibility.

Native Mobile Team

@antonisme provided the update:

Shipped

  • Embed block improvements and fixes
  • Use tarball instead of git 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.) for reactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/.-native-editor forked dependencies
  • Added native version of Dashicon component for mobile

Fixes:

In Progress:

  • Launching soon a way to contact support from inside editor
  • Additional Embed block improvements
  • GSS Font size, line height, colors

Task Coordination

The following items were shared by folks to update us on what work is in progress or where help is needed:

@shaunandrews:

  • I’m working up a some designs around block controls (like height, width, border, background, etc) and their groupings (dimensions? shape? layout?).
  • Check out the #design channel for some more info. I hope to write up some thoughts this week.

@mamaduka:

  • Helping with PR reviews/testing.
  • Worked on a few small PRs of my own.
  • I’ve PR that should fix editor crash when dragging multiple blocks into innerBlocks. I’m not very familiar with this part of the code, and I would appreciate extra eyes on it.
  • Also started working on useSelect call optimizations because of missing dependencies across the codebase.

@annezazu:

  • Still working through feedback on the current exploration on block theme switching.
  • Shipped a YouTube video about the Query Loop block.
  • Kicked off a post that I hope turns into a wider conversation about an approach for adopting FSE features.
  • Helped with the latest / News post.
  • Cleared unlabelled issues backlog.
  • Working on the next call for testing for the outreach program.
  • Midway through a coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. editor improvement post on accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) improvements.

@welcher:

@get_dave:

@mciampini:

  • I will continue refining the Navigator* components and the ItemGroup and Item components.
  • Helping with PR reviews around the @wordpress/components package.
  • Helping Riad with the updated Global Styles sidebar.

Open Floor

Adding locking capabilities to Reusable Blocks

  • @paaljoachim explained that at the moment it is too easy to make an accidental change to a Reusable block.
  • We soon should get a lock mechanism in place as per the overview Issue on locking.
  • @johnstonphilip queries whether locking is enough to ensure that the user understands the action they are taking is destructive across other pages.
  • @get_dave noted that the Update/Publish flow now separates out changes to the current Post vs Reusable Blocks (similar to how the Site Editor handles saving template parts).
  • @get_dave recommend raising an Issue to suggest having a more explicit warning inline on the Reusable Block to flag that you are making changes to a global entity.

Getting useInnerBlockProps and LinkControl out of “experimental” status

  • @fabiankaegy brought up two tickets related to features that are currently marked as __experimental which he thinks are at the point where they can be moved out of the experimental state.
  • @get_dave responded re: <LinkControl> to say:
    • There are still a number of items I’d like to see ticked off the tracking issue prior to merging (help with these appreciated).
    • It is quite powerful, but we should look at reducing the complexity of the component itself before committing to it.
    • Due to look at the architecture soon to see what improvements can be made – @youknowriad has mentioned this in the past.
  • @get_dave noted that @ellatrix has a PR to stablise useInnerBlocksProps and that more reviews and input are needed to get this to land.
  • It was agreed that given how long the components have been around that we should look to standardise both.

Wrap up

Thanks to everyone who attended the meeting!

#core-editor, #core-editor-summary, #meeting-notes, #summary

Dev chat summary – September 29, 2021

@audrasjb led the chat on this agenda. You can also read the Slack logs.

Highlighted blogblog (versus network, site) posts

Bringing to your attention some interesting reads and some call for feedback and/or volunteers:

Worth mentioning:

Thanks to the 23 contributors of the past week, including 4 new contributors! Kudos to the 5 coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. committers of the week, too.

A Week in Core – September 27, 2021

Upcoming releases updates

Next minor releaseMinor Release A set of releases or versions having the same minor version number may be collectively referred to as .x , for example version 5.2.x to refer to versions 5.2, 5.2.1, 5.2.3, and all other versions in the 5.2 (five dot two) branch of that software. Minor Releases often make improvements to existing features and functionality.(s)

@desrosj and @circlecube are still leading the 5.8.x releases. They published a schedule for 5.8.2 and –if needed– 5.8.3.

The 5.8.x point releases are coordinated in the #5-8-release-leads SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel. This channel is public and will be archived once 5.9 is released.

@costdev pointed out that a patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. for ticketticket Created for both bug reports and feature development on the bug tracker. #53801 leads to a change in both Core and in the @wordpress/widgets package and asked for advices for how to ensure that any changes are committed at the same time to minimise issues on either end. @audrasjb answered that there is already an issue for this ticket in the 5.8.2 Gutenberg project board.

Next 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.

Concerning the next major release —WordPress 5.9— a planning roundup was published a couple weeks ago.

Worth noting that @chanthaboune proposed a review of the upcoming 5.9 key features in the last issue of the WordPress.org podcast.

@audrasjb ran a first 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. scrub last week to review the tickets marked early. He will run another one on Thursday September 30, 2019 at 20:00 UTC.

Reminder: everyone is welcome to run a bug scrub on the #core Slack channel. If you are interested, please read this handbook post: Leading bug scrubs and get in touch with @audrasjb or @francina for details.

Also, @audrasjb silently scrubbed the Future Release queue and moved a dozen of tickets (in various components) to 5.9, with refreshed patches when needed. Most of them are ready and waiting for review/commit.

Component maintainers updates

Build/Test Tools – @sergeybiryukov

PHPUnit 9.5.10 and 8.5.21 were released with a breaking change: PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher deprecations are no longer converted to exceptions by default (convertDeprecationsToExceptions="true" can be configured to enable this). See changeset [51871] and ticket #54183 for more details.

This is also included in the Changes to the WordPress Core PHP Test Suite dev notedev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include: a description of the change; the decision that led to this change a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase., which is highly recommended to read as it includes other important changes for 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 authors using the WordPress Core test framework as a basis for their integration tests.

Upgrade/Install – @afragen

@afragen shared that there is currently a lot of activity on a 9 years old ticket: #22316. He added a new PR which is ready for review.

@audrasjb added that the design of the feature was discussed during the last #core-auto-updates weekly meeting.

@joyously asked if it is supposed to handle initial installation or deactivation and uninstall also? @audrasjb answered that it only handles initial installation, because a dependency could exists without the “base” plugin.

@joyously asked what value does this enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. add to the existing implementation. @clorith answered that It surfaces which plugins would enhance (or enable) functionality, so yes it has value. @audrasjb added that it standardizes a process which currently has many different implementations.

@afragen encouraged testers to install the PR, add a test plugin with a couple of dot org plugin slugs in a comma separated list in the Required Plugins headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes.. Removing or changing the header name will deactivate those dependencies from being displayed.

Toolbar – @sabernhardt

@sabernhardt shared a draft of a Toolbar component update post.

He also pointed out that a docs update (#54191) was just committed today.

Open Floor

From @marybaum and @annezazu: there is a new testing call in the Full Site Editing Outreach Program.

@costdev noted that the Administration component doesn’t have a maintainer currently listed. He asked for a review of #53152. @sergeybiryukov moved it to milestone 5.9.

@pbearne asked for a review of #54020. He’s available to make a simpler patch if needed.

@webcommsat shared that tomorrow (30 September) is the last day of #WPTranslationDay 2021. Everyone is welcome to come and join the polyglots teamPolyglots Team Polyglots Team is a group of multilingual translators who work on translating plugins, themes, documentation, and front-facing marketing copy. https://make.wordpress.org/polyglots/teams/. for the final event and the celebrations from 16:00 UTC.

#5-8-x, #5-9, #dev-chat, #summary

Dev Chat Agenda for Sept 29, 2021

Here is the agenda for this week’s developer meeting to occur at September 29, 2021, at 20:00 UTC.

Blogblog (versus network, site) Post Highlights and announcements

Bringing to your attention some interesting reads and some call for feedback and/or volunteers:

Next releases status update

  • Next minor releaseMinor Release A set of releases or versions having the same minor version number may be collectively referred to as .x , for example version 5.2.x to refer to versions 5.2, 5.2.1, 5.2.3, and all other versions in the 5.2 (five dot two) branch of that software. Minor Releases often make improvements to existing features and functionality.: WP 5.8.2
    👉 WordPress 5.8.2+ Release Schedule
  • Next 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.: WP 5.9
    👉 WordPress 5.9 Planning Roundup

Components check-in and status updates

  • Check-in with each component for status updates.
  • Poll for components that need assistance.

Open Floor

Do you have something to propose for the agenda, or a specific item relevant to the usual agenda items above?

Please leave a comment, and say whether or not you’ll be in the chat, so the group can either give you the floor or bring up your topic for you accordingly.

This meeting happens in the #core channel. To join the meeting, you’ll need an account on the Making WordPress Slack.

#5-8-2, #5-9, #agenda, #core, #dev-chat

Editor chat summary: Wednesday, 22 September 2021

This post summarizes the weekly editor chat meeting on Wednesday, 22 September 2021, 14:00 UTC held in Slack.

What’s next in 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/? (Mid-September 2021)

@jorgefilipecosta said the post with the goals for the Gutenberg project in September is published and referred that the priorities are the template Editor, Patterns, Global Styles theme.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., the design tools., and the Navigation 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./navigation editor work.

As a follow-up @ntsekouras brought attention to an experiment to trigger some discussions – a Patterns explorer, asking people to share their thoughts.

Project Updates

Mobile Application

Shipped

  • Improve error handling for embed block
  • Improve Reusable Blocks inserter UIUI User interface

Fixes

  • Fix image block height and border regressionregression A software bug that breaks or degrades something that previously worked. Regressions are often treated as critical bugs or blockers. Recent regressions may be given higher priorities. A "3.6 regression" would be a bug in 3.6 that worked as intended in 3.5.
  • Fix back icon color in dark mode

In Progress

  • Additional Embed block improvements
  • GSS Font size, line height, colors

Components package

Shipping

  • Completed a migrationMigration Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. away from the createComponent function. This simplifies the process of adding new components to the library, using the more straightforward View component.
  • Following up on the recently expanded contributor guidelines, we simplified the structure of the guidelines and added a table of contents.

In Progress

  • @youknowriad merged a PR that introduces a navigation component to the Global Styles sidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme., which moves us closer to the updated designs. We’re experimenting now with a revised Navigator component that may provide greater flexibility for the design.

Navigation Editor

Lots of work happening on priority items. Thanks to everyone who is contributing so much work.

REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/. interactions have been improved and more issues identified.
• Started looking at ways to add links in Bulk.
• Using Theme JSON to control the block in the editor has been ruled out.
• Another Hallway Hangout is on the cards – dates/times to be confirmed.

Task Coordination

@annezazu

Hallway hangout for adoption pathways for FSE with Marcus & Dave, continue amplifying the current block theme switching exploration (please check it out!), did some light triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors., and shared a coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. editor improvement post on the new Widgets Group block!

@ntsekouras

  • Query Pagination with `flex` layout(#34876, #34897).
  • Pass the search value to inserter, when clicking Browse All(#34912).
  • Delayed loading state of SSR component(#35033).
  • Pattern Explorer experiment(#35006).

@jorgefilipecosta

For the next week, the plan is to continue iterating on the design and address the remaining follow-ups we have thinks like changing the border of the input field from a gray to slightly different gray changing the dimension of inputs from 30px to 40px, changing the focus look on the range control.

@mciampini

Will keep supporting @jorgefilipecosta and other folks working on the @wordpress/components package, including most of the work that is being done on the new Global Styles sidebar.

Open floor

Responsiveness

Roman Axelrod asked the following:

It was mentioned earlier, but… At time moment, core editor doesn’t provide options of setting different styling rules for each device / breakpoint (Preview modes: Desktop, Tablet, Mobile).

Right now, the rules are global. For example if I set padding: 60px to Group block from the right sidebar of the editor, this rule is going to appear on Desktop and Mobile.I curious if we are going to have the same functionality that all popular page builders have? Usually they provide a list of breakpoints and ability to “overwrite” styling rules of previous breakpoint. It gives ability of adapting the design by requirements.Is this something that we can expect soon? Are we going to have something like this in 2021?

@jorgefilipecosta said he thinks that is not something on the roadmap for 5.9, but allowing to control how things look depending on the dimensions of the place where they are rendered is something that will end up existing.

Custom Fields

Roman Axelrod asked the following:

Are there any plans or ideas of using Custom Fields in core blocks?
For example, imagine the situation where I have 20 pages. All pages have a “Hero” section that contains titletextbutton on the left and image on the right.
The design is the same but the content is different and unique for each page (kind of a template).Now let’s say, after I built these 20 pages, we realized that the Heading block should be 5px bigger.
How should I fix that? It might be annoying to go page by page and update the font-size of each heading.As a reference, Elementor page builder provides this kind of option – they call it “Dynamic Content”.
I thought that the block-template-parts of FSE will solve this case. But this is still not there. Are there any thoughts/discussions about similar cases?

@jorgefilipecosta answered the following:

Hi Roman, maybe the solution to your issue is to define a CSSCSS Cascading Style Sheets. variable that represents the size. Theme.json provides a mechanism for declaring the css variables, and then instead of using 5px as value you use the css variable as the value. Changing the variable will then change the size in every place.

Roman followed up asking about how non-developers would be able to change those values. @jorgefilipecosta said that If one wants to allow a user to change a CSS variable, one could do it by registering a custom sidebar to change the variable. Maybe one day core offers something that automatically renders a UI where users could change variables registered using theme.json, but it is not part of the road map for now.

Developer Hours online

@bph made a big announcement during the core editor chat:

There will be a make core post with more info, this is just a heads-up, about a trial initiative to hold “Developer Hours online” every other week, with a group of Gutenberg developers, a short topic and then answering attendee’s Block and Theme building questions, with screen sharing of code and follow-up post. Depending how the trial goes, we might expand it. If you want to be part of that initiative let me know or comment on the post.

#block-editor, #chats, #core-editor, #core-editor-summary, #gutenberg, #meeting-notes

Implementing a Webfonts API in WordPress Core

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 developers have been able to enqueue scripts and styles for years, but fonts have always been more complicated to enqueue. Following ticketticket Created for both bug reports and feature development on the bug tracker. #46370 and last September’s proposal to add a fonts enqueue API in WordPress Core, we now have a patch ready.

With the recent advancements in 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/, global-styles, and an effort to consolidate options and UIs in the site-editor, a Webfonts APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. is becoming a necessity as it will allow theme developers to define fonts in their theme.json files.

In this first iteration, we are mirroring the scripts & styles enqueueing functions for consistency. Since enqueueing a webfont entails enqueuing a stylesheet (or adding inline styles) to enqueue the font files themselves, the webfonts API functions act as wrappers for the stylesheets API (with the appropriate modifications where needed).

The intention for this initial iteration is to provide a basis we can build upon and improve in the future – which is why it was kept minimal. More improvements and functionality will be added in the future, but in order to improve it, it has to be there.

The patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. adds the following functions:

  • wp_register_webfont
  • wp_deregister_webfont
  • wp_enqueue_webfont
  • wp_dequeue_webfont
  • wp_webfont_is
  • wp_webfont_add_data

The syntax of all these functions is identical to their style counterparts, so wp_register_webfont is the same as wp_register_style and so on. The only difference is the use of $params in lieu of $deps for practical reasons.

Notes:

  • The styles registered for webfonts automatically get a webfont- prefix to avoid conflicts with any similarly named stylesheets. This provides a clear distinction between normal styles and webfonts styles, while keeping the implementation simple.
  • Since webfonts don’t have dependencies, the $deps argument was replaced with $params. These params can be used to register a webfont from local files, and auto-generate the CSSCSS Cascading Style Sheets. for @font-face.

Enqueuing a webfont from a remote URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org

To use a webfonts API (Google Fonts, Adobe fonts, etc), we can use the URL provided by the API directly:

add_action( 'wp_enqueue_scripts', function() {
	wp_enqueue_webfont(
		// The handle
		'dancing-script',
		// URL to the webfont CSS - can use any public API.
		'https://fonts.googleapis.com/css2?family=Dancing+Script:wght@500;600&display=swap', 
	);
} );

This is identical to what we would previously do using the wp_enqueue_style function, but now using a more appropriately named wp_enqueue_webfont function. With the example code above, the webfont will be enqueued and the stylesheet’s handle will be webfont-dancing-script.

Generating CSS for a webfont

It is possible to generate the CSS for a webfont using the provider parameter and the wp_webfont_generate_styles function.

A provider is an object with details about the provider’s implementation and a method to get (or generate) the CSS from that API.

Generating styles for bundled font files

To generate styles for bundled font-files, set the provider to new WP_Fonts_Provider_Local().

$my_font_styles = wp_webfont_generate_styles( array(
	'provider'     => new WP_Fonts_Provider_Local(),
	'font-family'  => 'My Font',
	'font-display' => 'swap',
	'font-style'   => 'normal',
	'font-weight'  => '400',
	'src'          => array(
		get_template_directory_uri() . '/fonts/font.woff2',
		get_template_directory_uri() . '/fonts/font.woff',
	),
) );

Generating styles for Google fonts

To generate styles for a Google font, set the provider to new WP_Fonts_Provider_Google.

$roboto_styles = wp_webfont_generate_styles( array(
	'provider'    => new WP_Fonts_Provider_Google(),
	'font-family' => 'Roboto',
	'font-weight' => '400',
) );

Using the generated styles

You can attach the styles to an existing stylesheet using wp_add_inline_style:

add_action( 'wp_enqueue_scripts', function() {
	// Enqueue theme stylesheet.
	wp_enqueue_style( 'my-theme-styles', get_theme_file_uri( 'style.css' ) );
	// Get webfont styles.
	$roboto_styles = wp_webfont_generate_styles( array(
		'provider'    => new WP_Fonts_Provider_Local(),
		'font-family' => 'Roboto',
		'font-weight' => '400',
	) );
	// Add webfont styles.
	wp_add_inline_style( 'my-theme-styles', $roboto_styles );
} );

Alternatively, you can use the wp_enqueue_webfont function:

add_action( 'wp_enqueue_scripts', function() {
	wp_enqueue_webfont( 'roboto-400', '', array(
		'provider'    => new WP_Fonts_Provider_Local(),
		'font-family' => 'Roboto',
		'font-weight' => '400',
	) );
} );

This will internally call wp_enqueue_style with a blank $src, and attach the webfoot styles to the defined $handle.

Adding implementations for more 3rd-party APIs

At the moment of this writing, Google-Fonts is the most popular API for web fonts, and the only one publicly available, free, with OpenSource-compatible fonts.

Adding implementations for more APIs in the future can be done by extending the WP_Fonts_Provider class.

The $params argument

The $params argument is formatted as an array and accepts all valid CSS props of @font-face as its array keys. Any extra args are ignored. The list of valid descriptors was taken from MDN.
Defining a font-family is mandatory, and skipping that results in no CSS getting generated.

The src

If we’re enqueueing a webfoot from bundled files, then we can use the src to define the files. If we only want to define a single file for the webfont, then we can add it as a string ('src' => $url).
If we have multiple files for the webfont (different formats to support older browsers), then we can use an array ('src' => [ $url1, $url2 ]). In this case, the URLs get internally reordered for browser support (woff2, woff, ttf, eot, otf). SVG for webfonts is not supported because they have been deprecated (see caniuse.com/svg-fonts), so if provided it gets removed (like any other invalidinvalid A resolution on the bug tracker (and generally common in software development, sometimes also notabug) that indicates the ticket is not a bug, is a support request, or is generally invalid. type).

Note: The src can also accept data-urls.

Variable fonts

The font-variation-settings property accepts either a string (normal), or an array of key/value pairs (e.g. ["wght" => 637, "wdth" => 100]) and returns a string of these values (e.g., wght 637, wdth 100).

Props @jonoaldersonwp, @sergeybiryukov for reviewing

A Week in Core – September 27, 2021

Welcome back to a new issue of Week in CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. Let’s take a look at what changed on TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. between September 20 and September 27, 2021.

  • 22 commits
  • 23 contributors
  • 49 tickets created
  • 6 tickets reopened
  • 57 tickets closed

The Core team is currently working on the next point (5.8.2) and major (5.9) releases 🛠

Ticketticket Created for both bug reports and feature development on the bug tracker. numbers are based on the Trac timeline for the period above. The following is a summary of commits, organized by component and/or focus.

Code changes

Build/Test Tools

  • Remove the PHPUnit container from local Docker environment – #54112
  • Splits and improves compat tests – #39265, #53363
  • Update PHPUnit configuration for PHPUnit 9.5.10/8.5.21+ – #54183
  • Upgrades Tests_Multisite_MS_Permalink_Collision fixture methods and strict assertion – #51147

Code Modernization

  • Fix “passing null to non-nullable” deprecation in _mb_substr()#53635

Coding Standards

  • Fix the alignment of the array – [51855]
  • Remove duplicate assignment from a ternary operator in WP_MS_Sites_List_Table::site_states()#38296

Docs

  • Add @since notes to register_setting() for the deprecated misc and privacy option groups – #53399
  • Document some more common names for dynamic hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. and standardise the phrasing used – #53581
  • Fix typo in the $clear_working parameter description in WP_Upgrader methods – #54163
  • Miscellaneous docblockdocblock (phpdoc, xref, inline docs) corrections and improvements – #52217, #53399
  • Update description for retrieve_widgets() per the documentation standards – #53811
  • Update and enhance the docs for retrieve_widgets()#53811

Formatting

  • Pass 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. instance as a parameter to the render_block filters – #53596

General

  • Fix code quality issues which were identified by static analysis – #52217

Posts, Post Types

  • Don’t add a trailing number when there is a unique post parent – #51147

Tests

  • Correct the @ticket reference in wp_terms_checklist() tests – #53363, #51137
  • Don’t skip some Ajax tests 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, add them to the ms-excluded group instead – #53363
  • Further improve the tests for avoid_blog_page_permalink_collision(): – #51147
  • Remove unnecessary setUp() and tearDown() methods in multisite tests – #53363
  • Rename classes in phpunit/tests/multisite/ per the naming conventions – #53363
  • Update the Services_JSON test for PHPUnit 9.5.10/8.5.21+ – #54183, #54029, #53363

Props

Thanks to the 23 people who contributed to WordPress Core on Trac last week: @hellofromTonya (5), @jrf (5), @SergeyBiryukov (3), @netweb (2), @joelcj91 (1), @MaximeCulea (1), @zieladam (1), @mukesh27 (1), @pbiron (1), @aezazshekh (1), @zenithcity (1), @whyisjake (1), @knutsp (1), @tubys (1), @Daschmi (1), @jeremyfelt (1), @audrasjb (1), @terriann (1), @stormrockwell (1), @johnbillion (1), @costdev (1), @desrosj (1), and @hellofromtonya (1).

Congrats and welcome to our 4 new contributors of the week: @aezazshekh, @zenithcity, @tubys, and @Daschmi ♥️

Core committers: @sergeybiryukov (11), @hellofromtonya (4), @johnbillion (4), @whyisjake (2), and @azaozz (1).

#5-8-2, #5-9, #core, #week-in-core

Editor Chat Agenda: 29 September 2021

Facilitator and notetaker: @get_dave.

This is the agenda for the weekly editor chat scheduled for Wednesday, September 29, 2021, 03:00 PM GMT+1.

This meeting is held in the #core-editor channel in the Making WordPress SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/..

  • 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/ 11.6.0 (RC available).
  • WordPress 5.9 “Go, no go” date and priorities.
  • Updates based on updated scope for site editing projects:
    • Template editor.
    • Patterns.
    • Styling.
    • Navigation 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. & Navigation Editor.
    • Block based WidgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. Editor.
    • Mobile Team.
  • Task Coordination.
  • Open Floor.

If you are not able to attend the meeting, you are encouraged to share anything relevant for the discussion:

  • If you have anything to share for the Task Coordination section, please leave it as a comment on this post.
  • If you have anything to propose for the agenda or other specific items related to those listed above, please leave a comment below.

#agenda, #core-editor, #core-editor-agenda, #meeting

Changes to the WordPress Core PHP Test Suite

Why were changes needed?

Dev Wapuu
Image credits: @marktimemedia

The WordPress test suite uses the industry standard PHPUnit tool to run the PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher unit tests.

Over the years, PHPUnit has seen a number of changes, new assertions being introduced, different annotations and more, but most notably, as of PHPUnit 8.0, a void return type was added to the typical fixture setUp() and tearDown() methods.

This void return type is problematic in the context of WordPress, as return types in general were only introduced in PHP 7.0 and the void return type wasn’t introduced until PHP 7.1.
While WordPress still has a minimum PHP version of PHP 5.6, the void return type can not be introduced in the test suite as it would inhibit the tests from being run on PHP 5.6 and 7.0.

At the same time, having to run the tests on older PHPUnit versions (PHPUnit < 8.0) made it increasingly difficult to get the test suite to run on new PHP versions, like PHP 8.0 and the upcoming PHP 8.1 (expected end of November) as these older PHPUnit versions are no longer supported and are not being made compatible with newer PHP versions anymore.

Over the past few years, a number of different solution directions were explored and rejected, largely due to the large maintenance burden these would add to the small team of WordPress contributors maintaining the test framework.

With the upcoming release of PHP 8.1 as a driver, we took another look at this problem and the available tooling in the wider PHP field and a solution has now been implemented which should future-proof the test suite for, at least, a number of years.

The solution

The implemented solution is based on the external PHPUnit Polyfills library, which “allows for creating PHPUnit cross-version compatible tests by offering a number of polyfills for functionality which was introduced, split up or renamed in PHPUnit”.

The PHPUnit Polyfills also solves the void conundrum via a tailored TestCase using snake_case methods.

In effect, this means that the WP CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. test suite can now run on all PHPUnit versions between PHPUnit 5.7.21 up to the latest release (at the time of writing: PHPUnit 9.5.10), which allows for running the test suite against all supported PHP versions using the most appropriate PHPUnit version for that PHP version.

It also means that, as of mid August, the tests are being run against PHP 8.1 and fixes for PHP 8.1 compatibility are currently being made.

With the PHPUnit Polyfills in place, tests can now be written using the feature set of the highest supported version of PHPUnit.
The Polyfills library will fill in the gaps and ensure the tests can still run on lower versions of PHPUnit without problems.

What has changed?

  1. The Composer lock file has been removed.
    The version constraints in the composer.json file have been made stricter to ensure the developer experience is not negatively impacted by this with regards to coding standards checks.
  2. The PHPUnit Polyfills library at version ^1.0.1 has been added as a Composer dev dependency.
  3. All WordPress Core tests now use PHPUnit 9.x assertions and expectations.
  4. All WordPress Core tests now use snake_case fixture methods, i.e. set_up() instead of setUp() and tear_down() instead of tearDown().
  5. The minimum supported PHPUnit version has been raised to PHPUnit 5.7.21 (was 5.4.0).
  6. The WordPress Core test bootstrap file will no longer throw an error when the tests are being run with PHPUnit 8.x or 9.x.
  7. The WordPress Core test bootstrap file will throw an error when the PHPUnit Polyfills are not available or do not comply with the minimum version requirements.
  8. All WP Core native assertions now have an extra, optional $message parameter, just like all PHPUnit native assertions.
    Please use this parameter in all tests which contain more than one assertion to make debugging tests easier.
  9. The WP_UnitTestCase_Base::setExpectedException() method is deprecated and should no longer be used.
  10. The WP_UnitTestCase_Base::checkRequirements() method is deprecated and no longer functional, and in reality hasn’t been for a long time for anyone using it in combination with PHPUnit 7.0+.
  11. The copies of the PHPUnit SpeedTrapListener classes have been removed as they were never actively used in Core.
    Anyone who still wants to use the SpeedTrapListener can install it separately.
  12. The copies of the PHPUnit 9.x MockObject classes which were introduced in the WP Core test suite in WP 5.6 have been removed, as they are no longer needed when the tests are run on the appropriate PHPUnit version for the PHP version used.

While the above changes have been made in WordPress 5.9, a minimal selection of these changes has been backported to WordPress 5.2 – 5.8:

  1. The PHPUnit Polyfills at version ^1.0.1 is now a requirement for the test suites in WP 5.2 – 5.8 and this requirement will be enforced via the test bootstrap.
  2. … which makes all the polyfills for PHPUnit 9.x assertions and expectations available when running tests against WP 5.2 – 5.8.
  3. Additionally, snake_case wrapper methods have been added for the camelCase fixture method names, meaning that for WP 5.2 – 5.8, the snake_case fixture method names will work without needing further work-arounds, both for fixture declarations as well as for calling the parent::set_up() and the likes.

    There is one caveat to this: the backported implementation presumes a fixed order for calling the parent (camelCase) methods versus the child (snake_case) methods: for set_up*() methods: parent first, child second; for tear_down*() methods: child first, parent second.
    This is the standard order, but if you have a fixture method which diverges from this or doesn’t call the parent, you may get unexpected results.

These backports allow for backporting future (security) fixes for WordPress itself without having to make the accompanying tests compatible with older PHPUnit versions.

These backports will also make it more straightforward for extenders to continue to test their 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/theme against multiple WordPress versions.

For full details about all the changes, please have a read through Trac ticket 46149.

Changes under the hood which should not be noticeable:

A new PHPUnit_Adapter_TestCase class has been added. This class is nested in-between the WP_UnitTestCase_Base class and the PHPUnit TestCase class and provides the PHPUnit cross-version adapter layer.

All PHPUnit assertion polyfill methods which previously existed in WP Core have been removed as they are no longer necessary now this functionality is provided via the PHPUnit Polyfills library.
All polyfills for assertions/expectations which were previously in WP are still available, they are now just provided via the Polyfills package.

As for the Docker set up: the PHPUnit container is no longer needed and has been removed from the docker-compose config.

What hasn’t changed:

  • The PHPUnit class aliases (for support of PHPUnit 5), which WP provided are still available, though shouldn’t be needed anymore.
  • You can still extend the WP_UnitTestCase class for your tests and will receive access to everything which was available before + more (i.e. a complete set of polyfills).

Future changes

There is a ticket open to rename some of the WordPress native test helper methods to handle the “doing it wrong” and WP native deprecation notices, as the current method names (too) closely resemble a PHPUnit native method name, which can easily lead to confusion and use of the wrong methods in tests.

When that ticketticket Created for both bug reports and feature development on the bug tracker. is actioned, this dev-note will be updated with the relevant information.

What does this mean for contributors to WordPress Core?

In general:

If you use Composer locally, please run composer update --with-all-dependencies (or composer update -W for short) from the root of your WordPress clone now to make sure your install is updated and to get the most appropriate versions of the dependencies for the PHP version you are running on.

Go on, do that now. This dev-note will wait patiently for you to come back.

You will need to run this command semi-regularly in the future (whenever the composer.json file has been updated).

For WP 5.9 and higher, please don’t use composer install anymore.

If, for example for backports, you need to install the dependencies for WP 5.8 or lower, in that case, you still need to run composer install.

🎓 Why?

The first time you run composer install locally, it creates a composer.lock file and when you run Composer again, it will look at your composer.lock file to install the “locked” versions again.

Previously, with the committed composer.lock file, the lock file was managed and updated centrally. However, that also meant that you often would be running the dev tools at a version which wasn’t the most appropriate one for the PHP version you are working under. This was getting more and more problematic for running the tests, which is why the file was removed.

Now the composer.lock file is no longer committed, you have to update it yourself to make sure you receive the latest version of the dev dependencies appropriate for your PHP version and within the version constraints set in the composer.json file.

For running the Core tests:

If you usually run the Core tests via Docker using the npm run test:php command, you can continue to do so and all should still work as expected.

If you usually run the Core tests via a Composer installed version of PHPUnit, again, you can continue to do so and all should still work as expected as long as you followed the above instructions to run composer update -W first.

If you usually run the Core tests via a PHAR file, you either have to run composer update -W once in a while or you have to set up a clone of the PHPUnit Polyfills repo. For more information about this last option, please see the set up information in the handbook.
If you are running locally on PHP 7.2 or higher, you may want to download a more recent PHPUnit PHAR file (PHPUnit 8 or 9) to benefit from the advances which have been made in PHPUnit.

If you are running the tests locally on PHP 7.2 or higher, you may notice the test runs being faster and the output being enhanced as the tests will now run on a more recent PHPUnit version.

💡 Pro-tip:

Now might also be a good time to verify that your local wp-tests-config.php file is still in sync with the wp-tests-config-sample.php file.

Similarly, if you use a local phpunit.xml overload configuration file, it is strongly recommended to verify that any changes made in the phpunit.xml.dist (and multisite.xml) file are synced into your local configuration.

For writing tests for Core:

You can now use the full range of assertions as available in PHPUnit 9.5 in your tests. Please use the most appropriate assertion available.

Test fixture methods MUST use snake_case method names from now on as per the below table.

Old nameNew name
setUpBeforeClass()set_up_before_class()
setUp()set_up()
assertPreConditions()assert_pre_conditions()
assertPostConditions()assert_post_conditions()
tearDown()tear_down()
tearDownAfterClass()tear_down_after_class()

The Make Core handbook page about writing tests has been updated with this information.
The page has also been enhanced with more handy tips and tricks, so please have a read through!

What does this mean for plugins/themes running integration tests based on the WP Core test suite?

It is a known fact that there are a lot of plugins/themes which use the WordPress Core test framework as a basis for their integration tests.

If your plugin/theme is one of them, these changes will impact you as well.

Step-by-step: how to make your test setup compatible with these changes and with higher PHPUnit versions:

  1. Run your tests against PHP 7.4 with PHPUnit 7.x and WP 5.8.1 and make sure there are no pre-existing errors/failures.
  2. Add PHPUnit Polyfills as a Composer require-dev dependency (or inherit it from WP).
  3. If you add the Polyfills as a requirement and only support WP 5.9 and higher, remove the requirement for PHPUnit in favour of letting the Polyfills handle it. This will prevent potential future version constraint conflicts.
    • If you still need/want to run your tests against older WP versions, keep the PHPUnit requirement and make sure it is set to ^5.7.21 || ^6.5 || ^7.5 and let CI (continuous integration script) handle removing that requirement for WP 5.9.
    • Or do it in reverse and remove the requirement for dev and add it back in CI for older WP versions.
  4. Make sure the Polyfills autoloader is wired in to your test bootstrap.
    • If you’ve chosen to “inherit the Polyfills from WP”, in this context that means that you use a full clone of WordPress and will install the Composer dependencies for WordPress before running the tests. In that case, you should be all set.
    • If you use only a partial clone of WordPress, like when your tests have been set up using the WP-CLIWP-CLI WP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is http://wp-cli.org/ https://make.wordpress.org/cli/ scaffold command, or if you don’t run WordPress’ Composer setup, please make sure you load the Polyfills autoloader in your test bootstrap before running the WP native test bootstrap.
      • If you include your Composer vendor/autoload.php file as your test bootstrap before you run the WP native test bootstrap, you’re all set already, the Polyfills autoloader will be included automatically.
      • Alternatively, you can add a require_once 'path/to/vendor/yoast/phpunit-polyfills/phpunitpolyfills-autoload.php'; in your test bootstrap before including the WP native test bootstrap.
      • As a last alternative, you can declare a WP_TESTS_PHPUNIT_POLYFILLS_PATH constant containing the absolute path to the root directory of the PHPUnit Polyfills installation in your plugin/theme’s own test bootstrap file.
        Again, this constant must be declared prior to running the WP native test bootstrap file.
  5. Search your codebase for declarations of the fixture methods, as well as calls to (parent) fixture methods, and replace camelCase with snake_case in the method names.
    Example:
    // Old:
    public function setUp() {
         parent::setUp();
         // Do something.
    }
    
    // New:
    public function set_up() {
        parent::set_up();
        // Do something.
    }
  6. Verify your tests run without errors after the changes by running them against PHP 7.4 on PHPUnit 7.x with WP 5.8 .
  7. Verify your tests run without errors after the changes by running them against PHP 7.4 on PHPUnit 7.x with WP trunk (= WP 5.9).
  8. While using WP trunk/5.9, switch to PHPUnit 8.x – look out for deprecation notices PHPUnit throws and just literally do what they tell you to do.
  9. While still using WP trunk/5.9, switch to PHPUnit 9.x – look out for deprecation notices PHPUnit throws and just literally do what they tell you to do.

Once you’ve run through these steps, your tests should be cross-version compatible with PHPUnit 5.7.21 – 9.5, able to run against the WordPress 5.2 to 5.9 branches and able to run on PHP 5.6 – 8.1.

Next, you may want to run your tests against PHP 8.0 and 8.1 using PHPUnit 9.x with WP 5.9 to see if your plugin/theme is compatible with these more recent PHP versions.

🚨 Pro-tip:

If you want your CI build to fail when PHPUnit encounters PHP native deprecation notices, make sure to add convertDeprecationsToExceptions="true" to your PHPUnit configuration file as the default value for this setting has been changed to false in PHPUnit 9.5.10/8.5.21.

Enabling this setting is strongly recommended for testing your plugin/theme against PHP 8.1, as PHP 8.1 introduces a lot of new deprecations.

What to do when running tests in CI against multiple WP/PHP combinations?

If you are running your plugin/theme integration tests against multiple WordPress and PHP combinations, you will most likely need to make some adjustments to your Continuous Integration (CI) script(s).

Which exact changes you need to make depends entirely on your specific setup. There is no “one size fits all” solution.

As a general rule of thumb:

  • WP 5.2 – 5.5 is able to run tests against PHP 5.6 – 7.4 with PHPUnit 5.x (PHP 5.6 and 7.0) – 7.x (PHP 7.1 and higher).
  • WP 5.6 – 5.8 is able to run tests against PHP 5.6 – 8.0 with PHPUnit 5.x (PHP 5.6 and 7.0) – 7.x (PHP 7.1 and higher).
  • WP 5.9 and higher is able to run tests against PHP 5.6 – 8.1 with PHPUnit 5.x – 9.x (use the most appropriate PHPUnit version for each PHP version).

Also see the PHP Compatibility and WordPress Versions and PHPUnit Compatibility and WordPress Versions pages in the Make Core handbook.

Other typical things to take into account and to work around when needed:

  • Is there a config - platform - php setting in your composer.json which fixes the PHP version to a specific version – typically PHP 5.6 – for installing dependencies ?
    If so, you may need to either selectively remove this setting or run Composer with --ignore-platform-reqs for certain WP/PHP combinations in your test matrix.
  • Has the composer.lock file been committed ?
    In that case, you may need to either selectively remove that file in CI before running composer install; or run composer update -W for certain WP/PHP combinations in your test matrix.
  • Do you use a complete clone of WP ?
    For WP 5.2 – 5.8, you’ll need to install the WP dependencies by using composer install.
    For WP 5.9 and higher, you’ll need to install the WP dependencies by using composer update -W.

To make sure you run the test against the right PHPUnit version, you may need to run (a variation on):

composer remove --dev phpunit/phpunit
composer update --dev yoast/phpunit-polyfills --with-dependencies --ignore-platform-reqs

💡 Did you know ?

If you use GitHubGitHub GitHub is a website that offers online implementation of git repositories that can 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/ Actions to run your tests for continuous integration and PHPUnit and the PHPUnit Polyfills are your only external test dependencies, as of Setup-PHP 2.15.0 (expected soon), you can use the tools key in the shivammathur/setup-php action to install these:

- name: Setup PHP with tools
  uses: shivammathur/setup-php@v2
  with:
    php-version: '8.0'
    tools: phpunit-polyfills

For more information about the tools key for setup-php, see the action documentation.

For more information on how to wire in the PHPUnit Polyfills when installed via setup-php, see the FAQ section of the Polyfills documentation.

Anticipating some frequently asked questions

I’m a plugin/theme maintainer, but don’t use Composer, can I still run my integration tests?

Yes, but you do need to make sure that either the Polyfills are available via a Composer global or local installLocal Install A local install of WordPress is a way to create a staging environment by installing a LAMP or LEMP stack on your local computer. or via some other manner, like a clone of the repo.

If you haven’t looked at Composer before, now might be a good time to take a look at it.

I’m running my tests via another tool stack (like BrainMonkey, WP Mock, PHP Mock, WP Browser, PestPHP), how do the changes made to the WordPress test suite affect me?

Short answer: They don’t.

Long answer: if you want to run your tests against multiple PHP and PHPUnit combinations, you may still find the PHPUnit Polyfills library helpful to you.

If you’ve not heard of the above mentioned tools before and want to read up on them, here are some links:

I used the WP-CLI scaffold command to set up my integration tests. How do the changes made to the WordPress test suite affect me?

There is no automated way right now to adapt existing tests for which the initial was created via the WP-CLI scaffold command, to make use of the new setup.

The current recommendation is to go through the steps in “What does this mean for plugins/themes running integration tests based on the WP Core test suite?“, which might be more or less involved depending on what version of the scaffolded test setup you are currently using.

A future version of the WP-CLI scaffold plugin-tests command will provide an upgrade mechanism to automatically upgrade an existing test setup to the new requirements. This will include adding a fully Composer-based testing setup as a replacement for the current bootstrap logic, making a composer update possible in the future to keep up with further test setup changes.

If you’re interested in learning more about these plans for the future, please subscribe to the issue on GitHub to stay informed.

I’m using WP Test Utils for my unit and integration tests. How do the changes made to the WordPress test suite affect me?

WP Test Utils is a library offering utilities for both unit testing and integration testing for WordPress plugins and themes. WP Test Utils already includes the PHPUnit Polyfills.

For the unit testing part, which is based on BrainMonkey, you are not affected by the changes.

If you use the integration testing utilities, you will need to make the change from camelCase to snake_case for the fixture methods in your test suite and you can now potentially widen the PHPUnit version requirements for your integration tests (also see the information about this in step 3 of the “Step by step” guide and the information about adjusting CI scripts).

Presuming you were already using the PHPUnit Polyfills provided by the Test Utils to use modern assertions, that’s it. You’re done.

WP Test Utils will continue to handle the integration test bootstrapping, which allows for running the tests against multiple WordPress and PHP versions.

The first version of WP Test Utils which has full support for the test framework changes made in WP 5.9, is WP Test Utils 1.0.0.

WP Test Utils 1.0.0 also includes improved support for integration tests which were created using the WP-CLI scaffold command and support for running tests against WP versions which don’t include the backports, like WP 5.2 – 5.8 point releases released before today, as well as WP < 5.2.


Props to @hellofromtonya, @johnbillion, @dingo_d, @netweb, @sergeybiryukov, @swissspidy, @schlessera for reviewing ahead of publication.

#5-9, #build-test-tools, #dev-notes, #phpunit, #unit-tests