ContentOnly Patterns experiment: Add content only inspector fields #71730
Conversation
talldan added [Type] Experimental 
| Size Change: +5.9 kB (+0.25%) Total Size: 2.41 MB
ℹ️ View Unchanged
|
| Flaky tests detected in caf098b. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/19225947044
|
There was a problem hiding this comment.
This is a really promising direction. Thank you for getting it up @talldan
I think there's value in exposing an API to blocks, more so if, later, there's a way to register field controls or rely on Dataforms. And especially if this is coupled with smart defaults.
The more I think about it, the more I can picture the benefits of an inspector-based content editing approach:
- it centralizes content editing, but still having canvas editing as a complementary mechanism
- reduces friction: users don't have to click into each block individually and deal with visual clutter, and also don't have to understand which blocks are editable vs. which are locked
- for patterns with multiple text fields, users don't have to to click in/out of each block repeatedly
There are going to be some trade offs that can be hopefully addressed by good design choices.
For example, it's a new interaction pattern to learn. Not here, but later, we might want to provide "Edit on Canvas" option for users who prefer it, or make it obvious that it can be detached.
For patterns with many content blocks there'll be iterations to avoid the vertical scrolling nightmare, cognitive overload, and performance.
On mobile we'd want it to be usable too. Some ideas here:
- hierarchical grouping, e.g., grouping headings, other text, media, actions...
- grouping with tabs
- expandable text areas or modals for large content
All that could be adaptable in the UI based on block length and other context vars I guess.
packages/block-editor/src/components/content-only-controls/plain-text/index.js Outdated Show resolved Hide resolved
packages/block-editor/src/components/content-only-controls/media/index.js Outdated Show resolved Hide resolved
tellthemachines left a comment
tellthemachines left a comment There was a problem hiding this comment.
This is generally testing well! I couldn't get the media upload in Cover block to work but apart from that all the fields worked OK.
UX-wise I think the biggest missing thing is a way to select the inspector control from canvas and vice-versa, so it can be obvious what we're editing.
Editing the actual content of a block from the inspector still feels a bit silly, but it does work well for other attributes such as alt text and button links. Though it's tempting to use tools panel to hide the attribs that are not the main content so it feels less overwhelming, I'm also conscious that hiding them might mean some folks don't discover them at all 😅 (I struggle with remembering there are hidden tools even after years of working on this UI).
I'm almost tempted to suggest we make content editing from the inspector a preference, because personally I'd much prefer the inspector to show just the secondary editable fields for the selected block, and not everything for every block in the pattern.
The controls API feels very onerous though. I understand the problem with #71567 is that not all attributes with "content" role should be exposed as editable fields, so auto-rendering fields based on that won't work. But what's the minimum that we can get away with here? Could it just be an extra property on each attribute we want to make editable?
Also, could this mechanism also be leveraged for rendering the relevant inspector fields when the block isn't in contentOnly mode? It feels a bit wasteful to have a different version of each field in each mode, and unifying would make the overall experience more consistent.
What was the issue? It should work and has done in my testing, so any problem I can try to fix.
It was developed very quickly, so it's definitely not perfect. For something like this I think we need more than a day of developer work, which is about all I've spent on it, but it's a proof of concept/experiment, so not yet in the refinements stage. I personally don't think it's particularly onerous though, it's pretty simple and was very quick to add to blocks, but I created it so maybe I'm biased. 😄 I mentioned it in the PR description, but I think my plan would be to make it private and try some different things with the API to see what's achievable to simplify it. In #71567 the fields are still very far from functioning as expected, so it's hard to compare, I expect in that PR config will be needed too (labels, which fields are shown by default, some extra configuration for particular block behaviors). Perhaps in the end there's a middle ground between the two PRs that finds the right balance. |
In Cover blocks that had an opaque overlay color, the image didn't appear, though it showed a URL in the field.
The question is would it be acceptable to ship this in 6.9 with only the canvas interaction parts of the API public? So we could continue iterating on the inspector experience and maybe have it ready for 7.0?
My preliminary opinion on this is that even though I don't love ToolsPanel, it provides a better experience than the drilldown thing going on in #71567 😅 Having to click on stuff to do stuff is incrementally annoying the more clicks you have to do. |
Any particular patterns this happened with? I tried a few and creating my own, but still can't reproduce any issues.
We could also ship the feature with the API still private, but it means no support for third party blocks. Though I think lots of third party blocks are unlikely to adopt any API immediately anyway. Maybe canvas editing is enough for those blocks if we ship the The alternative is being able to finalize #71567 in just a few short weeks. 😬 |
| Small design challenge that I'm trying to solve is that these buttons look like input fields to me: My initial implementation was based on a component called Maybe the styles need to be overridden 😈 Not sure if we have prior art that I can borrow for this implementation. edit: changed the button to a grey colour now to match the featured image button in the post editor, which I think is better, but still looks like an input: |
One of my own with Cover as a top-level container (with an opaque overlay), and also this TT5 one where the opaque colored squares are also Covers:  In the screenshot, I tried to add an image to the black one. |
So it seems like the background image is set, but the black background color remains on the block and obscures the image. If you do the same process via the block on the canvas, the black background color is unset when the background image is added (edit: it actually dims the background). These kind of special block behaviors are difficult to account for. I'll have a think about it! |
| I've added some support for drill down now, with support for blocks like list and navigation. Some notes:
I think it works pretty well, but no doubt can have some refinement. For example, the following video shows a nav block, and we could maybe show visually that although the submenus are flattened that they're still part of a content group. Perhaps by showing a separator/border above the submenu. I think this kind of thing could be a follow-up based on design feedback: Kapture.2025-09-19.at.12.36.09.mp4Support for blocks that use entities like Site Title / Logo is still missing, as those can't simply use We'll need to figure out where we draw the line on this PR. |
talldan requested review from aaronrobertshaw, andrewserong, getdave, jasmussen, jeryj, mtias and scruffian | This is working well for me with Lists, Buttons and Galleries, provided we're not expecting to be able to add new items to them from the inspector 😅  Clicking through to enter a block with nesting doesn't feel too bad. A nested Cover with Gallery inside it has all the Gallery images un-nested (which is better than multiple nesting levels):  I wonder if we really needed to nest the Cover contents though. While it makes the list of fields in the inspector shorter, it doesn't necessarily make sense from looking at the pattern. Should I have to know that the part of the pattern with a different background color is a Cover block? Here is where being able to select an inspector field from the canvas, and vice-versa, might improve the experience. |
| Nice work, this is coming along impressively well. Already in this state, it feels like a very superior experience. There's a question of cases that feature a lot of paragraphs, where editing each paragraph as a separate field is a bit curious, but I'm not expecting a change here as this is part of the expectation of the pattern design, so no complete thoughts on that yet. A few other thoughts. We should elide (...) the label if it goes too long, so it doesn't wrap: The above also surfaces a challenge specifically with the Heading block, which has been changed for the benefit of the list view to show the contents of itself as its title. That becomes duplicative here, and is a bit curious. I understand from #71517 that it's important we show the block names for ergonomics, but I wonder: is it technically reasonable to only show block names, or customized block names, in this interface? I.e. in the above screenshot, unless I've manually renamed the Heading block to be called "Callout" or something else, it would be simply called "Heading"?  Can we omit the ellipsis menu for now? You mention the toolspanel approach for this, and I appreciate the re-use of an off the shelf component. But in part, this interface is about simplifying the editing of patterns, keeping them locked down, so fewer controls aid that aspect. And separately I'm excited about #71203 and theoretical future pattern authoring opportunities as part of this feature, and I have this idea:  The idea being to bring block visibility right into the content panel. Don't want a CTA button? Just hide it, but the pattern author can still include it. To be clear, this is just a vague idea. I'm sharing it only because it might affect the use of the toolspanel pattern.  Showing the links, rich text in the sidebar, this will likely be a future bridge to cross insofar as for the moment, you can't link anything. (Which is fine, this is about a reduced interface). But I do wonder if this means we'll need the ability of the block toolbar to appear in those cases. Or, you can't edit rich text at all, and we show only the text, not the visual link style. In fact the latter may be a better place to start. |
You can use the highlight text + paste URL method to create a link in the sidebar. Cmd + B and Cmd + I should also work for bold and italics. But yeah, no toolbar or popovers right now so you can't see what a link is. |
@jasmussen The only thing about making this change is that tools panel is used to hide some fields for some blocks: Is there some other way you'd recommend handling this if the ToolsPanel is removed?
This is a difficult balance to get right. I think the formatting needs to be preserved—a user might have gone to great lengths to format text in a long paragraph, so we need to maintain a |
andrewserong force-pushed the add/content-only-inspector-fields branch from 7a18611 to 5cb023e Compare 
andrewserong left a comment
andrewserong left a comment There was a problem hiding this comment.
After re-testing this PR with and without the contentOnly experiment on, I'm in favour of the idea of merging this in the shorter-term and continuing to iterate once it's in trunk. It's quite a large PR and there are heaps of things to consider and continue discussing, but it's also a change that's fairly well guarded / preserved behind an experiment.
My thinking here is that:
- The UI is all contained nicely within the
content-only-controlsdirectory, and the main entrypoint for this is ininspector-controls-tabs/content-tab.js. The only actual change to theContentTabcomponent is that it now also receivesrootClientIdand if the experiment is switched on then we useContentOnlyControlsinstead ofBlockQuickNavigation. - This means that we can continue to iterate on the UI in subsequent PRs, like exploring switching to using DataForm / switch out the ToolsPanel for an ad hoc heading + DropdownMenu for handling visibility
- We can also continue to iterate on the shape of
settings.fieldsin each of the blocks — while this PR changes lots of files, each of the changes to block files is guarded behind the experiment and it would be relatively simple to roll these back or update the shape ofsettings.fields - In follow-ups, I'd like to see us update the shape of
settings.fieldsso that it can match the DataForm API as closely as possible. I.e.typeshould correspond to DataForm controls, and we'd useidinstead ofmappingin some cases, etc, etc. But these nuances are best explored in smaller PRs IMO
So, all up — I think this PR provides a good foundation for continued work on this feature. There's also a natural entrypoint for us if we want to add an additional experiment to toggle between this editable fields UI and the previous BlockQuickNavigation — we'd simply update the ContentTab component to use a different experiment check before rendering ContentOnlyControls.
In short, I think merging will allow us to iterate more confidently and help tease apart decisions surrounding use of components and ideal UI and UX. If we decide that the overall experiment is not worth pursuing, then I also think it wouldn't be hard to remove this change (i.e. update ContentTab and remove settings.fields changes from the block library changes).
With all this in mind, I'm going to give this a tentative approval. I'm 50/50 on the UI — for smaller patterns I think it feels good, for longer ones I think it can be pretty rough, but I'm also keen to see how this UX pattern can evolve, and if we can polish it into something good, or if it winds up feeling like too much.
| Thanks @andrewserong - appreciate the thorough testing. LGTM to me. Approving because it's behind an experiment. We can let it simmer overnight in case @jasmussen and @mtias have time to give it a look. Other options if we want to test this feature and the base content only functionality separately:
💯 I think we have a good base from which to iterate seeing as it's still behind an experiment. Looks like reverting won't be too spaghetti-like in any event. Agree about DataForms, and carrying on the work to find a better UX for the side bar. I don't think we've cracked it, but hopefully a combo of testing, eyes and iteration will set us on course. On the public API side of things, I couldn't find any public API leaks
An optional improvement is to ensure that the block being edited is actually visible: I think not knowing which block you're editing could get annoying very fast. 😄 |
| I'm hoping to review the state of things well today, provide any missing mockups, and in general give this the attention it deserves. Before I return, a quick kudos for the patience and the hard work. This is impactful. Some quick instincts:
I'd question whether someone would choose to write long-form content inside a pattern or template part, which is one of the reasons I think it's important to start with the most basic interface outlined, and only optimize for what could be an edgecase when we know more clearly whether it's an edge-case or not. And yes, if this turns out to be a real headache for folks, then there are a lot of things we can do. I'll be eyeing #73222 a bit later, excited about some of the potential there. We've discussed how complex it might be to work with contiguous paragraphs, vs. keeping them separate. But there may still be something there, treat them as one, or collapse into flyouts, collapsibles. All sorts of optimizations are available to us: but let's build them when we realize they are necessary. One of the most important rules of thumb for all this work, is that this interface is not meant to be a replacement for the regular editing interface, it's meant to be a simpler interface for engaging with patterns. And if your needs situationally go beyond what's surfaced in the reduced interface, it needs to be trivial and intuitive to edit the blocks that make up the pattern, or just straight up detach. We can make those actions as prominent as we need them to be.
I will focus on this in my testing today, and try the most complex patterns I can find. Kudos for the attention to detail, and I want to help validate what we're doing here, but also agreeing that there will almost certainly be easy fixes to apply as followup PRs, especially since this is already an experiment. |
| Okay, I've gone fairly deep on this, and I want to start again with kudos. This is in a good spot, and I think we should land it and iterate. In addition to that, I found have some observations that I'd like to share, none of them I'd consider blockers to this PR landing:
For me the picture that is forming is that the flow feels right, and it's now a matter of iterating the details, including those above. To hopefully help make that more specific, I dove into some fresh iterations on the mockups we've had so far. I'll start with this one:
One of the things also discussed in 71517 is how we edit additional attributes set, such as alt text or a caption on an image. That same issue suggests a flyout, same as DataForm can hopefully provide, which I've sketched here:
I realize that this PR at present would put those inside a drilldown. Whether drilldown or flyout, we can feel out what works best there, but key here would be that the fields are very much data-driven, as Matías alludes to here. Let me know if this is useful! |
| @jasmussen Thanks for the feedback 🙇🏻 And good to have the confidence that we can merge and iterate. We'll dissect your feedback and create follow up tasks.
@tellthemachines pointed out that it's probably due to patterns that have no "root" block. There's no workaround for this yet. Issue reported: |
Agree. Iteration tasks to come... Thanks again. |
The |
Did you have an idea in mind for how to make it private? I couldn't see anywhere where we're treating it as a public API because both the contentOnly controls and setting Or do you mean because if someone calls |
| Yes, I'm not sure the experiment flag is a strong enough contract to consider it a private API. I would personally prefer if it didn't show up at all just to be on the safe side. I think we can use the private symbol key approach that's been used for private block editor settings. I'll put a PR together. edit: PR here - #73376 |
Gotcha — that sounds reasonable, especially to make sure we don't accidentally expose anything when stabilising the experiment, if we still want to keep the API for fields experimental. Thanks for taking a look! |
What?
Part of #71517
Contributes to solving #71557
Adds editable fields for contentOnly patterns. At the moment this only shows UI for non-container blocks, and I think it covers most of the main use cases with some outliers. Galleries, Links, and others should probably have some kind of drilldown, but I'll work on this as a followup.
TODO
Differences to #71567
index.js. I think this is a more achievable way to start. It may be possible to follow up by inferring the controls for blocks like Experimental - Add content attribute controls to "Content" sidebar in contentOnly #71567, but I think having a working implementation and reverse engineering it will be much easier. The config shows fairly clearly what each block requires.Other notes
setAttributesand notupdateBlockAttributes)Testing Instructions
Screenshots or screencast
(In the video there's an issue where LinkControl doesn't open up correctly when at the bottom of the screen, I need to fix it)
Kapture.2025-09-18.at.10.19.30.mp4