The WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:
Found a bugbugA 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.?Create a ticket in the bug tracker.
This proposal aims to introduce the concept of legacy components and a process of managing them in a way that is intentional and accountable.
Once something is committed and released in WordPress CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress., it comes with an implicit promise of backward compatibility for the foreseeable future. But it’s not clear what to do when a feature becomes outdated, unused, or deprioritized. These features often remain in Core instead of being removed or moved to a pluginPluginA 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, where bugbugA 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. reports and feature requests can be more appropriately handled, as was done with PressThis.
Maintenance mode would be an official status for components that should continue to be supported, but are no longer actively developed. Components might qualify for this status for reasons such as:
Low priority
No Maintainer
Better, more modern options available
Being replaced in the near future
These components would:
Continue to receive security updates when necessary.
Continue to consider and evaluate all bug reports on an individual basis.
Stop accepting feature or enhancementenhancementEnhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. requests, unless they are necessary to maintain backward compatibility or prevent breakage in new WordPress or PHPPHPThe web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher versions.
Maintenance mode could be removed from components in the future if conditions change.
What does maintenance mode look like?
When in maintenance mode, components would continue to have maintainers and regular triaging should continue. They would be marked clearly in TracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. and the Components page.
How would maintenance mode be declared for a component?
The process for placing a component in maintenance mode would be flexible and decided on a case by case basis. The process should be transparent and involve open discussions with the contributor community. The process could work like this:
A discussion is opened with (or by) current component maintainers about placing a component into maintenance mode.
A call for proposal and call for feedback on Make Core is published detailing why the component(s) are being considered for maintenance mode.
The component is placed in maintenance mode after sign off from leadership.
While a proposal to add the maintenance mode label will usually come from maintainers, it can also be proposed by any Core contributor. Contributors can perform regular audits of all components to try and identify any that are appropriate for maintenance mode.
What are the benefits of placing components in maintenance mode?
Clarifies which features are actively maintained, helping contributors and developers focus their efforts where they’re most impactful.
Reduces triagetriageThe act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. noise by lowering the volume of low-priority feature requests (there are currently over 8200 open tickets in Trac).
Prevents contributor frustration by setting clear expectations before time is spent on patches that are unlikely to be accepted.
Establishes precedent for responsible deprecation of features without requiring immediate removal.
Supports long-term maintenance by allowing legacy components to receive targeted attention without open-ended development pressure.
Facilitates better communication with users and extenders about Core’s direction and future support levels.
Current Maintenance Mode Candidates
Here are a few components that are possible candidates for the proposed maintenance mode state.
TinyMCE
TinyMCE no longer powers the blockBlockBlock 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 and only remains in Core to maintain Classic Editor support and backwards compatibility. There’s currently only 5 tickets in the component on Trac, and updating to more recent versions of the library does not have enough benefit to justify contributors’ time and effort. Its low ticketticketCreated for both bug reports and feature development on the bug tracker. volume, lack of active development, and functional redundancy make it a strong candidate for maintenance mode.
Customize
The CustomizerCustomizerTool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. served WordPress well, but has effectively been replaced by the block editor and full site editing. Sites with block themes no longer have access to the Customizer by default. Despite having 184 open tickets, development has slowed significantly with most activity focused on bug triage rather than feature enhancements.
Shortcodes
Shortcodes played a huge role in WordPress’ evolution, but today blocks offer a more modern and flexible alternative. No new features should be added to shortcodes. In fact, the APIAPIAn 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.’s brittle nature has historically led to bugs from even minor changes (see #58333). There are currently 54 open tickets in this component (5 feature requests and 11 enhancements).
Pingbacks/Trackbacks
Pingbacks and trackbacks are a big part of blogging, so they should remain for the foreseeable future. It could be replaced by Webmentions in the future should that mature a bit. The last enhancement ticket was merged over 5 years ago now (see #36576), and there has only been one feature ticket in the history of the component (#34420).
XML-RPC
XML-RPC is essential to many external apps and services that interact with WordPress, so it can’t be deprecated. But, the spec has remained largely unchanged for over a decade. There have been no new enhancement or feature requestfeature requestA feature request should generally begin the process in the ideas forum, on a mailing list, as a plugin, or brought to the attention of the core team, such as through scope meetings held for each major release. Unsolicited tickets of this variety are typically, therefore, discouraged. tickets closed as fixed since 2017 (term metaMetaMeta 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. support, see #40916) and 2012 (retrieving post terms, see #18434).
Conclusion
Labeling components as legacy and placing them in maintenance mode helps set accurate expectations, reduce unnecessary churn, and focus contributor efforts on current project priorities. A documented process also gives maintainers a framework for making intentional, accountable decisions about the level of support each component receives.
If adopted, this approach could help scale WordPress Core’s maintenance model while staying true to the project’s principles.
Release Candidaterelease candidateOne of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). 1, scheduled for March 3rd (read more about the WordPress 5.4 Development Cycle)
@johnbillion got to the heart of the matter: should betaBetaA 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. be for fixing bugs that predate the ones introduced during alpha?
@jeffpaul shared his experience since version 4.7: beta is for any bugs, but the release candidate is for regressions only, even though the handbook doesn’t specifically point one way or the other.
@johnbillion liked the idea that beta is for every bugbugA 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., as long as it’s in the milestone. But he noted that could make things tough in shorter release cycles.
@jeffpaul pointed out that avoiding committing non-regressionregressionA 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. bugs during beta means Beta and RCrelease candidateOne of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). wouldn’t be as clearly different from each other as they are now. Potentially, they could merge into a single term.
@johnbillion averred that bugs could still get fixed in beta, but RC should be the point where the CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. team is happy to release.
@joemcgill confirmed the current release cadence is set to assume that bug fixes of all types happen during the beta period (with digression from committers about what is safe to commit).
@joemcgill@johnbillion@azaozz all liked the idea of branching earlier in the cycle — for instance, at beta 1 — so people can keep working in trunktrunkA directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision., and @sergey confirmed things typically go pretty smoothly on that end. He also favors branching as soon as the current milestone is empty.
per @johnbillion, @matt has, in the past, preferred to keep focus on the current release.
@joemcgill and @francina — with other voices chiming in from the group — confirmed that 5.4 will continue as planned, with no changes. Any changes the working group comes up with will be effective no sooner than with the 5.5 cycle.
@francina proposed a change to the Components Check-in.
Up to now it’s typically fallen towards the end of the chat, so it feels rushed and rarely leaves enough time to dig into topics the group might bring up. She offers two options:
Schedule a weekly post in Make, where maintainers can leave a status update, like the one for Community deputies;
Adopt a Slackbot that, once a week, asks maintainers for a status update.
@francina also proposed that those updates — and other communications — live in a new #component-maintainersSlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel. Core is getting very busy with automated updates like TracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. and Travis bots, plus RSS.
@valentinbora observed he hasn’t seen many check-ins in past meetings. @francina surmised that maintainers might not have time [to meet], or that time zones and other commitments [could be sources of conflictconflictA conflict occurs when a patch changes code that was modified after the patch was created. These patches are considered stale, and will require a refresh of the changes before it can be applied, or the conflicts will need to be resolved.].
@francina and @valentinbora agreed that going async [communicating asynchronously] could help.
@francina to collect all the different info streams about the development cycle, offer a window to comment and update documentation;
@audrasjb to get all dev notesdev noteEach 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, and 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. by the end of the week and publish the Field GuideField guideThe field guide is a type of blogpost published on Make/Core during the release candidate phase of the WordPress release cycle. The field guide generally lists all the dev notes published during the beta cycle. This guide is linked in the about page of the corresponding version of WordPress, in the release post and in the HelpHub version page. before RC1.
You must be logged in to post a comment.