Experimental - Add content attribute controls to "Content" sidebar in contentOnly#71567
Experimental - Add content attribute controls to "Content" sidebar in contentOnly#71567getdave wants to merge 13 commits into
Conversation
|
Size Change: +1.01 kB (+0.05%) Total Size: 1.94 MB
ℹ️ View Unchanged
|
|
Flaky tests detected in 3f94064. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/17612601792
|
getdave
added
[Type] Experimental
getdave
changed the title
Don't you need a label for the fields? |
| }, | ||
| "id": { | ||
| "type": "number", | ||
| "role": "content" |
There was a problem hiding this comment.
Do you know why id had the content attribute in the first place? 🤔
There was a problem hiding this comment.
I checked on the source of when it was added in #47936, and my best guess is that it was so early in the process that it was added because it was so unclear how to make something considered content. From where we are now, it feels safe to say that "id" should not be considered content.
There was a problem hiding this comment.
I think this is the attachment id, and when replacing an image from the media library this will need to be updated (even in content only mode). We'll need a control in the inspector that can change this value. So I'd argue it could be considered as content. I think that's probably why the role was added.
In terms of inferring a control, we probably need to be able to detect the attachment id and the img/video element src attributes, and when present show a control that can update these values together. We might also want to match the logic around how the caption and alt text can be set from the attachment's caption.
There was a problem hiding this comment.
We were discussing identifying the media src and showing a media selection button. We haven't gotten there yet.
It feels like a bug to need id labeled as content. Hopefully using a media selector will set the fields we need.
There was a problem hiding this comment.
We'll need a control in the inspector that can change this value. So I'd argue it could be considered as content. I think that's probably why the role was added.
Do we need the attribute to be exposed in the inspector? Could we just update it when the media item itself changes?
| if ( attrDef.role === 'content' ) { | ||
| attributes.push( { | ||
| name: attrName, | ||
| definition: attrDef, | ||
| value: block.attributes?.[ attrName ], | ||
| } ); |
There was a problem hiding this comment.
Very clever!
Just checking my skim-reading assumptions: any block attribute could opt-in or opt-out of having content-only editable fields by:
- Using attributes[ someAttr ].role = 'content'
- The attribute having a supported type.
|
From the screenshot/screencast, it seems we're just duplicating fields that are already in Canvas. This seems to be going in the opposite direction to what we've been advocating with the block editor - in canvas editing is better than filling out forms. It also looks like what many "block builder" plugins are doing, using the sidebar to edit attributes, instead of the canvas. |
|
@Mamaduka this is to try the proposal in Pattern Editing and contentOnly interactivity. That's probably a good place to leave feedback, I expert more people are reading than the PRs. |
|
A lot to digest here. I like the idea of inferring the controls, but from testing the PR there are a lot of problems to solve, and I'm not sure it's a good idea to opt-in every attribute straight away. An example is that it's very easy to break image blocks by disconnecting the I think links will present similar challenges, where there's I'm ok with the idea of trying this, but I think it should be iteratively introduced rather than allowing everything from the start (and I realize that goes against the point of making everything work out of the box for third party blocks). UI-wise, I think it'd be good to lean closer to what was described in the issue too. So no drill down, instead something more like ToolsPanel. If we can achieve that with DataForms that's ideal, but I think we might need to gradually implement that. We need to consider things like having proper labels and only showing some fields by default as well. I also wish we'd focus efforts on one PR rather than creating alternate diverging approaches so early. Things will go very slowly if we constantly duplicate what we're working on. I could've done better on this as well, maybe I should've assigned the issue. Let's try to better coordinate efforts in the future. |
I think it's okay to try out different directions for Core work, but this is an unusual project in that it was proposed late in the cycle. I guess we have the luxury of working behind an experiment and iterating until we get things right. If the goal is to prototype with a view to request more fine-grained feedback, what can we work on in parallel? |
Suggestions |
I think this is the central issue. We're trying to quickly figure out a thing that we're not sure what the end looks like. We're not trying to step on toes, but quickly iterate sketches so we can find what works. I can confidently say @getdave and I are NOT confident that this PR is the right direction. We are using this PR to see if it might be the right direction. This is very much a POC sketch of the idea to see if it breaks down.
In #71517 it says:
I'm not saying it's the right move, but that's how we're building the sidebar in this PR to see how it works. |
getdave
force-pushed
the
feature/attribute-controls-system
branch
from
0f030f7 to
25d4c67
Compare
|
@talldan - thanks for testing this out! We're very much learning as we go here.
I didn't know this - could you explain how to reproduce this?
I think those should be excluded from the content editing experience. Those are more advanced functionality than baseline experience IMO. |
When adding a media library image to the block normally, both the In this PR you can change the image's I think what you'll need is a single control that manages both the gutenberg/packages/block-library/src/image/block.json Lines 26 to 27 in a4d79e8 Why? Because the video block needs to work the same way, but there the attribute is Then I don't how you'd determine which is the gutenberg/packages/block-library/src/image/block.json Lines 76 to 79 in a4d79e8 |
I was leaning more towards ToolsPanel based on past sentiment when this kind of UI has been discussed. For example: I did also ask a clarifying question about this in #71517 and this was the answer (#71517 (comment)):
It was a somewhat closed question rather than an open one though. Then there was a little bit extra about possibly using drilldown for complex blocks with hierarchy like List, but it still feels quite unclear to me how that will work. Maybe it'll be unusual having some blocks that drill down and others that don't, but I think it will already be the case no matter what. I'm also thinking that we have ToolsPanel on every core block now as the default Inspector UI, so it might make sense from that perspective too. |
|
I'm all in favor of reusing existing UI and components. This is very much a sketch to see if we can infer controls more than what UI we go with. |
- Display standardized UI controls for attributes with role: 'content' - Support string, boolean, and rich-text attribute types - String and rich-text render as TextControl - Boolean renders as ToggleControl - Controls appear under blockTitle in the sidebar - Maintains block selection while editing attributes
- Implement Navigator component with home screen and block-specific sub-screens - Add smart attribute display logic: inline for single attributes, navigation for multiple - Show chevron arrow for blocks with >1 content attribute to indicate drill-down capability - Create BlockContentAttributesView for detailed attribute editing in sub-view - Add SingleContentAttributeControl component for reusable single attribute handling - Maintain LinkControl with popover functionality for URL attributes - Ensure only one block sub-view can be open at a time - Provide 'Back' button to return to main view from sub-view - Preserve existing inline display behavior for single content attributes
…urning from deeper level
…d not be write mode editable I think these attributes were added early in on write mode (see PR# 47936) and incorrectly assigned role content to id, ref, and title attributes.
This is not working. When encountering a paragraph or list block, it creates a content group and passes these blocks to a standalone unstyled editor. The issue is this editor instance is tied to the main editor.
This can keep getting refactored further. The media selector is working though by inferring a selector of img and attribute of src. This can then be expanded for better UI when that is determined.
scruffian
force-pushed
the
feature/attribute-controls-system
branch
from
4716c74 to
da9a3f2
Compare
|
I'm coming back to this a bit late, I had some AFK. Thanks for the ping. Quick GIF:
I guess this is some work that precedes #71730 yes? I also just reviewed that. Both work well, though I tend to think 71730 works slightly better. The drilldown in the content pattern is impressive, I think this pattern can work especially well with complex blocks in contentOnly mode, a la Query Loop or Navigation (think site links), but less so for patterns where arguably it is beneficial to lock things down to what the pattern author has done, and be a bit more limiting in the options. The main goal is to provide a simplified editing interface for complex blocks or groups of blocks. For mostly static visual patterns, my instinct would go towards not needing the drilldown. |
|
Closing in favour of #71730 |
7 participants
This PR has been co-authored by @jeryj.
What
This PR explores (this is a WIP/prototype!) an automatic approach to displaying standardized UI controls for attributes with
role: 'content'in the block quick navigation sidebar. Unlike the alternative approach in #71577, this implementation requires no changes to existing block.json files and works automatically with all blocks (core and third-party).@jeryj and I are not sure which approach is best so we felt that prototyping this might help contributors to decide on which approach is best.
Closes #71557: Add automatic content attribute controls to block quick navigation sidebar
Key Features
@wordpress/dataviewsDataForm components as suggested in #71577#issuecomment-3274658200 - cc @youknowriadstring,boolean,rich-text,number, and URL attributes with intelligent field type mappingblock.jsonWhy
The current contentOnly mode lacks standardized controls for editing block content attributes in the sidebar. This creates an inconsistent user experience where users must switch between the canvas and sidebar to edit different aspects of their content.
This automatic approach addresses the core concern raised in #71577: ensuring write mode works for third-party blocks without requiring updates from block authors.
Comparison with Alternative Approach
controlproperty inblock.jsonWe acknowledge that both approaches have merit and the optimal solution may be a hybrid approach that combines automatic inference with optional manual overrides.
How
Automatic Control Inference
The system automatically maps attribute types to appropriate DataForm field types:
textfieldtogglefieldtextfield (with future RichText support)textfieldurlfield (detected by name patterns:url,src,href,link)Smart UI Layout
DataForm Integration
Leverages
@wordpress/dataviewsDataForm components for:Implementation Details
packages/block-editor/src/components/block-quick-navigation/index.js@wordpress/dataviewsto block-editor packageuseMemofor attribute processing anduseSelectfor efficient data accessTesting
Manual Testing
role: 'content'attributesKeyboard Testing
Screenshots
Screen.Capture.on.2025-09-10.at.16-58-21.mp4
Breaking Changes
None - this is purely additive functionality.
Uncertain Elements
Related Issues