What’s New for Developers?  ## Metadata - Author: [[Justin Tadlock]] - Full Title: What’s New for Developers? - Category: #articles - Document Note: --- tags: - #wordpress - #developer-updates - #open-source Author: Justin Tadlock Source: WordPress Developer Blog Reference: https://developer.wordpress.org/news/2025/08/whats-new-for-developers-august-2025/ date created: 2025-08-16 13:05 --- # Title: What’s New for Developers? (August 2025) ## Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📖 References](#-references) - [🗣️ Paraphrase](#-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-diversity-equity-inclusion-and-belonging-assessment) - [✅ Logical Validity](#-logical-validity) - [🔍 DARVO Analysis](#-darvo-analysis) - [🔍 SEO Evaluation](#-seo-evaluation) - [🎯 Conclusion](#-conclusion) --- ## 📝 Summary The August 2025 WordPress Developer Blog roundup previews the path to WordPress 6.9 with an emphasis on block library growth, theme.json interface control, customizable block bindings, AI-driven development tools, coding standards, and component updates. It also covers major Data Views enhancements, Playground internationalization, theme and block-level UX updates, and forward-looking proposals on composite blocks and plugin release workflows. --- ## 📖 Main Content Key developments and discussions: 1. **Core Block Library Expansion** - Greater willingness to include more design-oriented blocks in Core. - Matías Ventura notes that excluding key blocks hurts interoperability and adoption. - Icon block proposal is gaining traction. 2. **theme.json Control Enhancements** - Proposed ability to toggle UI elements for any block, globally or per-post type. - Requires Core blocks to fully adopt standardized ToolsPanel components. 3. **Customizable Block Bindings** - New `block_bindings_supported_attributes_{$block_type}` filter. - Example given for making Video block `src` attribute bindable. 4. **Plugin and Tooling Updates** - Phased plugin release infrastructure being prepared. - Composite blocks proposal to allow easier child-element styling. 5. **AI Building Blocks** - Four foundational tools: PHP AI Client SDK, Abilities API, MCP Adapter, AI Experiments Plugin. 6. **Coding Standards & Components** - WPCS 3.2: stricter meta checks, PHP heredoc sniff, improved PHP 8.1+ callable support, expanded deprecation detection. - New DateCalendar & DateRangeCalendar components for unified single/range date selection. 7. **Data Views Progress** - New per-page size options, additional fields/operators, grouping support, and date field type with sorting/validation. 8. **Playground & CLI Updates** - Documentation translated into five languages. - OPCache, Node.js multi-worker, and Xdebug improvements. - CLI additions: Blueprints v2, internal cookie store, cleaner debug output. 9. **Theme Updates** - Poster image control for Video block. - Button element inherits typography. - HTML tag selector for Post Content block. 10. **User-Facing Changes Relevant to Developers** - Gallery/Site Logo blocks adopt ToolsPanel. - Video block supports multiple track uploads. --- ### 🗒️ Notes - **Roadmap Context**: Sets the stage for WordPress 6.9 with site editor evolution, content creation refinement, and performance focus. - **Block Library Expansion**: Potential Core inclusions could help theme developers avoid extra plugins; reverses historic avoidance of “niche” blocks. - **Ventura’s Argument**: More Core blocks reduce fragmentation and improve theme interoperability; plugin approach doesn’t fully solve adoption issues. - **theme.json Control Proposal**: Would allow theme authors to fully tailor editor controls, both globally and per-block/post type. - **ToolsPanel Standardization**: Critical for granular UI control; groundwork already laid. - **Customizable Block Bindings**: Devs can now define additional bindable attributes; Video block example provided. - **Phased Plugin Releases**: In progress but not yet officially announced; could improve rollout safety. - **Composite Blocks Idea**: Targets blocks like Details for more intuitive child element styling. - **AI Tools for Core**: Encourages dev participation in #core-ai discussions; potential for AI-native WordPress features. - **WPCS 3.2**: Introduces tighter checks, better modern PHP support, and enhanced deprecated feature detection. - **New Calendar Components**: Replace legacy DatePicker with more flexible, unified system. - **Data Views**: Gains major flexibility for developers building data-heavy interfaces. - **Playground**: Expanded multilingual reach, technical enhancements, and CLI feature set growth. - **Themes**: Video block poster image UI, typography inheritance for buttons, new HTML tag options for Post Content. - **UX Consistency**: ToolsPanel adoption in media-related blocks hints at broader theme.json configurability. - **Community Call**: Developer Blog invites contributors to share tutorials and knowledge. --- ## 📖 References - Gutenberg GitHub discussions & PRs - WordPress.org plugin infrastructure updates - WPCS 3.2 release notes - Core AI team announcements --- ## 🗣️ Paraphrase 1. *Original*: “I think not having these blocks in the core library severely limits the expressiveness...” *Paraphrase*: Without certain blocks in Core, developers face design limitations, pushing them toward external block sets that may disrupt consistency. 2. *Original*: “With the latest WordPress trunk active, you can customize which blocks and their attributes can be bound.” *Paraphrase*: Developers can now choose exactly which blocks and attributes support data binding using a new filter. --- ## 📰 Newsletter **August 2025 Developer Update** ✨ WordPress 6.9 is on the horizon with potential new Core blocks, expanded theme.json control, and customizable block bindings for more flexible data connections. AI tools, stricter coding standards, and component upgrades join major Data Views and Playground enhancements. Themes get fresh UI options, and discussions on plugin rollout strategy and composite blocks point toward a more refined development future. Dive in: [Read the full update](https://developer.wordpress.org/news/2025/08/whats-new-for-developers-august-2025/) --- ## ✅ Action Items - Develop hands-on tutorial for using the new Block Bindings filter. - Advocate for inclusive Core block expansion with community testing. - Engage with #core-ai to explore integrating AI Building Blocks into production workflows. - Monitor phased plugin release developments for plugin team readiness. --- ## 🧪 Hypotheses 1. Expanding Core blocks will reduce reliance on third-party block libraries. 2. theme.json UI control will lead to more consistent, accessible site designs. ### 📊 Methodology - Pre/post adoption surveys for theme developers. - Analysis of plugin dependency shifts after Core expansions. ### ❓ Questions - Could Core block expansion negatively impact plugin innovation? - How might AI Building Blocks reshape WordPress developer workflows? ### 🔮 Future Research - Long-term study of UX impact from theme.json granular control. - Performance metrics for expanded Core block library. ### 💡 Implications - Decisions here could set precedent for balancing Core scope with plugin ecosystem health. --- ## 🧠 Learning Styles Assessment - **Visual**: Some screenshots; could add diagrams for block relationships. - **Aural**: None; could add audio summaries. - **Verbal**: Strong descriptive writing. - **Kinesthetic**: Lacks interactive demos—recommend sandbox links. - **Logical**: Strong API and proposal breakdowns. - **Social**: Some community links; could encourage collaborative experiments. - **Solitary**: Could offer self-guided exercises. - **Naturalistic**: No real-world environmental analogies. --- ## 📊 Accessibility Assessment - Likely WCAG-compliant; semantic H - Summary: What does the future of WordPress hold? A new admin, future API discussions, and the usual updates in this monthly roundup. - URL: https://developer.wordpress.org/news/2025/08/whats-new-for-developers-august-2025/ It’s already August, and we have a freshly printed [Roadmap to 6.9](https://make.wordpress.org/core/2025/07/28/roadmap-to-6-9/). Everything from evolving the site editor to refining content creation to performance improvements is on the docket. That means the last few months of 2025 are bound to be exciting ones. If you’re up for some *light* reading before jumping into the rest of this month’s news, I encourage you to at least peruse: * [Abilities & Workflows Overview](https://github.com/WordPress/gutenberg/issues/70710): An overview of the elements needed to unify admin commands, shortcuts, and AI-assisted workflows. * [Admin Materials and Surfaces](https://github.com/WordPress/gutenberg/issues/70913): A discussion on the structure of the future admin and mapping out the main elements that compose it. * [Admin Redesign: A solid routing foundation:](https://github.com/WordPress/gutenberg/issues/70862) A tracking document of the tasks for building the routing foundation for the WordPress admin redesign. ##### Expanding the Core block library? It might be in the cards Decorative image with a black background with a dotted border. In the center is a list of WordPress block type names and icons. There are always discussions of new blocks for Core happening. Just hop over to read the [current] 63 tickets labeled [New Block](https://github.com/WordPress/gutenberg/issues?q=state%3Aopen%20label%3A%22New%20Block%22) in the Gutenberg repository. In the past, there has seemed to be a hardline stance against anything that might’ve been too niche to include in Core, leaving third-party developers to fill the gaps. This has been a good system over the last two decades, but blocks are unlike other plugins. Theme authors rely on having a full toolkit to create unique designs without making users jump through the hoops of installing extra plugins. The good news is that the previous stance may be softening. Gutenberg lead architect Matías Ventura stated in the ticket [New Block additions for the Block Library](https://github.com/WordPress/gutenberg/issues/71026): > I think not having these blocks in the core library severely limits the expressiveness that theme builders (and users) can depend upon to build great designs and it can fracture the overall experience, forcing people to go for more fully equipped block libraries instead or desist altogether if they plan to release something broadly. One of the promises of blocks is that we can finally make themes interoperable without dulling down expression. A separate plugin for these blocks won’t help much if a person needs to release a theme or a pattern in the directory, cannot rely on the presence of the block, or is excluded because it doesn’t use core blocks. > > My opinion is that we should add a lot more blocks and revise a stance that I think harms adoption in this day and age. > > We’re still a few steps away from completely opening the floodgates, but there are already several tickets and PRs linked in the GitHub issue that make for possible block candidates. I wouldn’t doubt it if the [Icon block proposal](https://github.com/WordPress/gutenberg/issues/16484) has the most support. At the very least, it has stirred up a lot of discussion in recent weeks. What do you think? The more blocks in Core the merrier? Or leave it to plugins? In the last week, a new ticket landed in the Gutenberg repository that [would allow deeper control](https://github.com/WordPress/gutenberg/issues/71013) over the block editor’s user interface and experience from `theme.json`. The ticket also pushes for such control via post type registration. This is another idea that’s not a done deal yet, but it is an exciting proposal that could have some real momentum behind it. Currently, `theme.json` control of the user experience is a far call from being feature complete. But there is hope. Now that the UI for all the Core blocks [has been standardized](https://github.com/WordPress/gutenberg/issues/67813) via the `ToolsPanel` component, contributors have taken the first step toward making this secondary proposal a reality. The ticket outlines the next two steps that must be taken to make this level of control possible: * Audit all block tool panels, ensuring that all inspector controls and toolbar options can be enabled/disabled via `theme.json`. It would require all Core blocks to adhere to those standards. * Ensure this new mechanism can be used both globally and at the granular level. As a theme author, I’m excited about the prospect of enacting more control over the user experience. It would give me the freedom to implement some of the ideas I’ve had in these last few years but have lacked Core support for. I’ve rattled on enough about things that *might* happen at some point. Let me dive into a feature that is about as much of a sure thing as it gets. With the latest WordPress trunk active, you can customize which blocks and their attributes can be bound. As of WordPress 6.8, this support has been limited to the Heading, Paragraph, and Button blocks. But now things are wide open with the new `block_bindings_supported_attributes_{$block_type}` filter hook. It didn’t take me long to tinker with this once the [patch was committed in WordPress trunk](https://core.trac.wordpress.org/ticket/62090). My first test was making the Video block’s `src` attribute bindable, as shown in this screenshot (yep, that’s really a custom binding under the hood): Screenshot of a webpage with a video of ducklings on it. Want to test your own bindings? Here’s the filter I used for making the Video block’s `src` attribute bindable: ``` add_filter( 'block_bindings_supported_attributes_core/video', 'devblog_bindable_video_attrs' ); function devblog_bindable_video_attrs( array $attrs ): array { return array_merge( $attrs, [ 'src' ] ); } ``` I’ll let you take the rest from there. Be sure to check out the [Block Bindings API tutorials](https://developer.wordpress.org/news/tag/block-bindings/) right here on the Developer Blog if you need to freshen up your knowledge. The only problem I have run into is not having enough time to try out all the ideas I’ve had for the last year or so since the API graced us all with its initial featureset. *I’m going to have so much fun with this!* In last month’s edition of the monthly roundup, I noted a ticket that WordPress co-founder Matt Mullenweg opened: [Phased releases and roll-outs of plugins](https://meta.trac.wordpress.org/ticket/8009). Over the last couple of weeks, contributors have steadily pushed new code to WordPress.org to make this possible. There’s been no official word via the [Make Plugins P2](https://make.wordpress.org/plugins/) yet, but it’s worth keeping track of if you have plugins in the official directory. A [discussion on “composite” blocks](https://github.com/WordPress/gutenberg/issues/70994) is in the early stages on the Gutenberg repository. The idea is that there should be an easier way for blocks that contain specific nested blocks to surface those children for styling in the UI but be granular enough to style separately through `theme.json`. The Details block was noted as a suitable candidate for the concept (i.e., styling its `<summary>` element). It’s still too early to tell where the discussion leads, but it could potentially cater to both theme authors with more granular design control and users with a simpler interface. The Core AI team published its [AI Building Blocks for WordPress](https://make.wordpress.org/ai/2025/07/17/ai-building-blocks/) post, which gave a quick overview of the four building blocks with dedicated posts detailing each one: If you’re interested in bringing these tools to Core, join the discussions in the [#core-ai](https://wordpress.slack.com/archives/C08TJ8BPULS) Slack channel. ##### WordPress Coding Standards 3.2 released The latest iteration of the WPCS landed in the last month with several new feature additions and general changes. Some of these include: * Stricter meta usage checks * Sniffs for PHP heredoc syntax * Improved PHP 8.1+ callable support * Expanded deprecated feature detection to WP 6.8.1 And that’s just to name a few items. The release also includes improved documentation and other optimizations to make your code better. Check out the [release changelog](https://github.com/WordPress/WordPress-Coding-Standards/releases/tag/3.2.0) for details on all the updates. Gutenberg 21.3 added the `DateCalendar` and `DateRangeCalendar` components, a needed improvement over the current `DatePicker` component, which doesn’t support date ranges. [The new components](https://github.com/WordPress/gutenberg/pull/70578) create a unified approach to calendars that supports both single dates and date ranges. They also provide more flexible layout options. Contributors merged several notable tickets on Data Views over the past month: WordPress Playground has had a big month, especially when you consider that 39 pages of [its documentation](https://wordpress.github.io/wordpress-playground/) was translated into five languages: Gujarati, Spanish, Japanese, Filipino, and Portuguese. There’s also a new [Playground CLI](https://wordpress.github.io/wordpress-playground/developers/local-development/wp-playground-cli) doc, an updated [Web Instances](https://wordpress.github.io/wordpress-playground/web-instance) doc, and new [video resources](https://wordpress.github.io/wordpress-playground/resources#videos). Several general updates landed in the last month: A few nice additions to the Playground CLI include: * Blueprints v2 added via the `--experimental-blueprints-v2-runner` flag. * An [`--internal-cookie-store`](https://github.com/WordPress/wordpress-playground/pull/2323) option if you need Playground to own the cookie session in your workflow. * [Stop printing the stack trace](https://github.com/WordPress/wordpress-playground/pull/2401) if the `--debug` flag isn’t set and reject unrecognized options. Experimental Xdebug support had already shipped during the last monthly roundup, but contributors continued improving it by: Over the last few years, several theme authors have implemented custom solutions for implementing the `poster` attribute for the Video block. Typically, these would fall back to using the attachment’s featured image if it existed. But most users wouldn’t make the jump to uploading the image since the UI for it is removed from the block inspector controls. Gutenberg 21.3 introduced a dedicated control for [uploading a poster image](https://github.com/WordPress/gutenberg/pull/70816) for Video blocks. The downside of the PR is that the image is only stored on the block level and not added to the media attachment itself. So you might still need that custom script as a fallback in cases where the user doesn’t add their own poster. As of Gutenberg 21.3, the button element defined in the default `theme.json` [inherits typographical styles](https://github.com/WordPress/gutenberg/pull/70676) from its parent. The full styles for the element now look like this: ``` { "styles": { "elements": { "button": { "typography": { "fontSize": "inherit", "fontFamily": "inherit", "fontStyle": "inherit", "fontWeight": "inherit", "letterSpacing": "inherit", "textTransform": "inherit", "lineHeight": "inherit", "textDecoration": "none" } } } } } ``` This should not negatively affect most themes, but it’s worth testing your design to ensure compatibility. If it does impact your design, it’s likely that button elements were not consistent between the front end and editor in your themes in the past. Gutenberg 21.3 also added [support for selecting a tag](https://github.com/WordPress/gutenberg/pull/70698) via the **Advanced → HTML Element** dropdown for the Post Content block, giving you more flexibility over the document markup. The block now supports four selectable elements: Contributors addressed several theme-related issues over the last couple of Gutenberg releases: As usual, there are some changes that are more specific to users but are noteworthy in this development-related roundup because they directly impact your users. Both the [Gallery](https://github.com/WordPress/gutenberg/pull/67904) and [Site Logo](https://github.com/WordPress/gutenberg/pull/70599) blocks now use the `ToolsPanel` component for their settings. This is a part of a [larger effort](https://github.com/WordPress/gutenberg/issues/67813) to bring consistency to the block inspector across all Core blocks. It’s also possible that this effort leads to making all [block settings configurable](https://github.com/WordPress/gutenberg/issues/67813) via `theme.json`. The Video block also has support for [adding multiple tracks at once](https://github.com/WordPress/gutenberg/pull/70689). This eliminates the need to repeat the process for each file. There is one additional item from the Developer Blog in the past month. It’s a tutorial that showcases [how to style block themes](https://developer.wordpress.org/news/2025/07/you-dont-need-theme-json-for-block-theme-styles/) without `theme.json`. This section is a bit light this month. And while I think the pace of new articles will pick up pretty soon, the [Developer Blog still needs you](https://developer.wordpress.org/news/2025/07/the-developer-blog-needs-you/)! Consider joining us and sharing your knowledge with the community. It can be a rewarding experience., What’s New for Developers?, Justin Tadlock, 01k2fchsq6cwd2fk5tvzph14wh.