Amy Kamala 3:52 am on June 24, 2026
Tags: 7.1, agenda ( 1,138 ), core ( 739 ), dev chat ( 916 )

Dev Chat Agenda – June 24, 2026

The next WordPress Developers Chat will take place on Wednesday, June 24, 2026, at 15:00 UTC in the core channel on Make WordPress Slack.

The live meeting will focus on the discussion for upcoming releases, and have an open floor section.

The various curated agenda sections below refer to additional items. If you have ticketticket Created for both bug reports and feature development on the bug tracker. requests for help, please continue to post details in the comments section at the end of this agenda or bring them up during the dev chat.

Announcements 📢

7.1 General

Discussions 💬

The discussion section of the agenda is for discussing important topics affecting the upcoming release or larger initiatives that impact the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Team. To nominate a topic for discussion, please leave a comment on this agenda with a summary of the topic, any relevant links that will help people get context for the discussion, and what kind of feedback you are looking for from others participating in the discussion.

Open floor 🎙️

Any topic can be raised for discussion in the comments, as well as requests for assistance on tickets. Tickets in the milestone for the next major or maintenance release will be prioritized.

Please include details of tickets / PRs and the links in the comments, and indicate whether you intend to be available during the meeting for discussion or will be async.

#7-1, #agenda, #core, #dev-chat

Marin Atanasov 8:34 am on June 23, 2026
Tags: 7.1, dev-notes ( 623 ), dev-notes-7-1 ( 4 )

Hiding the Classic block from the inserter in WordPress 7.1

Note: this decision was reverted. You can read more about it in the new dev note.

We’ve just merged a change that will be part of WordPress 7.1 that hides the Classic 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. from the block inserter by default. The Classic block stays registered, every existing Classic block keeps working and remains editable, and a new filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. lets anyone bring it back into the inserter. This post explains what changes, why, and how to opt back in if needed.

What’s changing

Starting in WordPress 7.1, the Classic block (core/freeform) no longer appears in the block inserter (#11712, Trac #65166, originally #77911 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/). In practice, this means you can’t add a new Classic block from the inserter, the block library, or slash commands.

Nothing else about the block changes:

The Classic block remains registered.
All existing Classic blocks (including any  content) continue to render and stay fully editable, exactly as before.
The Classic editor and the underlying TinyMCE experience are untouched. If a post type doesn’t use the block editor, nothing here applies to it.

This is purely about steering new content away from the legacy Classic block, not about removing anything you already have.

To be clear: the Classic editor is not affected at all by this change. This is strictly about the Classic block inside the block editor. If you use the Classic editor (for example, via the Classic Editor pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party. or on post types that don’t use the block editor), your experience stays exactly the same.

Why we’re doing this

The Classic block has been the bridge from the pre-block era into the block editor, and it has served that role well. But it’s also the one block in CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. that doesn’t behave like a block:

Architectural consistency. Every other Core block is a node in the block tree. The Classic block is the lone exception, opaque HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. rendered through a separate editor embedded inside the block editor. Keeping it as a default inserter option works against the block-first model on which the editor is built.
Reducing the inflow. The migrationMigration Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. path away from Classic content (Convert to Blocks) has existed for years, and Classic usage keeps shrinking. Hiding the block from the inserter stops new Classic content from being created, so that set keeps getting smaller rather than growing.
Maintenance leverage. Many block-library improvements have to special-case the Classic block. Each special handling may be small on its own, but cumulatively, this may slow down work that benefits every other block.

The broader, longer-term goal, which will be covered separately as it matures, is to make the Classic block fully opt-in and eventually to lay the groundwork for loading TinyMCE only when it’s actually needed. WordPress 7.1 is just the first user-facing step on that path. None of the later steps are happening in 7.1, and each will get its own discussion and 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, 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..

Opting back in

If you (or your users) still want the Classic block available in the inserter, there’s a dedicated filter: wp_classic_block_supports_inserter.

Return true to show it everywhere:

add_filter( 'wp_classic_block_supports_inserter', '__return_true' );

The filter also receives the post being edited, so you can make the decision conditional, for example, per post type:

add_filter(
	'wp_classic_block_supports_inserter',
	function ( $supports_inserter, $post ) {
		return 'page' === $post->post_type ? true : $supports_inserter;
	},
	10,
	2
);

If you’d rather not write code, there’s a small plugin that does exactly this, Enable Classic Block, which flips the filter on for you. The plugin has already been submitted for approval to the WordPress Plugin Directory.

Backward compatibility

This change is opt-out by design and doesn’t break anything:

No content is modified or migrated. Existing Classic blocks are left exactly as they are.
The block, its edit behavior, and the Convert to Blocks action all continue to work.
The core/freeform block remains registered, so any code that relies on it being present keeps functioning.
Restoring the previous behavior is a one-line filter (or one tiny plugin) away.

What’s next

Alongside this change, we’re investing in the surrounding experience so that moving away from the Classic block is smoother for everyone:

A deprecation/migration notice (experimental). There’s an experiment in Gutenberg that surfaces a notice inside existing Classic blocks, with one-click actions to convert the content to blocks or to a Custom HTML block. We’re exploring this as a gentle way to highlight that the Classic block is being phased out and to make the migration path more discoverable. It’s behind an experiment flag for now while we refine it for a WordPress release.
Improving everything around it. In parallel, we’re improving and fixing the pieces that live by the Classic block: the Custom HTML block, the Convert to Blocks path, freeform handling and conversion, and related compatibility layers. The goal is that by the time Classic content needs to move, the tools to move it are solid.

These, alongside other planned next steps, can be tracked in the dedicated tracking issue.

We’d love your feedback

This is an early step in a longer effort, and we want to get it right. If you maintain plugins or custom integrations, run large sites, or have workflows that depend on the Classic block, we’d really like to hear from you, especially around migration and bulk-conversion needs.

Props to @desrosj, @mamaduka, @mukesh27, @westonruter, @wildworks, and @yuliyan for the contributions, feedback, and code reviews.

Props to @mamaduka and @yuliyan for reviewing this post.

#7-1, #dev-notes, #dev-notes-7-1

Greg Ziółkowski 7:46 am on June 22, 2026
Tags: 7.1, guidelines, Knowledge, merge-proposals ( 8 )

Merge Proposal: Guidelines built on Knowledge

We propose merging Knowledge, a new wp_knowledge custom post typeCustom Post Type WordPress can hold and display many different types of content. A single item of such a content is generally called a post, although post is also a specific post type. Custom Post Types gives your site the ability to have templated posts, to simplify the concept., into WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. for the 7.1 release, with Guidelines as the first feature built on it.

Knowledge is a general primitive for storing author-facing and agent-facing site knowledge as standard WordPress content: a post type with a type taxonomyTaxonomy A taxonomy is a way to group things together. In WordPress, some common taxonomies are category, link, tag, or post format. https://codex.wordpress.org/Taxonomies#Default_Taxonomies., the existing roles and capabilitiescapability A capability is permission to perform one or more types of task. Checking if a user has a capability is performed by the current_user_can function. Each user of a WordPress site might have some permissions but not others, depending on their role. For example, users who have the Author role usually have permission to edit their own posts (the “edit_posts” capability), but not permission to edit other users’ posts (the “edit_others_posts” capability)., native revisionsRevisions The WordPress revisions system stores a record of each saved draft or published update. The revision system allows you to see what changes were made in each revision by dragging a slider (or using the Next/Previous buttons). The display indicates what has changed in each revision., and REST access. Guidelines uses it to give site owners a first-class place to capture the standards that shape how content is written and edited, such as voice, tone, image preferences, and per-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. rules.

The implementation is operational in the GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ 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 has been exercised by production integrations. It builds on the Guidelines experiment, proposed in February and landed in Gutenberg 22.7 in March, then shaped through community feedback into a consolidated design and stabilized for core.

Purpose & goals

Most sites already have content standards, but they live outside WordPress in documents, wikis, and institutional knowledge. Guidelines gives them a canonical home inside WordPress, available where they matter: during writing and editing.

A single store of standards serves everyone who works on a site: writers and editors applying them by hand, plugins reading them, and AI assistants drawing on them too. Each of these needs the same thing, persistent and structured knowledge about the site, and today there is no shared place to keep it. Without a common primitive, every plugin ships its own storage, its own permissions model, and its own REST surface. That is exactly the kind of fragmentation WordPress core has historically prevented, the same way wp_template, wp_block, and nav_menu_item prevented parallel solutions in their domains. Core owns the primitive. The community decides what to build on it.

The name follows that intent. “Guideline” describes prescriptive records well but fits memories and working notes much less naturally, while “Knowledge” covers both procedural content (how work should be done) and declarative content (what is known). Knowledge names the namespace. Individual records are referred to by their concrete type, a guideline, a memory, a note. The user-facing feature in WP Adminadmin (and super admin) remains Guidelines, the same way the attachment post type surfaces as Media at /wp/v2/media.

The goals, concretely:

Provide a canonical storage primitive for author-facing and agent-facing site knowledge
Ship Guidelines as the first feature built on it, demonstrating the primitive in core
Replace fragmented plugin-specific storage, capabilitycapability A capability is permission to perform one or more types of task. Checking if a user has a capability is performed by the current_user_can function. Each user of a WordPress site might have some permissions but not others, depending on their role. For example, users who have the Author role usually have permission to edit their own posts (the “edit_posts” capability), but not permission to edit other users’ posts (the “edit_others_posts” capability)., and REST models with one shared foundation

Non-goals

This merge ships storage and access, not intelligence: no AI provider, no model, no retrieval algorithm, and no autonomous memory system. The specifics below are intentionally out of scope. They remain open topics, just not blockers:

No decay, consolidation, or retrieval mechanism in core. Consuming tools accommodate staleness above the primitive.
Further built-in types are deferred and can be registered by plugins in the meantime:
- skill – a procedure that can load and apply a guideline, is planned for 7.2 pending settled loading and discovery semantics (ai#430)
- plan – task-scoped working state for a multi-step task, pending a side-effect and lifecycle model
- artifact – a reference to a versioned work product distinct from the freeform text covered by note, explored separately
Load applicability of scopes (when a scope’s guidance applies beyond the universal site scope) is left for its own discussion.
Session state and cross-site user preferences live above the primitive.
Encryption at rest is orthogonal hardening that can land later without changing the data model.

What we propose to merge in 7.1

The wp_knowledge custom post type with native revision support
The wp_knowledge_type taxonomy and the wp_knowledge_types registration filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output.
The built-in types guideline, memory, and note (defined below)
The *_knowledge_item capability namespace and the access model described below
The generic /wp/v2/knowledge REST routes for working with knowledge records like other post types
The Guidelines Settings page: per-scope guideline records, a filterable scope registry as the source of truth for the UIUI User interface, and a read-only registry route at /wp/v2/knowledge/guideline-scopes

The knowledge management ability, registered through 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., is expected to follow in a later release.

Built-in types

Each type is defined by what the record represents and how it is applied:

guideline – a standard, pure text that is the source of truth, such as voice, tone, image guidance, or per-block rules. A guideline does nothing on its own. It is there to be applied, either directly by an ability that pulls the text in or through a skill that loads it. The site-wide standards managed on the Settings page carry this type.
memory – durable context explicitly saved or approved for future use, such as user preferences, stable facts, and profile context. Records are private and author-owned. The explicit save-or-approve rule is deliberate: core ships a storage primitive, not a memory architecture. Decay, consolidation, and retrieval remain things to build on top.
note – private freeform working text, such as sticky notes, drafts, and notes synced from external tools. A record saved without a type falls back to note.

Plugins register their own types through the same filter. A plugin might add a glossary type to keep domain terminology consistent across writers, editors, and any agent that reads it:

function my_plugin_register_knowledge_types( array $types ): array {
	$types['glossary'] = array(
		'title' => __( 'Glossary', 'my-plugin' ),
	);

	return $types;
}
add_filter( 'wp_knowledge_types', 'my_plugin_register_knowledge_types' );

Core relies only on the semantics of the built-in slugs it ships. Plugin types are free to define their own behavior.

Guideline scopes

Guideline scopes define the sections shown in Settings → Guidelines and the reserved slugs used to address the corresponding guideline records. Core ships scopes such as Site, Copy, Images, and Blocks, each one a guideline record at a reserved slug like guideline-copy. Plugins register additional scopes through a filter, and the Settings page reads the registry through a read-only REST route at /wp/v2/knowledge/guideline-scopes.

Scopes are not knowledge types. The wp_knowledge_type taxonomy answers what kind of record this is (guideline, memory, note). The scope registry answers where a guideline applies in the Guidelines UI. A scope is addressed by its reserved slug, not a taxonomy term, since a term per scope would attach to exactly one record and duplicate identity into a second system.

Privacy, security, and access model

Knowledge records are not exposed as a public index. The post type is registered as an internal storage primitive, not a front-end content type: it is not publicly queryable, and management flows through the Guidelines UI, REST, and registered programmatic surfaces rather than a native public post-type UI. Collection reads require authentication, per-item reads are capability-checked through read_post, and non-publishers can only create private records. New records default to private on creation.

Actor	Site-wide guideline records	Own private records	Others’ private records	Publish / manage global records
Subscriber	No	No	No	No
Contributor	Read where capabilities allow	Create, read, edit, delete	No	No
Author / Editor	Read where capabilities allow	Create, read, edit, delete	No	No
Administrator	Manage	Yes	Yes	Yes

This matrix reflects the access policy from gutenberg#78296 and will be aligned exactly with the final core 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.. The built-in type set is defined in code through a filter, while the underlying taxonomy terms are created lazily when a record is first saved with a given type, so authoring a record can create its term. Revisions are retained, and autosave is disabled, since knowledge records have no editor session.

Testing

Enable the Guidelines experiment in Gutenberg and verify:

Settings → Guidelines renders its sections from the scope registry, and each scope can be edited, revised, and restored through the 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/
The scope registry route returns core scopes and plugin-registered scopes
A Contributor can create and read only their own private records, and a Subscriber cannot access the post type through REST
REST collection reads require authentication, and non-publishers cannot create published records
No knowledge records are exposed through front-end public queries

Automated coverage for the controller, capability mapping, and type registry ships with the implementation and will be part of the core patch.

FAQ

Is this an AI-only feature? No. The storage primitive is already used for plain note-taking and draft syncing with no AI involved, and the Guidelines experience serves any multi-author site that wants consistent standards. AI tools are one consumer among several.

Does WordPress now have a “memory system”? No. Core ships storage with a clear access policy. A memory record is a durable context a user explicitly saved, comparable to a private post. Anything resembling a memory architecture, including relevance ranking, decay, or consolidation, is left to plugins and integration layers by design.

What about existing plugins that store AI context their own way? Nothing breaks. Plugins can keep their own storage or adopt the shared primitive to gain interoperability, revisions, and the capability model for free.

Why core instead of a plugin? Because the main value is interoperability. A plugin can store its own knowledge records, but it cannot establish a shared convention for how other plugins, editorial tools, and AI integrations store, protect, revise, and expose that knowledge. Without a core primitive, every integration defines its own architecture and the records cannot reliably interoperate. The footprint stays intentionally small: a post type, taxonomy, capabilities, and REST routes that sit unused until something writes to them, with no public queries, no frontend behavior, and no AI processing by default.

Timeline

The core patch is open for review as wordpress-develop#12201, tracked in Trac #65476. It is backed by the Gutenberg work the feature grew from: the rename to the wp_knowledge namespace and the follow-up that migrates Guidelines to use the improved structure.

The naming and scope model are settled, so this proposal moves forward on that basis unless a blockerblocker A bug which is so severe that it blocks a release. surfaces. The open question is narrower: is the API ready to stabilize for core? The names freeze at WordPress 7.1 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 on July 15, when the post type, taxonomy, REST routes, capabilities, and type slugs become long-term compatibility commitments. Feedback that would block stabilizing for core is most useful in the next three weeks, while there is still room to act on it.

Call for feedback

The questions below are where input matters most before these decisions become core commitments:

Is wp_knowledge the right long-term name for the primitive, and are guideline, memory, and note the right built-in type slugs?
Are the capability boundaries in the access model correct?
Is anything missing that should be settled before these names become core compatibility commitments?

The best places to respond are the comments below, the tracking issue, and the #core-ai channel in 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/.

Props to @aagam94, @artpi, @jason_the_adams, and @jorgefilipecosta for review and feedback on this merge proposal.

#7-1, #guidelines, #knowledge, #merge-proposals

annezazu 12:04 am on June 19, 2026
Tags: 7.1, release-roadmap ( 11 )

Roadmap to 7.1

WordPress 7.1 is set to be released on August 19th, 2026. This release advances how people work together in WordPress and opens up new functionality for all to benefit from. New Notes features, including suggestion mode and emoji reactions, make asynchronous feedback richer and more interactive. Meanwhile, real-time collaboration remains an exciting focus area with a few strategic decisions remaining to shape exactly how it’ll show up in the WordPress experience. New options for responsive styling and pseudo-state styling, two longstanding areas of feedback, expand what you can do directly in the Site Editor without needing to use CSSCSS Cascading Style Sheets.. A new Guidelines feature adds a persistent, structured way to encode editorial rules into WordPress, helping you keep your voice and preferences when collaborating with AI. Several new options make it easier to find your way around: see when a 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. inherits its styling from a global setting, set key details about your site in a new Identity section in the Site Editor, find what you need faster with recently used commands and suggestions shown in the command palette, and enjoy the familiarity of the adminadmin (and super admin) bar inside any of the editors. The experience of uploading and using media gets numerous updates, including a new free-form image cropper to get your images just right and client-side media improvements that support more image formats and add resiliency throughout. For those building on top of WordPress, numerous APIs are slated for more features and fixes. Expanded Unicode support is in the works so email addresses, usernames, and slugs can better reflect WordPress’ global audience. Finally, to round out the release are a slew of smaller yet important delights like a new “On This Day” dashboard 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., new blocks, and various writing flow improvements.

As always, what’s shared here is being actively pursued, but doesn’t necessarily mean each will make it into the final release of WordPress 7.1.

For those who want to be involved in the release in a different, more hands on way, there’s a new dedicated outreach effort for WordPress 7.1 to ensure collaborative editing gets the collaborative testing it needs. Learn more here.

AI

AI Client iteration

The AI Client is the foundational piece for running AI programmatically inside WordPress, and for 7.1 the focus stays on empowering 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. authors. Two notable capabilitiescapability A capability is permission to perform one or more types of task. Checking if a user has a capability is performed by the current_user_can function. Each user of a WordPress site might have some permissions but not others, depending on their role. For example, users who have the Author role usually have permission to edit their own posts (the “edit_posts” capability), but not permission to edit other users’ posts (the “edit_others_posts” capability). are planned: generation streaming, introduced first in the PHP AI Client as an initial effort to unlock full usage in a future release, and embeddings, which represent content as vectors to enable meaning-based search across a site. These arrive alongside minor fixes that keep improving the reliability of the AI Client.

Read this Make Core post for more details.

Connectors iteration

After landing a new framework for registering and managing connections to external services in 7.0, work is underway for connectors to gain more ways to authenticate beyond 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. keys. The plan is to start simple with adding username/application password support similar to the existing API key flow and then explore more general, declaratively-defined connection forms (URLs, a default-models dropdown, and more) in PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher, advancing the DataForm API in the process.

Follow this GitHub issue and this Trac ticket for more details, along with the related DataForm issues #76544 and #74865.

Guidelines

After shipping early as an experiment 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/ to gather feedback, a new Guidelines feature lets you define writing and content guidelines that tie into AI tooling, with the ability to import/export guidelines between sites. This brings a persistent, structured system for encoding editorial rules, brand voice, and content standards directly into WordPress for humans and AI alike. As more collaboration happens directly in WordPress, this brings consistency and personalization to that collaboration.

Follow this GitHub issue for more details.

Admin

A more organized command palette

The command palette now groups results into clear sections for recent, suggested, and matching commands. The recently used list is saved to your preferences so they persist across sessions. The design was also updated to make the list of resulting commands easier to scan and understand.

Review this pull request for more details.

Admin color scheme reflected in the Site Editor

The Site Editor 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 overall shell now follow the set WordPress admin color scheme instead of always using a fixed dark background. This ensures broader consistency across all parts of the WordPress experience when personalizing the admin with a color scheme of your choosing.

Review this pull request for more details.

DataViews and DataForms iterations

Work is underway to migrate DataViews onto the new Design System primitives for a more consistent look and feel, and to consolidate Quick Edit with the editor inspector so editing a post’s details feels the same wherever you do it. The DataForm API itself is growing more capable, including support for disabling individual controls. The Site Editor’s Pages, Templates, and Patterns screens are also becoming more extensibleExtensible This is the ability to add additional functionality to the code. Plugins extend the WordPress core software., with a new server-side REST endpoint that lets plugin authors register their own view and form configuration.

Follow this iteration issue for more details.

Dedicated Identity section

A dedicated Design → Identity screen brings the essentials of your site’s identity into one place, with an inline media editor for your logo and favicon and quick editing of your site title and tagline. The aim is to make these foundational settings simple to find and easy to update without digging into templates or needing to go searching in Settings.

Review this pull request for more details.

Design System

Work continues on the shared component library in wordpress/ui and the underlying theming system that powers it. A highlight of this cycle is graduating ThemeProvider from experimental to a stable, public API, alongside finalizing the public token names (background, foreground, and stroke renames), and adding new theme-customization tokens for corner radius and element sizing. In parallel, key parts of the editor UIUI User interface begin adopting improved components, with flyout menus extending to transforms, style variations, and the block ellipsis and transform menus.

Follow this tracking issue for more details.

New “On This Day” widget

The dashboard is getting a new “On This Day” widget that resurfaces past content, a popular feature across many different platforms. Get motivated by looking back on what you’ve written and write more content today for future reminders.

Follow this pull request introducing the “On This Day” widget for more information.

Persistent admin bar across editors (aka omnibar)

The admin bar is getting some nice polish ahead of being easily accessible in the Site Editor and Block Editor. Having landed as an experiment in Gutenberg first, this work brings the toolbar into the editing experience so the admin bar is with you wherever you are. The design update removes the “Howdy” greeting, replaces the home icon with the site icon, makes the profile avatarAvatar An avatar is an image or illustration that specifically refers to a character that represents an online user. It’s usually a square box that appears next to the user’s name. a circle rather than a square, and updates the legacy Dashicons icon font with wordpress/icons SVGs throughout the admin bar.

Follow this iteration issue for more details.

RevisionsRevisions The WordPress revisions system stores a record of each saved draft or published update. The revision system allows you to see what changes were made in each revision by dragging a slider (or using the Next/Previous buttons). The display indicates what has changed in each revision. iterations

After landing visual revisions in 7.0, this release focuses on making them even easier to read and navigate between. Planned improvements include a spark line view in the scrubbing toolbar to better visualize the history of changes, persistent URLs to allow sharing a link to a particular revision, and more.

Follow this iteration issue for more details.

APIs

Abilities API iteration

The Abilities API gives developers and AI tooling a structured, queryable way to expose what a WordPress site can do. This cycle advances querying and filtering of abilities and implements a curated set of coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. abilities (including site settings, current-user info management, and general site awareness).

Review this trac query for more details.

Block Bindings iterations

Block Bindings expands with new support for binding list-item blocks and inner blocks, letting more of your content connect to dynamic data sources.

Follow this iteration issue for more details.

Enforced iframed editor

The post editor has been moving toward always running inside an iframeiframe iFrame is an acronym for an inline frame. An iFrame is used inside a webpage to load another HTML document and render it. This HTML document may also contain JavaScript and/or CSS which is loaded at the time when iframe tag is parsed by the user’s browser., which isolates the editing canvas from the admin’s styles and lets viewport-relative units and media queries work against the canvas instead of the browser window. Today the editor still drops back to a non-iframed mode whenever a block using Block API version 2 or lower is present. To make the rollout gradual, the current plan is to enforce iframing for block-based themes in this release, then extend it to all themes in a future release. In both cases, blocks need to be on Block API version 3 to work in the iframed editor, and 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. guide is available to help extenders get there.

Read the dev note on the 7.0 changes and the block migration guide for more details.

Extended Unicode support in email addresses

This release is looking to broaden Unicode support so email addresses can better reflect WordPress’ global audience. This work centers around allowing storing Unicode email addresses (Core-31992) so functions like is_email(), sanitize_email() and antispambot() can be extended to support non-ASCII addresses.

Read this Make Core post and follow this Trac ticket for more details.

ReactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org 19 Upgrade

WordPress is upgrading from React 18 to React 19. This update will first be merged into the Gutenberg plugin ahead of an eventual pathway to Core. In this upgrade, there are several new APIs, major updates to TypeScript types, changed behaviors and more. Plugin and theme developers, please help test and review what’s coming as early and as much as possible. To help with testing, install and activate the latest version of Gutenberg, head to the experiments page, and turn on the “React 19” experiment.

Follow this tracking issue and read this Make Core post for more details.

Blocks

Icon API expansion

After WordPress 7.0 introduced the foundations of the SVG Icon API (the icon registry, a REST endpoint, and the core Icon block), 7.1’s iteration centers on opening the API up to third parties with new public functions like register_icon() and unregister_icon(), core-icons theme support, SVG sanitization and namespace validation, and collection support (similar to the Font Library) so agencies and product makers can ship their own branded icon sets. The work also explores a reusable icon picker modal for any block, Icon block enhancements like flip and rotate, and making the hardcoded icons in blocks such as Navigation, Breadcrumbs, and Details selectable through the Icon API. Alongside the API work, the core icon set itself is getting a visual refresh, with prominent icons redrawn as stroke-based designs for a more consistent, modern look.

Follow this iteration issue for more details.

Deprecating the Classic block
As a first step towards making the Classic block and TinyMCE opt-in, the Classic block is planned for deprecation in 7.1, and will no longer appear in the block inserter. The related work improves migration and conversion paths and prepares the next step for making the Classic block and TinyMCE opt-in, so sites that don’t rely on the classic experience would get a lighter, faster editor.

Follow this tracking issue for more details and read this Make Core post.

More Core blocks and block improvements

The editor opened with a playlist block visible, listing out three songs.

Every new block added to Core means new possibilities for all, without needing to rely on third party blocks. 7.1 has a few new Core blocks slated for inclusion:

Playlist block, with additional waveform audio visualization.
Table of Contents block, automatically generating navigable links to the headings in your content.
Tabs block, organizes content into tabbed panels.

Alongside these new blocks are a set of upgrades to current block functionality to help you do more with what’s already there:

Gallery block lightbox refinements, including swipe indication and opt-in captions on mobile.
New block support for the HTML block, making it possible to have editable blocks inside of a custom HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. block. This is especially useful with AI generated sites, since LLMs often create custom HTML.
“Mark as decorative” toggle for the Image block to hide decorative images from screen readers for an improved experience.
An shortcode transform was added to the Embed block, so converting or pasting shortcodes now creates a proper Embed block instead of leaving raw shortcodeShortcode A shortcode is a placeholder used within a WordPress post, page, or widget to insert a form or function generated by a plugin in a specific location on your site. text behind.
Block specific transforms were added to the Shortcode block when text matches a registered shortcode. This makes it much easier to convert a shortcode into a comparable block.
The Group block added support for background gradients through a new background.gradient block support, allowing gradients and background images to work together without conflicts. While limited to the Group block for now, block authors can adopt this new support using a simple register block type filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. before it comes to more Core blocks.

This is a great area to contribute to the release. If interested, please help with the Dialog block for transcripts and conversations and the Marquee block for scrolling, animated content as these both are on the list of blocks to add but don’t have a champion.

Writing flow and drag-and-drop improvements

To ensure writing and arranging content continues to get smoother, a dedicated focus is on chipping away at everyday pain points in the writing experience. This includes a wide range of focuses from improving drag and drop to ensuring multi-selection works on touch devices.

Follow this tracking issue for more details.

Collaboration

New Notes features

A Note in the editor with emojis listed to react with.

Notes have a range of planned improvements that include notes on specific content within a block and across multiple blocks, rich text in notes, notifications for replies and follows, emoji reactions, a minified notes experience, and an “apply suggestions” feature. All of these help provide a richer, more interactive experience of collaborating with others directly in the editor.

Follow this iteration issue for more details.

Real-time collaboration

Imagine a world with no post lock screen and with collaborators of all kinds (human and AI) working together to share content with the world through WordPress. After a monumental effort ahead of the last release, real-time collaboration marches ahead with that vision in mind and with big, open strategy questions around:

What to land in this release (full feature vs the underlying architecture)? This came up in a Core Committer meeting at WCEU and is important to directly call out.
What storage mechanism to use? There’s a clear winner that still needs to be decided upon.

These decisions, along with the readiness of the feature, are the key aspects to get right for all of WordPress and to align with project leadership on. They impact who gets access to the feature and what the experience will be like. To help aid the decision making and reliability of the feature, there’s a new dedicated outreach effort for WordPress 7.1 to ensure collaborative editing gets the collaborative testing it needs. Please consider getting involved and learn more here.

Follow this iteration issue for more details.

Customization

Display inherited styles

When you’re styling a block, it isn’t always clear which styles are coming from the theme, a parent, or global styles. This work explores surfacing inherited styles clearly in the sidebar so you can understand where a block’s styles are coming from and edit at the right layer of styling, whether that’s a global or local change.

Follow this tracking issue for more details.

Interactive states styling

A button block with viewport and pseudo state options visible.

A standardized way to style interactive states is taking shape. Support for pseudo-state styling such as hover, focus, and active has landed for both Global Styles and individual block instances, building on the broader “states” effort. Further work, including custom states like styling the current menu item, continues beyond 7.1. All of this work means you can begin to style how blocks respond to interaction, like buttons changing color on hover, all without writing a line of CSS.

Follow this tracking issue for more details.

Pattern editing iterations

With WordPress 7.0, the experience of using patterns shifted to be more like editing a single block with a focus on content changes than exposing every tool available for every block in a pattern. For this cycle, work will focus on UXUX User experience improvements based on feedback around this change, 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, and general maintenance.

Follow this iteration issue for more details.

Responsive styling

View of the option to switch into a responsive editing mode.

Responsive styling for blocks has been a long requested feature and 7.1 aims to be a big step towards more support. Building on the same style states mechanism that powers the interactive states styling for blocks, this work lets you define how a block looks at different screen sizes. This means you can apply responsive styles, like a font size at a certain viewport, directly in the editor without writing custom CSS. The feature will be available both for global styles that apply across every instance of a block, and for individual block instances. The aim is to make responsive design a built-in, first-class part of the editing experience.

Follow this iteration issue for more details.

Viewport breakpoint customization

After adding the ability to hide or show blocks based on viewport, theme-configurable breakpoints defined in 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. are being added to provide more flexible, customizable responsive styling.

Follow this iteration issue for more details.

Media

Client-side media iterations

After being punted from 7.0, client-side media processing keeps getting more capable and resilient ahead of this release. The work spans HEIC image support, Ultra HDR support, GIF-to-video conversion, more resilient uploads that retry on failure and resume after a crash or going offline, video transcoding to web-safe formats, optimization of previously uploaded media, and local poster generation during video upload so pages can render before a video finishes loading.

Follow this iteration issue for more details.

Media editor modal

The Media editor modal replaces the existing inline cropping tool in the Block Editor. The modal keeps the familiar Crop button as the entry point, and brings freeform and aspect-ratio cropping, flip, fine-grained and snap rotation, and metadata editing into one dedicated workflow.

Follow this tracking issue for more details.

Media gallery improvements

Galleries are becoming more dynamic and easier to build, with better handling of the legacy gallery shortcode on conversion, dynamic galleries that can sort or pull media attached to a post, and a quicker path in the inserter’s media tab to images attached to the current post with thumbnails shown directly.

Follow this tracking issue for more details.

Performance improvements

The core performance change planned for 7.1 is an update to speculative loading: when both object caching and page caching are detected, the default eagerness would move from conservative to moderate, prefetching and prerendering more readily on sites equipped to handle it so navigation feels faster.

Follow this Trac ticket for more details.

Two further efforts are being iterated on within feature plugins you can install and benefit from today. Work in the View Transitions plugin centers around bringing smooth, animated transitions between pages on the front end. Work in the Enhanced Responsive Images plugin computes more accurate sizes values in block themes so browsers download appropriately sized images. Both are in active development, and interested contributors are welcome to help move them forward.

Follow the View Transitions and Enhanced Responsive Images issues for more details.

Find something missing? Want to help?

If you have something you’re working on that you don’t see reflected in this post, please share a comment below so we can all be aware! If you’re reading this and want to help, start with the above items and/or pingPing The act of sending a very small amount of data to an end point. Ping is used in computer science to illicit a response from a target server to test it’s connection. Ping is also a term used by Slack users to @ someone or send them a direct message (DM). Users might say something along the lines of “Ping me when the meeting starts.” me (@annezazu) in the 7.1 release leads channel. I have a list of projects that were punted from this release that I’m happy to talk to people about taking on.

Thank you to @ramonopoly @isabel_brison @ellatrix @gziolo @jason_the_adams @ntsekouras (and many others I might be forgetting) for reviews. Thank you to @fcoveram for the beautiful visuals.

Changelog

June 22nd: added more detail to new background.gradient block support for the Group block.
June 24th: updated classic block section.

#7-1 #release-roadmap

Jeffrey Paul 3:03 pm on June 17, 2026
Tags: 7.1, planning ( 36 )

Announcing the WordPress 7.1 Release Squad

This post is announcing the formation of the 7.1 release squad after a call for volunteers.

Exciting News: The WordPress 7.1 Release Squad is assembled!

Release LeadRelease Lead The community member ultimately responsible for the Release.: Anne McCarthy
Release Coordination: Benjamin Zekavica, Krupa Nanda
Tech Leads: Aki Hamano, Joe Dolson
Triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. Leads: Adrian Duffell, Sajjad Hossain Sagor, Sergey Biryukov
Test Leads: Huzaifa Al Mesbah, Nikunj Hatkar

As with the 6.7, 6.8, 6.9, and 7.0 release cycles, WordPress 7.1 will continue the approach of forming a smaller, focused Release Squad. This streamlined structure places more emphasis on collaboration with the various Make Team Reps, who are encouraged to help coordinate efforts from within their respective teams. The goals are to reduce the overhead on the Release Squad while still ensuring each Make Team’s contributions and priorities are represented throughout the cycle, and to reduce overlap between a Make Team RepTeam Rep A Team Rep is a person who represents the Make WordPress team to the rest of the project, make sure issues are raised and addressed as needed, and coordinates cross-team efforts. and that team’s Release Squad Leads. Noteworthy Contributors will be captured from Team Reps towards the end of the release cycle.

The number of volunteers far exceeded the available squad roles, so we selected folks whose experience and focus best aligned with the needs of the 7.1 release. If you weren’t selected this time, your contributions are still incredibly valuable, and there are plenty of ways to stay involved throughout the release cycle, including testing, 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. scrubs, triage, documentation, and more. Every contribution helps move WordPress forward, and we’re grateful for your continued participation.

Big thanks to everyone who volunteered for the release squad, and heartfelt appreciation to everyone helping move WordPress 7.1 forward through testing, triage, documentation, bug scrubs, and more. Your efforts make this release possible, and there’s a lot to be excited about as WordPress 7.1 comes together!

Props to @tyxla, @annezazu, @jorbin for reviewing this post and @jorbin, @desrosj, @annezazu, @tyxla, and @4thhubbard for helping assemble the 7.1 release squad.

#7-1, #planning

Amy Kamala 2:51 am on June 17, 2026
Tags: 7.1, agenda ( 1,138 ), core ( 739 ), dev chat ( 916 )

Dev Chat Agenda – June 17, 2026

The next WordPress Developers Chat will take place on Wednesday, June 17, 2026, at 15:00 UTC in the core channel on Make WordPress Slack.

The live meeting will focus on the discussion for upcoming releases, and have an open floor section.

Announcements 📢

Discussions 💬

Open floor 🎙️

#7-1, #agenda, #core, #dev-chat

Amy Kamala 3:56 am on June 10, 2026
Tags: 7.1, agenda ( 1,138 ), core ( 739 ), dev chat ( 916 )

Dev Chat Agenda – June 10, 2026

The next WordPress Developers Chat will take place on Wednesday, June 10, 2026, at 15:00 UTC in the core channel on Make WordPress Slack.

The live meeting will focus on the discussion for upcoming releases, and have an open floor section.

Announcements 📢

CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.

General

Discussions 💬

The discussion section of the agenda is for discussing important topics affecting the upcoming release or larger initiatives that impact the Core Team. To nominate a topic for discussion, please leave a comment on this agenda with a summary of the topic, any relevant links that will help people get context for the discussion, and what kind of feedback you are looking for from others participating in the discussion.

Open floor 🎙️

#7-1, #agenda, #core, #dev-chat

annezazu 7:29 pm on June 3, 2026
Tags: 7.1, collaboration ( 3 ), feature-real-time-collaboration ( 4 ), gutenberg ( 544 ), phase 3 ( 18 )

Announcing a collaborative editing outreach effort for 7.1

A new dedicated outreach effort is underway for WordPress 7.1 to ensure collaborative editing gets the collaborative testing it needs. Please join #collaborative-editing-outreach in 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/ (steps to sign up here) if you:

Want to use collaborative editing on a regular basis.
Enjoy being an early adopter.
Feel comfortable using the latest version of the GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ 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..
Have the ability to participate through the 7.1 cycle (at least until 8/18/26).

Thanks in advance for helping shape the future of this feature.

Why now?

Collaborative features require an inherently collaborative way of testing. For the 7.0 cycle, a lot of time and effort was spent with more developer oriented testing, enterprise level testing, and deterministic testing with hosts. While incredibly useful, this effort broadens the scope of testing by bringing in passionate real-world early adopters across a range of hosting environments and backgrounds. For collaborative editing to truly succeed, it’s important to go beyond just getting stability, performance, and reliability right.

In running the FSE Outreach Program, I saw how powerful it was to have a dedicated space for folks to regularly interact with those building the feature for a faster feedback loopLoop The Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_Loop in the right direction. After the hard decision was made to remove collaborative editing from WordPress 7.0, the aim is that ahead of 7.1 the outreach program model provides enough structure to create meaningful feedback without being too overbearing or exclusive considering the timeframe. This was first discussed in #feature-realtime-collaboration before being brought to project leadership.

Who can join?

Anyone is welcome to join #collaborative-editing-outreach! Real Time Collaboration is included in the latest versions of Gutenberg, and can be enabled under `Settings > Writing` in the dashboard when the Gutenberg plugin is active.

It’s critical people from across different hosting environments and use cases are a part of this, from nonprofits to small businesses to newsrooms. If you have a large need for collaborative editing, enjoy sharing feedback, and are comfortable with using the latest Gutenberg plugin, this is an awesome way to contribute to the WordPress project. Test team badges will be given out at the end.

More about the effort

The aim is to engage passionate real-world early adopters across a spread of hosting environments in a dedicated slack channel throughout the release process to ensure a tight feedback loop for both bugs and feature requests. This will take a simple form: a dedicated slack channel (#collaborative-editing-outreach) where folks can get set up with collaborative editing, share ongoing feedback, and those working on the feature can open bugs/make fixes/share improvements/etc. Compared to the FSE Outreach Program, there won’t be ongoing themed calls for testing since they would end up being very repetitive. Instead, key updates will be shared in the slack channel to help inform folks as new fixes or features are added to give feedback on them. The latest updates for collaborative editing will be delivered through the Gutenberg plugin which is why using the latest version is a requirement for this channel. As discussed here, a featured plugin isn’t currently feasible.

Tied to this, outreach will be done to hosting companies to attempt to recruit participants for this outreach program. This is being done to help get as many different environments as possible represented.

Currently, @amykamala, @greenshady, and I will be acting as the small crew driving this forward in the slack channel, alongside the developers and designers working on this feature.

Questions? Comments? Concerns?

Please leave them below. Thanks for engaging.

Thank you to @amykamala @greenshady @maxschmeling for reviewing this post.

#7-1, #collaboration, #feature-real-time-collaboration, #gutenberg, #phase-3

Amy Kamala 4:59 am on June 3, 2026
Tags: 7.1, agenda ( 1,138 ), core ( 739 ), dev chat ( 916 )

Dev Chat Agenda – June 3, 2026

The next WordPress Developers Chat will take place on Wednesday, June 3, 2026, at 15:00 UTC in the core channel on Make WordPress Slack.

The live meeting will focus on the discussion for upcoming releases, and have an open floor section.

Announcements 📢

7.1 Development

Upgrade to React 19 targeted for WP 7.1
Call for volunteers ~~closed at the end of last week~~ is still open until this Friday, June 5th, 7.1 squad to be announced.

General announcements

Happy 23rd birthday, WordPress <3
WCEU is this week!
WCAsia Core Committers recap
What’s new in Gutenberg 23.3
Hotfix for publish button placement (TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. #65286)

Discussions 💬

Open floor 🎙️

Props to @audrasjb for collaboration and review.

#7-1, #agenda, #core, #dev-chat

Jb Audras 8:38 pm on May 27, 2026
Tags: 7.0 ( 76 ), 7.0.1 ( 5 ), 7.1, core ( 739 ), dev chat ( 916 )

Dev Chat summary: May 27, 2026

Start of the meeting in 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/, facilitated by @audrasjb 🔗 See the agenda post.

Announcements 📢

WordPress 7.0

WordPress 7.0 “Armstrong” was released on May 20^th! 🚀

Some new dev notesdev 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, 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. were published for 7.0:

WordPress 7.0.1

We have some issues in the milestone, but nothing that deserves an immediate 7.0.1 release (this the below discussion concerning potential hotfixes, though).

@jorbin proposed to publish a call for volunteers in the next couple days to target middle or end of June for the release.

WordPress 7.1

WordPress 7.1-alpha is under active development.

Two posts were published concerning 7.1:

Commence: Operation WP 7.1
WordPress 7.1 call for volunteers. @jeffpaul added that nominations will go until the end of next week, aiming to have a team finalized a week or so after that.

General

Discussion 💬

From @masteradhoc: 3 TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets/PR are waiting for review:

@audrasjb will review them in the next days.

@desrosj suggested to add a legal review to #65025 and pinged @4thhubbard to organize that.

From @jorbin:

#65286 is the ticketticket Created for both bug reports and feature development on the bug tracker. we are discussing. No actions are blocked, but the publishing screen on the non blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor looks extremely messy, so it’s worth cleaning it up while 7.0.1 is being worked on. @desrosj had proposed putting a fix in the Classic Editor plugin which could absolutely work. I was thinking the Hotfix plugin would make sense since it’s possible for this to affect custom post types and people may not be using the classic editor 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. at the same time. There are also other options […] but I think we should pick one and aim to get a solution out sooner rather than later.

@jeffpaul: “if we’ve not confirmed it affects CPTs, then I’m in favor of the classic editor plugin (and also that its low priority in that case)”.

@audrasjb: “I was about to say the same thing, in fact Classic Editor (plugin) seems like a really good option”.

@desrosj: “My thinking about the Classic Editor plugin instead of the Hotfix plugin is that sites that are choosing to remain using the classic editor likely have this plugin installed and activated already. So it fixes a wide number of sites just by pushing the update (provided they have auto-updates enabled, of course). I think we could still include the fix in the Hotfix plugin as well (anyone experiencing the issue without the Classic Editor plugin could install and activate), but it has far fewer users at 4,000+ compared to 9M+.”

@audrasjb: “But it wouldn’t affect websites where the Block Editor is disabled via a hook, or during CPT registration, etc.”

@davidbaumwald confirmed this affects CPTs without the Classic Editor.

@jorbin: “I like the idea of both hotfix and classic editor. I will also say that hotfix should always have a lot less users than classic editor since one is designed as a short term needed plugin and the other is the hotfix plugin”.

@masteradhoc added that the issue will be fixed on the WP Rocket plugin quite fast, as a ticket is already open there.

@jorbin and @audrasjb noted that the Hotfix plugin should be Featured in the plugins list. @audrasjb added that the plugin should also get a small assets refresh.

In conclusion, there is a path forward for the short term (use both Classic Editor and Hotfix plugins), and @jorbin and @desrosj will coordinate to put this together.

@yaniiliev asked whether there are any changes that the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. team would like to see on the new profiles page? Anything missing, anything feeling off? This will be discussed during next week’s meeting. Feel free to comment this summary if you have anything to share about this topic.

#7-0, #7-0-1, #7-1, #core, #dev-chat

Welcome!

Communication

Announcements 📢

7.1

General

Discussions 💬

Open floor 🎙️

What’s changing

Why we’re doing this

Opting back in

Backward compatibility

What’s next

We’d love your feedback

Purpose & goals

Non-goals

What we propose to merge in 7.1

Built-in types

Guideline scopes

Privacy, security, and access model

Testing

FAQ

Timeline

Call for feedback

AI

Admin

APIs

Blocks

Collaboration

Customization

Media

Performance improvements

Find something missing? Want to help?

Changelog

Announcements 📢

Discussions 💬

Open floor 🎙️

Announcements 📢

CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.

General

Discussions 💬

Open floor 🎙️

Why now?

Who can join?

More about the effort

Questions? Comments? Concerns?

Announcements 📢

7.1 Development

General announcements

Discussions 💬

Open floor 🎙️

Announcements 📢

WordPress 7.0

WordPress 7.0.1

WordPress 7.1

General

Discussion 💬

Site resources