--- title: WordPress 7.1: What developers need to know | daily.dev description: WordPress 7.1 is scheduled to release on August 19, covering 310+ Core Trac tickets, 180+ bug fixes, and 100+ enhancements. Key developer-facing changes... canonical: https://daily.dev/posts/wordpress-7-1-what-developers-need-to-know-zzifbsubz twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: WordPress 7.1: What developers need to know | daily.dev og:description: WordPress 7.1 is scheduled to release on August 19, covering 310+ Core Trac tickets, 180+ bug fixes, and 100+ enhancements. Key developer-facing changes... og:url: https://daily.dev/posts/wordpress-7-1-what-developers-need-to-know-zzifbsubz og:image: https://api.daily.dev/og/posts/ZzifbsuBz.png og:image:alt: WordPress 7.1: What developers need to know og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # WordPress 7.1: What developers need to know **[Collections](https://daily.dev/sources/collections)** · 6 min read · 3 upvotes · 0 comments ## Summary WordPress 7.1 is scheduled to release on August 19, covering 310+ Core Trac tickets, 180+ bug fixes, and 100+ enhancements. Key developer-facing changes include: responsive block styles with configurable breakpoints via theme.json, pseudo and custom style states for Button and Navigation Link blocks, a new public SVG Icon API (wp_register_icon_collection/wp_get_icon), an expanded Abilities API with full execution lifecycle, the post editor now always running in an iframe regardless of theme type, new client-side media processing APIs, Design System CSS custom properties and ThemeProvider, and accessible tooltip components. Notable deprecations include @wordpress/nux (now a no-op shim), @wordpress/reusable-blocks APIs, and experimental functions cloneSanitizedBlock and sanitizeBlockAttributes. The Markdown parser in @wordpress/blocks switches from showdown to marked. React 19 is deferred again; WordPress 7.1 stays on React 18.3. ## Content WordPress 7.1 is on track for its final release on August 19, 2026, and by this point the release has gone through the full gauntlet: RC1, RC2, RC3, RC4, two mid-cycle security releases (7.0.2 and 7.0.3), and now an extended code freeze before General Release. Here's what's actually in it, and how the last stretch of the release process has played out. ## Where things stand right now The code freeze started Monday, August 17 at 2:00 PM UTC and runs through General Release on Wednesday. That's more buffer than usual, giving the release squad room to catch anything before it ships. If a critical bug turns up during this window, they'll decide whether it's bad enough to block the release — which means another RC and restarting the dry run — or whether it can wait for 7.1.1. RC1 was the hard string freeze: no new strings allowed after that point, and translations don't show up until the 7.1 branch gets cut. Until the branch exists, every commit to trunk needs sign-off from two core committers, and only regression fixes or test suite additions are allowed on the milestone. Once the branch is created, trunk opens back up for 7.2-alpha work.­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­ RC3 shipped more than 90 fixes since RC1 (37 in the editor, 57 in core). RC4 added another 26 or so, split across editor and core again. You can test via the Beta Tester plugin, a direct download, or WP-CLI: ``` wp core update --version=7.1-RC4 ``` If you maintain a plugin or theme, now's the time to update your "Tested up to" version and flag any compatibility issues before they become launch-day surprises. The release party itself has two parts: a Slack walkthrough and a live stream from WordCamp US in Phoenix, where 7.1 gets published to the world. The community's also been asked to test .zip packages across different server setups — IIS, older PHP/MySQL combos, fresh installs, upgrades, multisite — plus basic flows like publishing a post or installing a plugin. The boring stuff matters most here. ## The big developer-facing changes The Field Guide covers 310+ Core Trac tickets, 180+ bug fixes, and 100+ enhancements, so I won't try to list everything. But a few things stand out. **Responsive block styles.** This is probably the headline feature. You can now define Tablet and Mobile-specific styles for blocks — typography, color, background, border, spacing, layout — either globally through Global Styles or per block instance. WordPress generates media-query-scoped CSS on the frontend with stable class names. Default breakpoints are 480px (mobile) and 782px (tablet), but both are configurable via a new `settings.viewport` setting using px, em, or rem. In theme.json, you'll set these using `@mobile` and `@tablet` keys. If you'd rather not deal with any of this, there's a `responsiveEditingEnabled` setting to turn it off entirely — existing saved responsive styles will still render fine either way.­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­ Right alongside that: pseudo and custom state styling. The Button and Navigation Link blocks now support hover, focus, focus-visible, and active states, configurable through theme.json, Global Styles, or block instance attributes. There's also a new custom states system for theming special conditions — like styling the current menu item in a navigation link — using a dash-prefixed convention in theme.json. Same deal as responsive styles: a `blockStatesEditingEnabled` setting lets site owners turn off user-facing state editing without breaking anything already saved. **SVG Icon API.** Now public, with `wp_register_icon_collection()` and `wp_get_icon()`. Useful if you've been hand-rolling icon systems in your plugins. **The editor is always iframed now.** Regardless of theme type, the post editor runs inside an iframe. There's also a persistent admin toolbar and a jQuery UI bump to 1.14.2. **Abilities API grows up.** It now has a full execution lifecycle, custom validation, and a discovery pipeline — a meaningful step past what shipped in earlier releases. **Design System theming.** New CSS custom properties and a ThemeProvider component for branding admin UI. Also worth noting: `__next40pxDefaultSize` is now a no-op. Form controls just render at 40px regardless of what you pass — one less prop to think about. **What got punted.** React 19 didn't make it in — WordPress 7.1 stays on React 18.3. Real-time collaborative editing is also deferred, as is hiding the Classic block from the inserter. None of these are surprising; they've been circling for a while. **Playground gets more capable.** A new multi-site interface and a programmatic Site Manager API landed this cycle too. ## Smaller editor changes worth knowing about A handful of changes that won't make headlines but will bite you if you're not expecting them: - The Navigation block no longer propagates font-size down to child items, fixing some annoying CSS compounding bugs. If you relied on the old behavior, there's a PHP filter to restore it. - `cloneSanitizedBlock` and `sanitizeBlockAttributes` are deprecated in favor of their stable equivalents. - The Markdown parser in `@wordpress/blocks` switches from showdown to marked, now following CommonMark/GFM specs. Expect minor parsing differences if you had markdown content relying on showdown's quirks. - Paragraph blocks now support mobile multi-selection, with editing event handlers moved to the canvas element. - A new `disableContentOnlyForTemplateParts` setting lets themes opt out of content-only editing for Template Parts. - Block-level preset CSS classes now use `:where()` for specificity, which should fix some annoying responsive state conflicts people have been hitting. - `getEntityRecords()` had a pagination bug where non-paginated entities weren't returning full collections — that's fixed. - `@wordpress/nux` is now just a no-op compatibility shim, and `@wordpress/reusable-blocks` APIs will start logging deprecation warnings. ## Accessibility work — and one regression to know about This cycle shipped 45 core and 43 editor accessibility fixes, including a standardized tooltip API for accessible names, better screen reader labeling across admin screens, list tables, and media modals, and improved Windows High Contrast Mode support. Two new blocks — Tabs and Playlist — were built with accessibility as a starting point rather than an afterthought.­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­ But there's one deliberate step backward worth flagging: the Media Library's default behavior is changing from a load-more button to infinite scroll. This is a known problem for screen reader and keyboard users — infinite scroll is a pattern accessibility advocates have been warning about for years. To the team's credit, they've documented this clearly rather than burying it. There's a per-user opt-out in the User Profile screen, and site owners can disable it globally through the `media_library_infinite_scrolling` filter, or by using the WP Accessibility plugin, which flips the default back to load-more. It's a strange trade-off to see land in the same release that's otherwise stacked with accessibility fixes, but at least the escape hatches exist for anyone who needs them. ## Bottom line If you build themes or plugins, the responsive block styles and pseudo-state system are the two changes that'll actually affect your day-to-day work — budget time to test against them. Everyone else should mostly notice a snappier, more consistent editor, plus the infinite-scroll change in Media Library, which is worth disabling if accessibility matters for your site's admin users. Final release lands August 19, live from WordCamp US in Phoenix. ## Questions this post answers ### What are the default breakpoints for responsive block styles in WordPress 7.1 and can I change them? WordPress 7.1 sets default breakpoints at 480px for mobile and 782px for tablet. Both are configurable in theme.json via a top-level settings.viewport key, accepting px, em, or rem units. In theme.json and Global Styles, responsive values use @mobile and @tablet keys. Responsive editing can be disabled entirely with the responsiveEditingEnabled editor setting. _WordPress theme developers tracking breakpoint configuration changes keep up with releases like this on daily.dev._ ### Is the post editor always iframed in WordPress 7.1 for classic themes? Yes, the post editor runs in an iframe unconditionally in WordPress 7.1, regardless of theme type. The enforceIframe setting is no longer optional — classic themes now get the same iframe-based editor as block themes. Additionally, the __next40pxDefaultSize prop is now a no-op; form controls render at 40px unconditionally. _Plugin developers adapting to the WordPress editor iframe change can follow the full rollout on daily.dev._ ### What Markdown parser does @wordpress/blocks use in WordPress 7.1? @wordpress/blocks switches from showdown to marked in WordPress 7.1, following CommonMark and GFM specifications. Developers doing custom Markdown handling inside blocks should check for behavioral differences between the two parsers, as the spec compliance may produce different output for edge-case Markdown syntax. _Developers maintaining WordPress block plugins that process Markdown should watch for compatibility issues — daily.dev surfaces these kinds of ecosystem shifts as they land._ ## Similar posts on daily.dev - [What’s new for developers \(July 2026\)](https://daily.dev/posts/what-s-new-for-developers-july-2026--1fusc413s) · WordPress Developer · 10 upvotes · 0 comments --- Tags: [#javascript](https://daily.dev/tags/javascript), [#php](https://daily.dev/tags/php), [#wordpress](https://daily.dev/tags/wordpress) [View this post on daily.dev](https://daily.dev/posts/wordpress-7-1-what-developers-need-to-know-zzifbsubz) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"WordPress 7.1: What developers need to know","url":"https://daily.dev/posts/wordpress-7-1-what-developers-need-to-know-zzifbsubz","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/wordpress-7-1-what-developers-need-to-know-zzifbsubz"},"datePublished":"2026-08-10T21:20:58.614Z","dateModified":"2026-08-17T17:36:13.658Z","description":"WordPress 7.1 is scheduled to release on August 19, covering 310+ Core Trac tickets, 180+ bug fixes, and 100+ enhancements. Key developer-facing changes...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/86aabe2f8dfa787d80ad8334526fbcc8?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/86aabe2f8dfa787d80ad8334526fbcc8?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Collections","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Collections","logo":"https://media.daily.dev/image/upload/s--fk_6ycEi--/f_auto,q_auto/v1780996001/logos/collections?_a=BAMAMiWQ0","url":"https://daily.dev/sources/collections"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/wordpress-7-1-what-developers-need-to-know-zzifbsubz","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":3},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"javascript,php,wordpress","timeRequired":"PT6M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Collections","item":"https://daily.dev/sources/collections"},{"@type":"ListItem","position":3,"name":"WordPress 7.1: What developers need to know"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/wordpress-7-1-what-developers-need-to-know-zzifbsubz#faq","mainEntity":[{"@type":"Question","name":"What are the default breakpoints for responsive block styles in WordPress 7.1 and can I change them?","acceptedAnswer":{"@type":"Answer","text":"WordPress 7.1 sets default breakpoints at 480px for mobile and 782px for tablet. Both are configurable in theme.json via a top-level settings.viewport key, accepting px, em, or rem units. In theme.json and Global Styles, responsive values use @mobile and @tablet keys. Responsive editing can be disabled entirely with the responsiveEditingEnabled editor setting. WordPress theme developers tracking breakpoint configuration changes keep up with releases like this on daily.dev."}},{"@type":"Question","name":"Is the post editor always iframed in WordPress 7.1 for classic themes?","acceptedAnswer":{"@type":"Answer","text":"Yes, the post editor runs in an iframe unconditionally in WordPress 7.1, regardless of theme type. The enforceIframe setting is no longer optional — classic themes now get the same iframe-based editor as block themes. Additionally, the __next40pxDefaultSize prop is now a no-op; form controls render at 40px unconditionally. Plugin developers adapting to the WordPress editor iframe change can follow the full rollout on daily.dev."}},{"@type":"Question","name":"What Markdown parser does @wordpress/blocks use in WordPress 7.1?","acceptedAnswer":{"@type":"Answer","text":"@wordpress/blocks switches from showdown to marked in WordPress 7.1, following CommonMark and GFM specifications. Developers doing custom Markdown handling inside blocks should check for behavioral differences between the two parsers, as the spec compliance may produce different output for edge-case Markdown syntax. Developers maintaining WordPress block plugins that process Markdown should watch for compatibility issues — daily.dev surfaces these kinds of ecosystem shifts as they land."}}]} ```