This focuses on decisions made after the roadmap was shipped through to release day, listed from oldest to newest, with reasons listed below. I used AI to help compile this list from a combination of the #7-1-release-leads Slack, AI briefings I tried to get to work (it was a bust), and GitHub/trac activity. I’ll likely update this as I remember more items but, for now, these were the bigger decisions that had to be made.

Jun 19 — Ship the 7.1 roadmap.

• Beta 1 was less than 3.5 weeks away, and continuing to tinker with every detail had diminishing returns.
• The roadmap had already been through many iterations with squad feedback, and anything wrong could still be corrected after publishing.
• Decision: ship Roadmap to 7.1.

Jun 19 — Create a separate #7-1-design-assets channel for design work

• Design asset work (highlight grid, video featurettes, microsite) spans many avenues and would create noise in the main release channel, so I kept important release conversations in #7-1-release-leads while letting anyone join the design coordination as they liked.
• This was the first time we ever did release asset in a dedicated public channel. Usually this work ends up on GitHub issues, figma files, and in various calls or DM when we review.
• My hope in making it public is that we could get more perspectives and folks could see how much goes into the assets themselves.

~June 25 — shared a design direction for “Apply globally” with granularity

• After meeting with Aaron, a Gutenberg contributor, in person to talk through some of the 7.1 items when we had happened to be in the same place, I worked on navigating some design decisions.
• I opened gutenberg#79719 to test replacing the per-control “push to Global Styles” action with a granular review modal, in response to feedback that a per-control push felt risky by default.
• Aaron split the individual-style-pushing work into its own PR, gutenberg#79839, building on a DataViews-based approach suggested in gutenberg#49278 (comment). He then saw this through!

Takeaway: this is a great way for release leads to help make decisions while still ensuring the code is up to snuff.

July 4 — Dialog and Marquee punted

• Not enough contributions and progress made for two easy decisions to punt the feature from the release.

~Jul 7 — Land the “Posts list: excerpt in Compact view” work as-is

• The design had gone through repeated back-and-forth with no resolution.
• I decided it was better to land what existed and adjust based on real feedback than keep debating it.

Jul 7 — Classic block stays in the inserter for 7.1 exactly as today

One of the takeaways is that the Classic block should become obsolete by choice, not by force. I believe time will be better spent to make the alternative genuinely better, while also smoothly, losslessly migrating content, so that users move off Classic block because they want to, not because the door has been removed.

From “The Classic block stays in the inserter for WordPress 7.1“

• The plan to hide the Classic block from the inserter was reverted, and the wp_classic_block_supports_inserter filter and its deprecation notice were removed.
• There’s a full announcement with details about why it was punted already shared.

~Jul 8 — Punt real-time collaboration (RTC) entirely from 7.1

• Scope and transport decisions were unresolved with feature freeze approaching, so a clean deferral was safer.
• This required talking with a large number of contributors to understand where we were, alongside talking with Matt himself. Beyond that, my leaning towards punting came from my own testing and understanding of our options.
• I confirmed this directly with Matt and announced it publicly on Jul 8. I tried to make this decision as early as possible to ensure we could focus on more realistic items to land.

~Jul 8–13 — no on the Knowledge merge proposal, no on AI Client streaming and embeddings

• Matt gave the Knowledge merge proposal a no, and I closed the loop with a public summary of the outcome. Merge Proposal: Expanding WordPress Core Abilities is the related public proposal thread.
• The main reason for the “no” is that the priority for Matt for AI work is around working on evals and benchmarking all the model makers use and target. This ties directly into WP Bench work. He also made it clear that he doesn’t want to put things into Core that aren’t already driven by real-world adoption with impressive week to week growth (think: double digits).
• php-ai-client streaming did not make 7.1, and the WordPress/ai embeddings PR #683 was punted after landing too late.

~Jul 10–14 — Bless a limited list of items for the beta period, scope Notes down, and punt suggestion mode to 7.2

• I pulled together a list of Blessed items to confirm with the release squad: Notes features, displaying inherited styles, and a handful of small revisions enhancements, all close to landing with buy-in from their feature owners. I reconfirmed this list unchanged on Jul 14.
• Confirmed the notes scope, including punting suggestions after a big refactor: @mentions, rich text, and @mention notifications, with emoji reactions, floating notes, and minified mode targeted at Beta 2.
  • Suggestion mode was excluded and punted to 7.2 because a recent major refactor made it too experimental and under-tested.

~Jul 14 — Punt the Abilities API follow-ups from 7.1

• I punted the Abilities API proposal, partially in light of the direction from Matt previously around AI features.

~Jul 14 — Punt the Table of Contents block from 7.1

• Aki handled this after no contributions moved this block forward.

~Jul 20 — Punt Unicode email address support to a community plugin

• Matt made this call on the proposal itself citing too vast of a surface area for security issues and added complexity, when we have more pressing problems to solve.

~Jul 23 — Defer the React 19 upgrade from Core 7.1

React 19 upgrade won’t be a part of WordPress 7.1. After briefly enabling it in Gutenberg we discovered unexpected incompatibilities in how old and new version of React interact with each other, and in the ways how plugins use React, and we were forced to revert the change.

From “React 19: punted beyond WordPress 7.1, experiment in Gutenberg“

• This decision was made by those who contributed to it and the work continues in the Gutenberg plugin. (#71336)

Jul 28 — Add a way to disable responsive styling, but don’t remove the feature

• Enterprise theme maintainers raised support-burden concerns in dev chat and asked for a pause or an opt-out.
• My call: “A way to disable is fine. I don’t think fully disabling it makes sense.” A full removal was disproportionate to the impact and desire for this feature. Aki built the disable mechanism, targeting RC1 at the latest.
• A way to opt out likely should have been done from the beginning as this is a common request in WordPress, even when a feature is long awaited.

~Jul 31–Aug 3 — Punt “displaying inherited styles”

• Disagreement persisted right up to Beta 4 and there just wasn’t a solid design direction we could land with enough time for proper user feedback.
• This followed the same conservative-scoping principle as the earlier calls when punting, and I wrote a retrospective on it so the squad could learn from the situation.
• This was another example where I tried to unblock things as the release lead by sharing various possible approaches to get consensus but, sadly, none of them ended up working out.

Aug 3 — Punt the “On this day” widget

• Outcome of my 7.1 review call with Matt: he didn’t think it was good enough and wanted it removed.
• I passed along the broader principle to the squad: what we don’t add is sometimes more valuable than what we do.

Aug 6 — Move forward with auto-approve self pingbacks

• After getting a late request from Matt, auto-approved self ping backs landed.
• I discussed the surface area of this change with a number of contributors and agreed that this would be safe to make an exception for this close to the release due to the limited impact and small amount of code.

~Aug 14 — Revert the toolbar focus/hover style change rather than ship it in 7.1

• Trac #65849 started as a report that clicking a toolbar item showed a focus outline that felt distracting. A fix matched the toolbar’s hover state to its focus state, which then drew pushback from several designers who argued it collapsed hover, focus, and “current page” into one confusing signal and introduced visible regressions in plugins like Yoast.
• Once the debate had run for several days without agreement, I made the call in comment:33: “My concern is the :hover rendering and the resulting visual changes in [63190], backported in [63201]. That landed on August 11 and I don’t want it to ship in 7.1.” I sent the improvement of the focus indicator itself to 7.2 (#65445, #65878) rather than trying to resolve the design disagreement days before release.
• The full toolbar focus/hover change was reverted in r63306, backported to the 7.1 branch in r63318, restoring the WordPress 7.0 appearance.

Aug 19 (release day) — Skip the live on-stage release at WCUS and publish the announcement post directly

The original plan was for Matt to accept the proclamation, do the release with slides and the highlight video ready, then start his session. As it turned out, Robert hadn’t seen the slides beforehand, and neither had I. A commit triggered auto-updates early, around 1:30pm MT, when only limited availability was intended (release visible via Downloads > Releases and wp-cli only). By the time I came out on stage, roughly 300K sites had already updated, and a WP Rocket fatal was already being reported and flagged in the release squad channel. Backstage, word came that Matt “doesn’t want to do the button,” which was ambiguous between not wanting to press the button himself and not wanting to do the release on stage at all. The real-time discussion with the release squad starts here.

I made the decision to publish, in this order of importance:

1. Matt clearly said no to the button, even if it was just for himself, and I didn’t want to push against that or make him repeat himself in the middle of a big task.
2. Auto-updates had been running for about three hours, so word was already out regardless of what happened on stage and I worried about the confusion that would happen if we didn’t proceed.
3. The original timeline, releasing right after the proclamation, was gone, and I had no way to know how long it would be until the release could happen.
4. Matt’s presentation didn’t seem related to the release as it went on, and I had no way to check what else it might cover.
5. I had no way to communicate with Matt to follow up or clarify in the moment since he was on stage.
6. All of this was happening at a rough time for APAC squad members, and I didn’t want to prolong things when all signs pointed to the release not happening on stage.
7. The presentation was already running 20 to 25 minutes late, and it seemed likely we would run out of time.

I explicitly owned the call: “I will own this decision if it ends up being wrong later.” I was eventually called on stage about 50 minutes after the original time. Lessons for next time: a new handbook page for running releases live at in-person events, and a triple-check or full run-through backstage before going on.

Testing in real environments matters a ton. It’s part of why this site is running the latest and greatest as are some of the other sites I run. You simply run into different bugs and points of confusion when you’re in the flow of using a product over doing artificial testing. At the same time, since I already have a number of real sites using the latest from 7.1, I wanted to also test scenarios I might not otherwise run into, like 100 revisions in a post or 3+ posts published in the same day appearing in the now punted “On this day” widget. Here’s a list of everything I ended up creating with studio with some bonus additional items I forgot to include:

• Create a plugin that registers icons into a collection as part of the updates to the Icon block.
• Mass import my photos from the photo directory to test the media library’s infinite scroll.
• Create a post with 100 revisions to test revision improvements.
• Create posts without titles to test excerpts displaying instead of just (no title).
• Create 5 posts that were written on today’s date to test the “On this day” widget.
• Create a post with attached images to test the ability to use attached images in a gallery block and insert them from a dedicated section in the Inserter.
• Mass generate comments with varying nesting levels to test re-parenting a comment.
• Mass generate Notes on a post to test @ mentions, in line notes, and rich text (not featured in the video below).

The possibilities are endless and this saved me loads of time! Time that I would have spent just setting up scenarios instead was spent truly testing. If you’re a nerd like me and want to help test, here’s a playground made from the above created WordPress studio site where AI did all the heavy lifting:

Happy testing!

Ultimately, this morning, the decision was made to punt the feature (link to the conversation in the release leads channel and a link to the GitHub thread). Here’s a re-share of part of what I said there: I’ll speak plainly and say that I am so frustrated we couldn’t get this in a better spot (not at anyone in particular, just at the reality of the situation). I really, really want our users to benefit from this landing. At the root of the reason why it didn’t land are a few things: lack of a solid design approach, lack of robust exposure and feedback from users due to it not landing soon enough, and lack of agreement on a way forward. What we did not lack is a willingness to try and experiment. Even if we have a strong idea that this would help users and are centering that, I would rather have more assurance it genuinely is helping in a way that makes sense. Similar to some extra Notes features, I hope to see this land in Gutenberg soon, perhaps first as an experiment to be extra safe. We can do a call for testing and get more direct feedback too.

With the above in mind, I wanted to preserve part of the journey of this feature partially to get any early feedback and partially to have a snapshot of the problems and solutions explored across a range of PRs.

About the feature

Since I ran the FSE Outreach Program back in the early days of the Site Editor, I heard feedback that folks couldn’t understand the hierarchy of styles. In some cases, I’d watch user testing where folks would style a template thinking it would automatically apply everywhere. In other cases, I’d watch people pick a style variation and then open block settings for an individual block in a template only to be confused not to find those styling options reflected in the sidebar. This longstanding problem has been something I’ve passionately wanted to see fixed for a long time.

At a high level, for this release, the full spectrum of the desired feature is to allow folks to see inherited styles reflected in the block settings, identify where they come from via breadcrumbs, override any inherited options, reset them back to inherited options when needed, and push any local overrides globally. This last aspect was actually split out into it’s own PR and approach here using a different approach separate from the overall feature for a simpler design, allowing it to land. The other aspects are what the rest of this post will focus on.

Evolution

Below is a look at an early version of what was developed with me talking through the default state and two options to show inherited styles: a blue dot and a diamond approach.

There are numerous issues with the above designs:

• The feeling of clutter/noise in the interface greatly increases.
• Debates over what’s better accessibility wise, a tooltip or infotip.
• Needing to make big exceptions to the overall design system per this comment.
• Severe layout constraints, considering the small space.
• The underline not clearly indicating a globally inherited value and not being very visible.
• Accessibility and design system concerns with the hover option also acting as a reset mechanism.

After beta 1, the problem then arose that a number of folks were on vacation this time of year or out for various reasons, hampering our ability to come together with enough perspectives. I noted this here as a risk. To keep working moving, I proposed two different possible ways forward:

Diamond with the ability to reset to inherited style

This option shows no indication of something inherited globally but it just reflects the styles you see in the canvas. If you override an inherited setting then a diamond appears to indicate an override (this should be a filled in diamond, sorry!). When you hover over it, you see an option to reset to the inherited styles. This reduces visual noise by not showing an inherited style while still allowing folks to see when they have an override and to reset to global.

Diamond with only a tooltip

This option also shows no indication of something inherited globally but it just reflects the styles you see in the canvas. If you override an inherited setting then a diamond appears to indicate an override. When you hover over it though, you ONLY see an indication that this local change is overriding global styles (copy is rough on this tooltip). To reset, you rely on the tools panel which we know is accessible and is a current known pathway. This is a more scoped down version of the former item in that it only shows a tooltip but without any ability to reset since that already exists in the tools panel.

This last option is what was then pursued in this AI generated PR from yours truly after being taken over by devs. This was possible to generate with AI thanks to the hard work to have a sound and robust technical approach by Aaron Robertshaw.

Exploring infotips rather than tooltips

During this PR, we went back and forth around tooltips vs infotips. Tooltips eventually won out but here’s a view of what the infotip component approach looked like:

Confusion around the reset method

Separately, within the comments of this PR, I noted a big drawback to losing the reset option baked into the same inheritance indication and shared the following video. Put simply, there are two different options to reset the values and it’s not clear why they are different:

This then led to, in some cases, a reset option being added separately to the controls as shown in this comment to help ease some of the confusion there for some of the options.

Adding back in breadcrumbs

Finally, after it felt like we were making headway with the above approach, I explored adding back in breadcrumbs to show where style options were inherited. This was built using AI and was made easy to do thanks to prior work by Aaron Robertshaw once more.

Lessons learned

Here’s what I learned in the process:

• Never lose sight of the overall user problem. Let that guide you to scope back solutions.
• Use AI once the foundation is built to explore many different options. Having clear visuals (even just videos) for folks to react to kept the conversation and ideas flowing.
• Land and debate pieces of work, while not losing sight of the spectrum of the feature set. This often helps find a way forward.
• Knowing a user problem deeply doesn’t replace user feedback on the solution at hand.
• Summer break in certain parts of the world at this time of the year is a real factor in planning for releases and needs to be considered.
• There are many considerations from performance to accessibility to design systems to navigate all at once. Seek those perspectives out and let them sharpen your approach.

Ultimately, I think this was the right call but it was extremely painful to make. On a personal level, I couldn’t shake not liking the diamonds in the interface nor how cluttered it looked so I’m excited to have more time to iterate, make it undeniably awesome, and land it hopefully for 7.2.

“In this world of numbness and information overload, the ability to feel, my boy, is a rare gift indeed.”

Patrick Ness

Ironically, I’ve been so deep in the release that I haven’t been able to share a recent short documentary I was interviewed for about open source. It was terrifying to be interviewed–I cried during parts and found myself deeply appreciative of the questions asked. I stumbled into open source. When I joined Automattic in 2014, I didn’t have a full appreciation or understanding, beyond knowing it was in our creed. Once I started to wrap my head around it, I couldn’t go back. I couldn’t unsee or stop knowing. Suddenly, I started to see all around me just how powerful of a concept it really is and how much is missed by not embracing a more open world. My hope in sharing the documentary below is that folks will watch it in order to get a better sense of why open source matters. Like everything, it’s not perfectly good nor perfectly bad but it does feel like a better way. I also still feel like I’m only scratching the surface of open source. It’s a similar feeling I get when talking to a queer elder who fought to have rights that I sometimes take for granted today.

I feel like I have endless things to say but that’s why tomorrow exists.

In many ways, this feels like a return to what I was doing 9-10 months ago with AI and it feels… right. I’m sure I’ll still contribute PRs here and there but it feels important to think about how best I can sustainably contribute in a way that’s best for the project. For this release cycle and my role in it, this has felt like the best use of time for all involved.

With that in mind, I wanted to share a few examples of what that collaboration has looked like, mainly to serve as inspiration after meeting with the recent AI Leaders graduates this week in Chicago. Bear with me as this is going to be deeply nerdy and detailed–happy to explain anything in the comments below. I am also going to skip over all of the wonderful contributions from everyone on the threads. Please go look into them! I mainly want to focus on how I’m approaching this to show how others might think to contribute.

Process

My process is very simple. I’m using Claude both in terminal and in CraftAgents to work with the PR locally. I make it clear that I am just wanting to work locally and I have no intentions of pushing any updates to it or creating a PR. I previously set up a dev environment so, if you haven’t done that, ask Claude to do it for you and point it at documentation, like wp-env.

Applying changes globally

One of the features for 7.1 shows inherited styles so it’s easy to see when a global setting is impacting the part of your site you’re working on. As part of being able to override those styles, an option was added to push an individual change to a block to the entire site. For example, you could change the font size of a paragraph and push just that font size change to all paragraphs on your site. The approach in progress showed two options every single time you made a local change to a block:

This means that every single time you make a local change and you go to reset it to the global option, you’d be presented with an option to also push the styles globally, separate from the overall “apply globally” option available under Advanced in block settings. In testing the PR, I couldn’t shake that this felt off and initially flagged it for design in this follow up comment. More time passed though and I kept thinking about it before deciding to try something different out that you’ll see below.

Design later reviewed it, said it looked good, and the dev working on the feature is in the process of adjusting the approach. Mind you there are loads of details to work out but this just saved likely hours of back and forth as well as waiting for design to review when I had an idea in mind that just might work.

Surface attached images in Inserter

Despite the concept of attached images existing for a long time, there hasn’t been an easy way to find them from the Inserter. To zoom out, adding seeing attached images is meant to help with two main flows: allow folks see what images are attached to a post and prioritize those for ease & allow folks to attach images to a post for use in the post itself (more newsroom style flow where someone uploads from a media library for someone else to then use that image in content). 7.1 has a dedicated area of work to improve this and a discussion broke out around how best to approach it. Here’s what the initial PR was looking like:

When I first saw this, the attached images section immediately overwhelmed everything else, including seeing the button for the broader media library. At the same time, there are real concerns that most folks may not quite understand the terminology. To try to address this, I offered an alternative UX approach using AI that simplifies things (and makes the images themselves bigger and easier to review): it takes the same approach the other options uses and just adds at the top an “attached images” option. See below:

You’ll notice there’s some jankiness but that’s by design. I’m not trying to have a code ready PR. I’m trying to communicate a way forward and this was a very fast way to do so. Amazingly, the same developer working on this feature already had a PR in that direction and this discussion helped us move towards it.

New image cropper

A call for testing went out for Media Editor Modal: call for testing that adds a free-form image cropper in the Block Editor along with other goodies. I regularly use our image tools to manage my photos so I am keen to see this land and to have it land in a way that feels delightful to use. In testing this out, I found myself again wanting to communicate not just in words what I want to see but in code. I left a comment and shared some still images (after I struggled to get this video to upload to Cloudup) of what I thought might work:

This has evolved so much since this comment over a month ago and I highly recommend folks go check it out/try it out.

What a good reminder to be careful for the full length of something. What a good reminder to be grateful for undo buttons, auto-saves, revision history. I spend so much time in a headspace where things can be fixed and iterated upon that I can feel the ways it bleeds into my carving. When you know something can be fixed later, it inherently changes you, even if there are very real consequences to needing to fix something. I wrote about a part of this four years ago: how great it feels to have to be at attention with something and how much I seek those habits out.

How would I be different if I were in a less forgiving area of work, like if I were the surgeon that operated on me? How would that shape how I live my life, what hobbies I seek out, how I treat others? In many ways, I can already be so rigid and more on the anxious side that it’s probably been a positive for me to work in a world with more room for gray, for trying and failing, and for seeing one’s work through the lens of relentless iteration. Growing up playing soccer, I had a coach yell at me about how after I missed a shot, I put my head down directly distracting me from the game unfolding before me. He taught me a valuable lesson in taking failure head on without blinking and being ready for the next moment after when things could change. I still struggle not to take myself out of the game when things go wrong and I still think about his words. This is also likely why I don’t enjoy golf which suffers from higher consequences when you miss than soccer. I feel the ways I need hobbies like wood carving to stretch me to pay attention differently.

I am also just frustrated with myself for creating yet another hole in yet another spoon. This is at least the second if not the third spoon I’ve done this to in the last year. While I end up giving the spoons away, my minimalist self laments the wasted wood and wasted effort. Why didn’t I pay more attention? What do I need to do differently? I thought I was slowing down, taking my gloves off often enough to really feel the wood and understand where more work was needed. If I’m doing this repeatedly with a physical object, what other holes am I creating elsewhere in my life without realizing? Not everything will be so apparent, especially if others are unwilling or unable to voice it to me and hold the mirror up.

Time to get back to it and not remove myself from the game for too long. Wish me luck. Perhaps the part of me that keeps trying after so many holes is the real part to nurture.

While I never got a proper shot of the sunset, I captured the moment and the feeling better this way–the feeling of bumping into bodies, the jostling to get the best view, and the futility of trying to bottle up nature. I stood back and watched the sky melt.

1. Draft Sweeper 
   surfaces one of your abandoned drafts worth picking back up, ranked by what you’ve asked it to prioritize: completeness, recency, theme, all three, or custom weighting.
2. Future Drafts 
   lets you write a draft to your future self with a return date, so you’ll see it again when you said you’d want to.
3. Ideas Inbox 
   captures ideas the moment they hit and lets you convert any of them into a draft with a single click. This prevents an ideas list from being separate from where you write.
4. Habit Creator 
   watches your post archive for recurring patterns (topics, tags, seasonal rhythms) and nudges you toward the next installment in a thread you’ve already started building.

The name Underway is meant to invoke feelings of work in progress and momentum as drafts and ideas are always just right there to form into something. It won’t be submitted to the plugin directory just yet as I don’t want to submit something I can’t reasonably commit to maintaining.

Playground & Demo

Below is a demo of the plugin in use on a local test site and on an actual site I run (surrogacy-stories.com) to show it in action and to show empty state for new users.

For those who want to play around with the plugin themselves, check out the following playground setup:

AI usage principles

Throughout this process, we slowly landed on the following principles with AI based on our own experience of using AI and not wanting to use it for writing. This was intentionally an opinionated stance on AI grounded in a writer’s perspective.

• Clearly disclose how AI is used and what it does.
• Offer an easy, clear option to turn on and off.
• No AI slop or promotion of AI slop. This means no draft creation.
• Natural integration with WordPress, including what comes next like connectors, grid work, and guidelines where applicable.
• Widgets need to work well without AI and shouldn’t add AI unless it genuinely enhances the experience.
• AI functionality respects token usage and is conservative in usage/encourages conservative action.

The above informed the various design decisions reflected.

How we got here

After going wild with widgets to create a dream dashboard that makes you want to wake up and check WordPress, we explored a range of widgets. We dropped bundling two into Underway for the final push due to the setup being a pita for most people: Strava Stories and Jot. Strava Stories surfaces your latest activity with a quick option to create a draft with what you shared on Strava. Jot offers ideas for what to write about based on what you’ve been sharing and doing on connected apps (ToDoist, GitHub, Strava, etc). Both of these required an annoying amount of setup due to needing oauth. While they work, they don’t feel as ready to bundle and share.

Give feedback

If anyone wants to try it out and give feedback (be critical!), you are welcome to open issues here and just respond to this post.

I am not going to launch this as I don’t believe in launching dead ends and I don’t think I can reasonably maintain this nor do I think it’s likely the best code. I wouldn’t take much from this beyond me scratching an itch and feeling my way through our curation tooling!

Demo

Quick details

As much as possible, I relied on built in defaults and followed the curating the editor experience guide. Switching levels is non-destructive so you can move up and down at any time from the bottom right switcher, and if you have unsaved changes you’ll get a “Save before switching?” prompt before the editor reloads into the new level. If someone isn’t wanting to have changes immediately go live, this creates a bit of a tricky scenario if they need to switch a level to do something more advanced. This pain point touches on a known one in Core I opened five years ago.

I imagine using this plugin in conjunction with creating specific locked patterns, including some partially synced patterns, would go a long way if I were working with clients. It takes cultural connotation around video games and “levels of difficulty” to add what I see as good friction to switching into what you need, knowing you’ll get a different experience to match your level. It also presents editor defaults less around “write” or “design” and more around difficulty level as I find I very rarely enter the editor thinking about one task. I usually edit my site and am thinking about many tasks but at different levels of difficulty.

Simple mode

This is meant to be for someone who just wants to make simple changes and doesn’t want to risk breaking the layout the theme already set up.

• Theme/site/post/query/template-part blocks are hidden from the inserter, so you can’t accidentally drop a Query Loop or Post Title into a page or build out templates.
• Block-support controls are stripped to the minimum. Only Color and Font Size appear on the block sidebar. Border, Dimensions, Shadow, Position, Advanced typography (line-height, letter-spacing, font appearance), etc. are all removed at the registration level, so they don’t even show up in the ToolsPanel “more” menu.
• focusMode is on so clicking a block dims everything else on the canvas.
• The chrome is minimized aka block breadcrumbs hidden, block helpers (insertion-point UI, etc.) hidden, distraction-free-style minimal topbar.
• The Inserter is locked to the Patterns tab only.
• The RichText toolbar is trimmed to bold / italic / underline / strike / link / inline-code / text-color.
• The Styles sidebar is trimmed to Browse styles + Colors + Typography + Background.
• Patterns are content-locked by default to line up with WP 7.0.
• Root blocks get lock.remove: true. Backspace can’t accidentally wipe an entire section. There are some bugs with this when switching to different modes that I finally gave up on.
• Choose-pattern modal fires on new pages.
• Code Editor and block-directory installs are disabled.
• theme.json is constrained server-side to match — appearance-tools off, advanced typography keys off — belt-and-braces on top of the JS-side stripping.

Intermediate mode

This is meant for someone who is building or rearranging aspects of a site while keeping the overall site design mostly intact. It most closely matches what you get out of the box with some light curation.

• Theme blocks are available in the inserter again.
• Block-support controls show core defaults aka whatever the block author marked as visible by default. The “more” menu has the rest. (No stripping, no force-expansion.)
• focusMode is off — the canvas behaves normally.
• Block breadcrumbs and block helpers are visible.
• All Inserter tabs (Blocks, Patterns, Media) are available.
• Full RichText toolbar.
• Full Styles sidebar.
• Patterns are auto-unlocked when inserted — no extra click to edit structure.
• Root-block lock-removal is off so you can delete sections if you want to. If you save in simple first though, things are still locked.
• Choose-pattern modal still fires on new pages.
• Code Editor and block-directory installs stay disabled (those are Advanced territory).

Advanced mode

This is for designing or rebuilding a theme from scratch. Every control and option is surfaced by default.

• Theme blocks available, same as Intermediate.
• Block-support controls are pre-expanded — __experimentalDefaultControls is populated for every control the block declares, so Border, Dimensions, Shadow, Position, Background, advanced typography, etc. all render up-front in the sidebar instead of hiding behind the “more” menu.
• focusMode off, full breadcrumbs and helpers visible.
• All Inserter tabs.
• Full RichText toolbar.
• Full Styles sidebar.
• Patterns auto-unlocked on insertion.
• Root-block lock-removal is off.
• Choose-pattern modal is disabled on new pages.
• Code Editor is enabled (Ctrl/Cmd+Shift+Alt+M) and block-directory installs are enabled so you can pull in new blocks from wordpress.org.

Going forward

This experience helped me think through some current problems we need to solve in Core, including improving discoverability of entering/exiting contentOnly with patterns, making different settings configurable, what default options should be available, what else we should allow curation for, and more. It was really neat to see the way the many options we have could be curated and also laid bare how our current approach only fits a certain audience. At times, I found myself loving the efficiency the full openness of Advanced provided and, in other moments, the ease of Simple made editing feel more straightforward.

“Your task is not to seek for love, but merely to seek and find all the barriers within yourself that you have built against it, and embrace them.”

Rumi

I’ve heard another variation that’s something like “and love them.” This is one of many quotes that have remained lodged into my soul over many years. In any case, in all of this downtime from surgery, I’ve been feeling many of my barriers. There will always be reasons not to try, not to love, not to care whether that’s with people, work, or my own life. They will never go away. In a moment of awareness today, my perspective eased and I tried to imagine myself pulling in all of my barriers for a big hug. I tried to imagine holding them close and observing them rather than banging my head against them, ruminating on them, or simply stopping at the point of my barriers. These are my barriers! This is what I have been tasked with sitting with in my life. I hope I learn every part of them, how they impact me, how I fall for them, why they are there, how they try to protect me, on and on.