Editor components updates in WordPress 7.1
🔗 **Source:** [Editor components updates in WordPress 7.1](https://make.wordpress.org/core/2026/07/23/editor-components-updates-in-wordpress-7-1/)
> [!note]+ Document Notes
> tags: [wordpress-7-1, gutenberg, wordpress-components, design-systems, plugin-development]
> author: WordPress Core contributors
> source: Make WordPress Core
> reference: https://make.wordpress.org/core/2026/07/23/editor-components-updates-in-wordpress-7-1/
> date created:
>
> # 🏷️ Title: Editor components updates in WordPress 7.1
>
<!-- deep-read:sections start -->
## 🧭 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-assessment)
- [✅ Logical Validity](#-logical-validity)
- [🛡️ DARVO Analysis](#-darvo-analysis)
- [🎯 Conclusion](#-conclusion)
- [🔄 Refactor Appendix](#-refactor-appendix--editor-components-updates-in-wordpress-71)
- [🧰 Template Library](#-template-library)
### 🔗 References
- [Editor components updates in WordPress 7.1](https://make.wordpress.org/core/2026/07/23/editor-components-updates-in-wordpress-7-1/)
- [40px component-size tracking issue](https://github.com/WordPress/gutenberg/issues/65751)
- [Emotion-to-SCSS tracking issue](https://github.com/WordPress/gutenberg/issues/66806)
- [Navigation removal](https://github.com/WordPress/gutenberg/pull/78529)
- [Experimental utility removal](https://github.com/WordPress/gutenberg/pull/78528)
## 📝 Summary
- WordPress 7.1 makes 40px the unconditional default height for a broad set of form controls. The former opt-in prop no longer changes runtime behavior.
- The components package starts moving Emotion-based styles to SCSS modules. Consumers that passed Emotion's `css` prop to `View` or relied on fragment order need to adjust.
- The deprecated `Navigation` component and `__experimentalApplyValueToSides` utility are removed after warnings that began in WordPress 6.8.
- Plugin, theme, and block developers are the main stakeholders. The key risk is silent visual or cascade changes in extensions that depended on old opt-outs or Emotion behavior.
- Bottom line: extension authors should remove obsolete props, replace `Navigation` with `Navigator`, and test component styling against WordPress 7.1.
## 📖 Main Content
- **Form-control sizing:** Affected controls now render at 40px. Passing `__next40pxDefaultSize`, including `false`, does nothing. A few controls also ignore their deprecated `size` prop. `Button` remains outside this change and still uses its own opt-in prop.
- **Styling migration:** `View` keeps the `css` prop only for type compatibility; it no longer applies styles. Use `style` or `className`. When Emotion fragments depend on source order, compose them within one `css()` call before combining classes with `cx()`.
- **API removals:** `Navigation` is gone in favor of `Navigator`. `__experimentalApplyValueToSides` is gone, while `BoxControl` remains available.
- **Release pattern:** The post shows staged compatibility work: early opt-in, console warnings, deprecation, then removal. That gives maintainers time to test while letting Core finish a design-system migration.
- **Uncertainty:** The post says the Emotion migration will expand, but it does not list every future component or a final completion release.
## 🗒️ Notes
- The 40px change covers many controls from `@wordpress/components` and four typography controls from `@wordpress/block-editor`.
- Removing `__next40pxDefaultSize={ false }` closes the escape hatch to the former 36px height.
- `Button` is an explicit exception, so automated cleanup must not remove its opt-in prop without checking current behavior.
- The `View` change can fail quietly because the prop remains accepted by types while doing nothing at runtime.
- CSS shorthand, longhand, and nested-selector order can change when separate Emotion fragments are passed through `cx()`.
- The removal schedule gives a concrete test case for whether deprecation warnings reach extension maintainers before code disappears.
## 📚 References
- [Make WordPress Core dev note](https://make.wordpress.org/core/2026/07/23/editor-components-updates-in-wordpress-7-1/)
- [Gutenberg issue 65751](https://github.com/WordPress/gutenberg/issues/65751)
- [Gutenberg issue 66806](https://github.com/WordPress/gutenberg/issues/66806)
- [Gutenberg PR 78529](https://github.com/WordPress/gutenberg/pull/78529)
- [Gutenberg PR 78528](https://github.com/WordPress/gutenberg/pull/78528)
## 🗣️ Paraphrase
- WordPress finishes the form-control sizing migration begun in 6.7 and 6.8. Developers no longer opt into 40px controls or opt back out to 36px.
- Core is replacing Emotion internals with SCSS modules. Most extensions should not notice, but code tied to Emotion's runtime or cascade behavior must move to ordinary styles and classes.
- Two APIs that carried deprecation warnings since 6.8 now disappear. Developers must use their documented replacements or remove obsolete calls.
- The post is a migration checklist, not a broad product announcement: search your extension code, update the named APIs, then test visual behavior.
## 📰 Newsletter
WordPress 7.1 finishes several component migrations that have been warning developers since 6.8. Form controls settle at 40px, `View` stops honoring Emotion's `css` prop, and the old `Navigation` component exits in favor of `Navigator`. The practical move is simple: search your plugin or theme for the named props and APIs, remove the dead paths, and run a visual regression pass. [Read the full dev note](https://make.wordpress.org/core/2026/07/23/editor-components-updates-in-wordpress-7-1/).
## ✅ Action Items
#### DevRel
- Publish a before-and-after migration guide and track extension questions by component.
- Run an office hour for plugin and theme developers with real code examples.
- Add copyable search commands for deprecated props and imports.
- Measure guide use through clicks, support questions, and resolved compatibility reports.
#### OSPO
- Add the removed APIs to internal WordPress dependency inventories.
- Confirm license and provenance records for copied component examples.
- Route compatibility findings upstream with reproducible cases.
- Track which maintained products still depend on Emotion-specific behavior.
#### Community
- Maintainers: test supported extensions on a WordPress 7.1 build.
- Contributors: submit focused documentation or migration fixes.
- Sponsors: fund compatibility testing and issue triage.
- Ecosystem: share breakage reports with exact component names and screenshots.
#### WordPress
- Core: keep removal notes tied to replacement guidance and release criteria.
- Core Performance: measure CSS payload and runtime effects from the SCSS migration.
- Core AI: ensure code assistants stop suggesting removed props and APIs.
- Core Program Team: track cross-package migration dependencies and unresolved dev-note gaps.
- Mobile: confirm shared component assumptions do not leak into app interfaces.
- Playground: publish a 7.1 compatibility sandbox for extension testing.
- Community: include the change in developer-focused WordCamp materials.
- Training: update component-development lessons.
- Marketing: avoid presenting internal migration work as a user-facing redesign.
- Support: prepare a short diagnostic for broken control sizing.
- Design: verify 40px controls across density, state, and layout cases.
- Documentation: update package references and migration examples.
- Photos: no direct action; verify contributor tools if they use affected controls.
- TV: caption and index any migration walkthrough.
- Polyglots: translate user-facing strings only; code identifiers stay unchanged.
- Accessibility: test target size, focus visibility, and zoom behavior.
- Meta: scan WordPress.org interfaces using the affected packages.
- CLI: consider a command or documented grep recipe for deprecated symbols.
- Hosting: add extension compatibility checks to 7.1 staging guidance.
- Tide: flag removed imports only when the scan can avoid false positives.
- Openverse: test any shared WordPress component surfaces.
- Themes: update theme-author guidance for component overrides.
- Plugins: alert authors whose code still contains removed symbols.
#### The WPOCC
- Fund a short compatibility clinic and publish the resulting migration examples.
- Support maintainers who need test coverage for component changes.
### FAIR
- Record component-version requirements in package metadata.
- Keep migration guidance portable across distribution channels.
- Publish decision records for compatibility policy and sunset timing.
## 🧪 Hypotheses
- Extensions that heeded WordPress 6.8 console warnings show fewer 7.1 regressions than extensions that did not.
- Removing Emotion from components reduces client-side styling overhead without increasing CSS conflicts.
- Keeping the `css` prop in types while making it a no-op causes more silent failures than a compile-time removal would.
- A machine-readable deprecation list reduces time-to-fix for plugin authors.
### 📊 Methodology
- Scan a representative plugin and theme sample for the named props, imports, and utilities.
- Run visual regression tests on WordPress 7.0 and 7.1 with matched content and viewports.
- Compare support tickets, console warnings, and fix times before and after release.
- Measure CSS size, style insertion time, and cascade differences for migrated components.
### ❓ Questions
- When will `Button` complete its 40px migration?
- Which components move from Emotion next, and how will authors receive notice?
- Should a no-op prop remain in types, or should types force migration?
- Can Core publish a structured deprecation feed for extension tooling?
### 🔮 Future Research
- Test whether staged deprecation warnings reach maintainers who do not run development builds.
- Compare source-order behavior across Emotion, SCSS modules, and mixed extension styles.
- Study whether automated codemods can remove the old sizing prop without touching the `Button` exception.
### 💡 Implications
- **Practice:** extension teams need code search plus visual testing, not code search alone.
- **Policy:** removals work best when warnings, replacements, and dates are easy to query.
- **Security:** no direct security change, though dead compatibility code can hide untested paths.
- **Education:** examples should teach the difference between accepted types and active runtime behavior.
- **Funding:** shared compatibility labs would reduce duplicate testing across small maintainers.
### 🧠 Learning Styles Assessment
- Reading level estimate: Flesch-Kincaid grade 11–13, based on technical vocabulary and long component lists.
#### 👀 Visual learners
- Present: code identifiers and one composition example.
- Improve: add before-and-after screenshots and a component matrix.
#### 🔊 Aural learners
- Present: not applicable; this is a text dev note.
- Improve: add a short narrated migration summary.
#### 🗣️ Verbal learners
- Present: direct replacement instructions.
- Improve: define Emotion, SCSS modules, cascade order, and no-op.
#### 🧩 Kinesthetic learners
- Present: actionable removal and replacement steps.
- Improve: provide a Playground lab with a deliberately broken extension.
#### 🧠 Logical learners
- Present: clear version sequence and API mapping.
- Improve: add a decision table for each deprecated symbol.
#### 🧑🤝🧑 Social learners
- Present: issue and pull-request links.
- Improve: add an office-hour prompt and peer testing checklist.
#### 🧘♀️ Solitary learners
- Present: enough detail for self-paced migration.
- Improve: add a self-check quiz and completion checklist.
#### 🌿 Naturalistic learners
- Present: not applicable; the source has no environmental frame.
- Improve: note any build-size or runtime-efficiency effects once measured.
### 📊 Accessibility Assessment
#### Screen reader semantics
- The source uses headings, lists, code, and links. Link labels made only of issue numbers need surrounding context.
#### Keyboard navigation
- The article is primarily static. Confirm code samples and tables do not create focus traps.
#### Contrast and readability
- Long identifier lists are dense. Use row grouping and sufficient code contrast.
#### Text resizing and reflow
- The side-by-side code table should reflow at 200% zoom without horizontal loss.
#### Media and captions
- Not applicable; no time-based media appears in the captured article.
#### Forms and interactions
- Not applicable; the article contains no forms beyond site navigation.
#### Standards reference
- Check WCAG 2.2 AA criteria 1.3.1, 1.4.10, 2.4.4, and 2.4.6.
### 🌍 DEIB Assessment
#### Cultural breadth
- The guidance is globally applicable but only in English.
#### Inclusive language
- The tone is neutral and role-focused.
#### Neurodiversity support
- Headings help scanning; the long component list raises cognitive load.
#### Representation
- No people or case studies are represented beyond contributor credit.
#### Psychological safety
- The post avoids blame and gives direct migration steps.
### ✅ Logical Validity
#### Strong reasoning
- The post uses a clear change-to-action pattern: it names behavior, scope, exception, and replacement.
- Version history supports the claim that maintainers received an opt-in and warning period before removal.
#### Fallacies
- No material fallacy is present. The claim that most consumers need no change would be stronger with compatibility-test data.
#### Tone of voice
- Precise, procedural, and restrained. The post distinguishes final behavior from exceptions and future work.
### 🛡️ DARVO Analysis
- Deny: not applicable; the source does not deny a reported harm.
- Attack: not applicable; it does not target critics or maintainers.
- Reverse victim/offender: not applicable; no conflict frame appears.
## 🎯 Conclusion
WordPress 7.1 completes several component migrations after a staged warning period. Developers should remove obsolete sizing props, replace `Navigation`, stop depending on `View`'s Emotion `css` behavior, and test the visual cascade. The main follow-up is a 7.1 compatibility run against maintained plugins, themes, and WordPress.org interfaces.
## 🔄 Refactor Appendix — Editor components updates in WordPress 7.1
### 📚 Literature Atoms
### [H1] Form controls adopt 40px unconditionally
> [!quote] ID:rw_1036798918
> Starting in WordPress 7.1, @wordpress/components form controls use a 40px default height unconditionally.
**Context & use**:
- Opening change summary.
- Use when tracking design-system defaults and extension compatibility.
**Tags**: #xref
**Highlight**: [view highlight](readwise://open/1036798918)
<!-- atomicity: 1 idea ✓ -->
### [H2] View stops applying Emotion css
> [!quote] ID:rw_1036798919
> View still accepts the legacy css prop for type compatibility, but it is now a no-op.
**Context & use**:
- Emotion migration section.
- Use when separating type compatibility from runtime compatibility.
**Tags**: #xref #articleseed
**Highlight**: [view highlight](readwise://open/1036798919)
<!-- atomicity: 1 idea ✓ -->
### [H3] Deprecation ends in API removal
> [!quote] ID:rw_1036798920
> The component has been deprecated since WordPress 6.8. Use the Navigator component instead.
**Context & use**:
- Navigation removal section.
- Use as a release-policy example of warning, replacement, and removal.
**Tags**: #xref
**Highlight**: [view highlight](readwise://open/1036798920)
<!-- atomicity: 1 idea ✓ -->
### 🧠 Permanent Candidates
#### [P1] Type compatibility does not guarantee runtime compatibility
**Claim**: An accepted prop can still be operationally dead.
**Evidence pointer**: [[#H2]]
**Scope & conditions**: Applies when libraries retain types during staged migrations; breaks when runtime and types are removed together.
**Links**:
- [[Deprecation policy]] — because extends staged API retirement.
- [[Visual regression testing]] — because applies-in component migrations.
- [[Compatibility contracts]] — because contrasts compile-time acceptance with runtime behavior.
<!-- atomicity: 1 idea ✓ -->
### ✏️ Fleeting Queue
- [F1] Check maintained WordPress extensions for the four removed or ignored symbols — source dev note #xref.
### → Things 3
- [ ] Run a 7.1 code search and visual test on maintained extensions — WordPress compatibility #things
<!-- deep-read:sections end -->
📄 **Full text:** [[Full Document Contents/Articles/Editor components updates in WordPress 7.1.md|Editor components updates in WordPress 7.1 by WordPress Core contributors]]
## Highlights
- Starting in WordPress 7.1, `@wordpress/components` form controls use a 40px default height unconditionally. The opt-in `__next40pxDefaultSize` prop is no longer needed and has no runtime effect when passed. ([View Highlight](https://read.readwise.io/read/01ky7rk8mnt4n1za04vpbdrf1d))
- Note: The 40px form-control migration becomes the unconditional default.
- Tags: wordpress-components, atom/literature/h1
- Starting in WordPress 7.1, the deprecated `Navigation` component and its subcomponents are removed from `@wordpress/components` ([#78529](https://github.com/WordPress/gutenberg/pull/78529)). ([View Highlight](https://read.readwise.io/read/01ky7rkax4avq0684et1baykxn))
- Note: A two-release deprecation window ends in removal.
- Tags: wordpress-components, atom/literature/h2