Start of the meeting in Slack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/., facilitated by @joemcgill.
Announcements
The WordPress 6.5 retrospective post has been published, please fill in the survey if you would like to leave feedback or suggestions for improvements to the release process.
Forthcoming Releases
Next major 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.: 6.6
We are currently in the WordPress 6.6 release cycle. The deadline for leaving feedback on this Planning Proposal post has ended, and we expect a release squad to be announced soon. Please leave a comment if you have any updates to share about this.
Next maintenance release: 6.5.3
WordPress 6.5.3 will be the next maintenance release. @jorbin published this post outlining the schedule.
@jorbin shared:
Work on WordPress 6.5.3 is progressing. The target for release is 7 May and there are bug 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. scrubs happening twice a week.
Of the tickets I’ve reviewed so far, https://core.trac.wordpress.org/ticket/60992 feels like the highest priority. It has a patch 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. on it that could use some extra testing.
For the full schedule of scrubs or if you aren’t a bug gardener and want to suggest a ticket Created for both bug reports and feature development on the bug tracker. for the milestone, see
https://make.wordpress.org/core/2024/04/15/wordpress-6-5-3-an-upcoming-maintenance-release/
As with all minor releases, any and all help is appreciated.
Slack reference
@afragen confirmed that the expected behaviour of the patch for #60992 is: The patch for 60992 allows the redirect after the Activate button on the plugin 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 card in plugin-install.php. There continues to be no redirect for the Activate button in any modal, ie “More Details” or “View details” modals.
@costdev confirmed that they’re confident we can land the resolution for 6.5.3.
Next Gutenberg 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/ release: 18.2
Gutenberg 18.2 is scheduled for April 24 and will include these issues.
Discussion
There were several proposed discussion topics for today:
- How can we get PHP8 support completed and out of “compatible with exceptions”: suggested by @jorbin
- Aligning the coding standards for Core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. and Gutenberg so that both can use the same tooling: also suggested by @jorbin
- Revisit syncing editor packages early and throughout the release cycle: suggested by @jeffpaul
How can we get PHP8 support completed and out of “compatible with exceptions”
On the first topic, @jorbin noted that: PHP8 support feels to me like one of those things that is kind of stagnent and I would love to see some movement towards full and complete support for all PHP8 versions. I wanted to bring it up as a topic to see if others agree or if people think the current core stance is good.
There is not currently an active effort to reach full support for PHP8.
@jeffpaul noted that: PHP Compatibility and WordPress Versions handbook page that shows PHP8 support (beta 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. support, compatible with exceptions).
@oglekler mentioned that: I am mostly working with 7.4 and from times to times have surprises like this: #46338.
There are 42.5% of WordPress sites using PHP8+ according to https://wordpress.org/about/stats/.
@ironprogrammer mentioned this related proposal: Proposal: Criteria for Removing “Beta Support” from Each PHP 8+ Version.
@joemcgill suggested this may be a conversation that needs to start in #core-php to see if there is already an active effort in place to continue making progress, and if not, try to kickstart the process.
@jorbin noted that the outline the criteria and process for reviewing each "beta support" PHP version with each WordPress major release item is what is needed to get completed to move this forward. And then clearing out the php-compatability focus.
@joemcgill added that it seems like one of the biggest risks currently is that WP continues to show only beta support for supported PHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher versions once 8.4 is released later this year, so it would be nice to make progress on this.
@costdev highlighted that this effort should be led by a sponsored contributor, due to the amount of work involved. @jorbin mentioned that if there is a host who wants to sponsor this, please get in touch via a DM or a comment on this post.
Aligning the coding standards for Core and Gutenberg so that both can use the same tooling
@jorbin kicked off this topic with:
This is inspired by two things:
- The lack of prettier / mismatched tooling for JS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. between the two repos
- The conversation/PR a few months back to remove the WordPress-Docs ruleset from Gutenberg
It’s also something I was just raising for visibility.
Slack reference
@joemcgill noted that: As I recall, this has been mentioned as one of the main challenges to more frequent syncing of GB packages to Core, as well. (e.g., https://github.com/WordPress/gutenberg/discussions/59786#discussioncomment-8784550)
It looks like @get_dave was planning on writing a Make Core post following the above discussion on GitHub 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/. In that discussion, @antonvlasenko summarised two issues relating to the PHP side:
- Developing the missing linters to enforce WordPress Core standards.
- Fixing an issue with synchronizing the rulesets between Gutenberg and WordPress to ensure a unified set of linters.
@jorbin mentioned that for the JS side, there likely is going to need to be a mass reformatting commit or two (if it’s similar to the experience from when jshint was first put into place).
Highlighted posts
The full list of posts from the last week in Core can be read on the agenda at this link.
#6-6, #dev-chat, #summary
