This post summarizes key discussions from the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Committercommitter A developer with commit access. WordPress has five lead developers and four permanent core developers with commit access. Additionally, the project usually has a few guest or component committers - a developer receiving commit access, generally for a single release cycle (sometimes renewed) and/or for a specific component. meeting held on November 25, 2025 with project leadership. As with previous check-ins, the goal is to align on key initiatives, gather feedback, and clarify next steps for the WordPress project.

Note: This meeting followed the Chatham House Rule.

Purpose of these meetings

The group briefly discussed what the goals of these meetings are and which groups are ideal to include. Contributors have asked if only committers are invited, or if broader groups are allowed to join as well (component maintainers, team reps, etc.).

After discussing, the following was agreed upon:

• These meetings are most valuable when committers only attend plus a small group of invited contributors who support that group in establishing and accomplishing project-level goals.
• This creates a safe space for free, honest, and frank conversations, which is the most prominent reason why these meetings are valuable. 
• There is certainly value in having more frequent open forums for wider audiences. These should have narrower focuses, and could have guest speakers, and field some questions ahead of time.

Looking ahead: 2026

The next topic of conversation was forward facing around the planning for 2026 and beyond.

Release Planning Post-6.9

The first item related to 2026 planning discussed was to seek clarification on the rough plan for releases going forward.

The main point to underscore out of this discussion is that the intention in 2026 is to return to a cadence of 3 major releases per year. A release in February was proposed, but most felt that was too short.

• December is really quiet as many people take time off to end the year.
• February release would mean 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. 1 very early in January, leaving just over a month for an alpha period.
• The features that are being worked on would likely not be ready in time for a February release (more on these later).

March or April was suggested, and there was a higher level of confidence in that target.

Lining up the release day of 6.9 with State of the WordState of the Word This is the annual report given by Matt Mullenweg, founder of WordPress at WordCamp US. It looks at what we’ve done, what we’re doing, and the future of WordPress. https://wordpress.tv/tag/state-of-the-word/. is an experiment of a new way to celebrate a release. If it goes well, future major releases could be planned to coincide with flagship events. However, this could be complicated and may require additional planning from leadership and involvement with contributors that help plan release cycles.

• Events are typically planned around budget, venue availability, and regional factors such as the predominant religious holidays or weather patterns.
• It could limit options for release squad members due to availability issues because of time zone differences, or for people who are traveling to and from the events leading up to release day.

Targeted release dates are also influenced by the features being targeted for each release. So which features are targeted for 7.0?

Possible Features for 7.0

To start this conversation, features that were removed from or were not ready in time for 6.9 were mentioned. These included:

• Template activation
• The tabs 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.
• Client side abilities for the Abilities 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.

This rough draft document was shared. Someone in attendance uses this as a way to track any ongoing UXUX User experience/UIUI User interface improvements, who is responsible, their high-level status, etc. and will be turned into a proper post in the near future.

Some other features explicitly discussed:

• WP AI Client work
• Client-side media editing

The status of the adminadmin (and super admin) redesign project was mentioned. The intention of this was clarified. It’s not about completely redesigning the admin area. It’s more about giving it a new coat of paint and refreshing what is already there. How can we revive WP Admin?

• How can the settings screens be improved?
• The view transitions 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 is quite nice and makes the admin feel more modern and refreshed.
• Site Health and the PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher upgrade warning in the dashboard have gotten really scary and overwhelming. How can these be more approachable, useful, and informative?
• Can the dashboard be used more effectively?
  • The About page is seen by so few people today with many sites auto-updating major releases.
  • Are there new ways to inform the user about an update that happened? Or educate them on how to better take advantage of newly added features?
  • Previously, the welcome 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. was updated with each release, but that practice has stopped.
  • Are there new widgets that can be added, such as “on this day” or “new/unresolved notes” for sites making use of the Notes feature.

WordPress AI Client in Core

Work continues on the AI Client parallel to releases. Because the AI client is a great way to encourage the ecosystem to build around solid foundations (such as the Abilities API), the ideal home for this is Core itself. The combining of these related APIs will unlock so many possibilities for developers and site owners.

• Core will always remain agnostic. Including a specific model or only integrating with some third-party services is not sustainable.
• Features can be conditionally available based on the presence of an AI model.
• Open sourceOpen Source Open Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL. models could be used. But oftentimes the experience is bad.
  • Models are quite large.
  • They must download on a per-site basis, which takes time and disk space (even the smallest models are approaching 1GB)
• Machine-based models such as Apple Intelligence may be an option.

A few more promising initiatives/approaches were discussed.

1. Browsers are working towards including models within the browser. This means they would already be installed on a user’s machine, and all data stays local.
2. The W3C WebML working group is working to standardize these tools.

AI can be implemented in a way that browser-based models can be overridden but serve as the fallback/default when no other models or services are configured. In some recent experiments, browser-based models have shown to be very strong when put up against small, state of the art ones.

One exercise that could be helpful is to step back and consider what the use cases are in default WordPress before picking a model. A few possible use cases were mentioned:

• Searching the media library for specific subject matter within images.
• Creating a newsletter based on recent content.

An area of improvement for the group is the story being told. How do the tools being built improve WordPress? How do they benefit the user? How does work being done today open the door for empowering functionality later?

A few more ideas were thrown out as ways to improve how well LLMs work with and for WordPress:

• Improving code base documentation helps LLMs understand the code base better.
• Including “build for WordPress” as a benchmark within models.
• Ensure site content and WordPress is accessible for models.
• Tools like PHPStan and languages such as TypeScript with stricter typing help make the code base more consumable and easier to understand

Raising the minimum required PHP version to 7.4

This conversation focused on the compelling reasons for changing the project’s support policy.

• Raising the minimum allows the project to move forward with new features.
• It’s a balance between bringing users with us and not being held back.
• Not about leaving people behind.
• PHP 7.4 moves the needle in the direction of being more heavily-typed (see previous TypeScript point above), making it easier for AI models to ingest and understand.
• There’s a good amount of bloat in the code base that only remains to support older versions of PHP.
• AI-related SDKs from third-parties have varying minimum PHP requirements. Keeping the minimum required version of PHP too low prevents using some of these.

Understanding Responsible Parties

Throughout the 6.9 release, it was helpful to know who was responsible for or leading efforts for a given feature. It helps the community to better understand where there are gaps and where they can pitch in to help.

When looking at the potential 7.0 features (and beyond), efforts will be made to continue this practice.

Follow Up Action Items

• Propose additional open/semi-open meeting formats for wider community groups and increased transparency (@4thhubbard & @desrosj).
• Publish a release schedule for 2026.
• Determine the targeted features for 7.0 (and possibly 7.1).
• Consider what would be needed to regularly coordinate release days to coincide with in-person events.

The agenda and raw notes for this meeting are available in Google Docs.

Props @4thhubbard for review.

#committers, #core-committer-meetings