Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add: Content lock ability. #43037

Merged
merged 24 commits into from
Aug 31, 2022
Merged

Add: Content lock ability. #43037

merged 24 commits into from
Aug 31, 2022

Conversation

jorgefilipecosta
Copy link
Member

@jorgefilipecosta jorgefilipecosta commented Aug 5, 2022

As shared by @jameskoster in #42684 (comment) we are exploring a content lock with the following requirements when a container is 'content locked':

  • Non-content child blocks (containers, spacers, columns, etc.) are hidden from the list view, un-clickable on the canvas, and entirely uneditable.
  • The Inspector will display a list of all child 'content' blocks. Clicking a block in this list reveals its settings panel. We may need to list the root block as well, but I am not 100% sure.
  • The main List View only shows content blocks, all at the same level, regardless of actual nesting.
  • Children move and remove is locked.
  • Additional child blocks cannot be inserted.
  • There is a link in the block toolbar to 'Edit as blocks'. This temporarily toggles off the features outlined above, allowing full edit access, either inline (similar to cropping in the Image block) or in template part focus mode. We should test both approaches.

Screenshots

image
image
image

Sample

<!-- wp:group {"templateLock": "contentOnly", "backgroundColor": "pale-cyan-blue", "layout" :{" type": "default"}} -->
<div class= "wp-block-group has-pale-cyan-blue-background-color has-background"><!-- wp:heading {"style" :{ "typography" :{ "fontStyle": "normal", "fontWeight": "700"}}, "backgroundColor": "pale-pink", "fontSize": "x-large"} -->
<h2 class="has-pale-pink-background-color has-background has-x-large-font-size" style="font-style:normal;font-weight:700">Heading</h2>
<!-- /wp:heading -->

<!-- wp:list -->
<ul><!-- wp:list-item -->
<li>a1</li>
<!-- /wp:list-item -->

<!-- wp:list-item -->
<li>2</li>
<!-- /wp:list-item -->

<!-- wp:list-item -->
<li>3</li>
<!-- /wp:list-item -->

<!-- wp:list-item -->
<li></li>
<!-- /wp:list-item --></ul>
<!-- /wp:list -->

<!-- wp:paragraph {"backgroundColor": "vivid-red", "textColor": "secondary"} -->
<p class="has-secondary-color has-vivid-red-background-color has-text-color has-background">Paragraph</p>
<!-- /wp:paragraph -->

<!-- wp:quote -->
<blockquote class="wp-block-quote"><!-- wp:paragraph -->
<p>sdsds</p>
<!-- /wp:paragraph --><cite>sd</cite></blockquote>
<!-- /wp:quote -->

<!-- wp:image {"align": "center", "width":239, "height":239, "sizeSlug": "large", "style" :{ "border" :{ "width": "18px" }}} -->
<figure class="wp-block-image aligncenter size-large is-resized has-custom-border"><img src="https://s.w.org/style/images/about/WordPress-logotype-wmark.png" alt="" style="border-width:18px" width="239" height="239"/><figcaption class="wp-element-caption">f</figcaption></figure>
<!-- /wp:image -->

<!-- wp:spacer {"height":"28px"} -->
<div style="height:28px" aria-hidden="true" class="wp-block-spacer"></div>
<!-- /wp:spacer -->

<!-- wp:group {"backgroundColor":"secondary"} -->
<div class="wp-block-group has-secondary-background-color has-background"><!-- wp:separator -->
<hr class="wp-block-separator has-alpha-channel-opacity"/>
<!-- /wp:separator -->

<!-- wp:spacer {"height":"55px"} -->
<div style="height:55px" aria-hidden="true" class="wp-block-spacer"></div>
<!-- /wp:spacer -->

<!-- wp:pullquote {"gradient":"blush-bordeaux"} -->
<figure class="wp-block-pullquote has-blush-bordeaux-gradient-background has-background"><blockquote><p>End quote inside another group</p></blockquote></figure>
<!-- /wp:pullquote --></div>
<!-- /wp:group --></div>
<!-- /wp:group -->

Testing

  • I pasted the previous sample on the code editor.
  • I verified there is no way I could select the image (images will be considered content in the future on another PR I'm making) or spacer blocks by clicking on it or by using keyboard navigation, e.g., arrows and tabs. It looks like the non-content block does not exist.
  • I verified the non-content blocks don't appear on the list view.
  • I verified the group block was totally locked; I could not insert or move any block inside it.
  • I verified I could use Edit as blocks to make the block "normal".
  • I verified that If I'm using Edit as blocks and move away to another block outside the group, the group block becomes locked again, and the Edit as blocks stops.
  • I verified that If I'm using Edit as blocks and click finish editing as blocks, the group block becomes locked again, and the Edit as blocks stops.

Missing

UI to add a content block. For now, we can hardcode on the code editor. But a UI could be offered either as part of the lock modal or as part of a UI to create patterns on the editor.

@jorgefilipecosta jorgefilipecosta added the [Feature] Patterns A collection of blocks that can be synced (previously reusable blocks) or unsynced label Aug 5, 2022
@jameskoster
Copy link
Contributor

Nice, this is working fairly well. A couple of observations:

We need a way to handle non-text content like images. In the example above it should be possible to swap the image source.

It's a bit strange to find the parent container in the 'content' section of the Inspector, since that is not really 'content'. We'll need to adjust the design a bit there.

There's something a little bit awkward about clicking the block in the Inspector and being taken to the settings panel. I think it's because it looks like list view, and so I've come to expect that clicking will just select the block. Having both actions take place simultaneously (select & reveal settings) feels a bit unexpected. Perhaps we need a dedicated 'Settings' button or something.


A more high-level thought that may impact some of the above: 'content lock' kind of suggests to me that only content can be edited. Consequently this brings into question whether it should be possible to adjust the style of the content blocks inside the container? It would simplify things a great deal if you were only able to edit the actual content (and use the tools in the toolbar) here. If it's not a lot of work, it could be interesting to try a version of this where you cannot access the settings panels.

@jasmussen
Copy link
Contributor

Nice, this is a potent PR, let's be sure to land a variant of this in time for 6.1.

I took it for a quick spin:
contentlock

I'm still absorbing the feature, so I'll need to think more about this. But a few very quick first impressions:

  • Locking down and flattening the structure, but maintaining editability of text, is the key value of this.
  • The simple logic for the sliding inspector works pretty well for customizing each block inside.
  • The flow for Edit as blocks and finish editing as blocks works well, since the unit maintains its overall locking state even if you de-select. In other words, it isn't a "convert to blocks" button. Though, let's look for simpler wording here (Is "Edit" and "Done" too little?)

Something that I'll need to think more about is the heuristic for which blocks show up as still selectable, and which ones don't. I have to edit as blocks to change the image, but I can change the heading level. Mainly this feels a bit confusing as I can clearly see there's an image present, but it doesn't show up in the list view.

Part of me would like for all of this to be locked down even further, especially for the first iteration. As an unformed thought is to not show any child blocks in list view when locked, and to use a drastically simplified block toolbar for any editable fields inside. Something closer to the caption toolbar we have:
Screenshot 2022-08-09 at 13 42 03

I.e. perhaps instead of this:

Screenshot 2022-08-09 at 13 43 36

maybe something like this:

Screenshot 2022-08-09 at 13 44 07

I'll come back with more thoughts, but wanted to share immediate reactions. Nice work!

Comment on lines 1438 to 1440
if ( getBlockAttributes( state, rootClientId ).lock?.content === true ) {
return 'all';
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking at this change, I wonder if it makes sense for content locking to be a part of templateLock, instead of block locking.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question 👍 Yes, I guess we should consider making it a templateLock = content. It seems to make sense.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've been educating myself about the different locking mechanism we have. I agree that using templateLock makes more sense than lock because templateLock aims to control the inner blocks behavior while lock controls the block itself.

I see some challenges:

  • Naming. We should follow the existing naming schema and indicating what it locks, not what it allows to edit. noContent could work.
  • Semantics. Introducing a new state to templateLock that is not absorved by the existing all is going to create disonance for users of the API. Example:
    • inserts => locks insertion/removal
    • all => "inserts" plus locks movement
    • noContent => "all" plus a bunch of other things (prevent selection for blocks without content, hide them listview, absorb the block inspector of the inner blocks, etc)
  • Nested templateLock. The existing locking mechanism fallbacks through a hierarchy: PostType's templateLock < an InnerBlocks's templateLock < another InnerBlocks's templateLock < a singe Block's lock. The latest has more priority. Does the new noContent state also flows through the hierarchy? If so, what's the expected behavior here:
<group templateLock=noContent>
  <group templateLock=all />
</group>
  • Following the reasoning above, there's an existing templateLock=false state. If a block has this state, it "unlocks" anything defined up in the hierarchy. Some blocks use it: social links, navigation, and column. If we respect the cascading behaviour and false can unlock anything, the new state won't be effective for those blocks.
  • templateLock and lock and interrelated. We should consider introducing the corresponding states for lock if we introduce one for templateLock.

Chewing about it, this is the next steps I see:

  • Update this PR to use a new state in templateLock instead of lock. Despite the challenges it makes more sense.
  • Ignore the value of templateLock for nested containers in this PR. For controlling scope, it should be addressed in a follow-up.
  • We may need to consider exposing templateLock as an attribute of colum, navigation, and social links should the false state needs to be overriden by a pattern. To be tested and investigated when addressing nested content.
  • I'm unsure about introducing a new state for lock. It makes sense conceptually, though I can't see now any practical uses for it. Punt it for the future if need be.

Thoughts?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pushed changes to substitute lock.content by templateLock: "noContent". It should work the same as before.

@jameskoster
Copy link
Contributor

As an unformed thought is to not show any child blocks in list view when locked

I think this is worth a try, possibly in conjunction with not providing access to the inspector for child blocks as well. These feel somewhat linked to me, and fit the notion of shipping something sooner that is more lightweight.

It would solve the somewhat awkward duplication of child blocks appearing both in list view and the Inspector. And the interaction quirk I pointed out in my last comment, where clicking the child block's name in the Inspector has two detached actions (select + expose settings). It would probably feel more natural if it was just a selection tool.

maybe something like this:

That's a good thought. There's really no need to display the block type in the toolbar, especially as transforms shouldn't be possible in this context. Ditto the lock icon – the lock status of these blocks should probably be governed inherently by the parent's 'content lock'.

Just to connect a dot, could we somehow leverage the work in #42399 to achieve this?

I would add that it might be worth keeping the parent selector though. It will be helpful in configurations where child blocks fill the height/width of the parent.

@jasmussen
Copy link
Contributor

Just to connect a dot, could we somehow leverage the work in #42399 to achieve this?

I had that thought too. It might, but given how trivial it was in the inspector to hide a few of the toolbar segments, it might be okay to do a temporary thing in the mean time?

I would add that it might be worth keeping the parent selector though. It will be helpful in configurations where child blocks fill the height/width of the parent.

I don't feel strongly about this. But I do kind of feel like having to select a layer kind of goes against the main purpose of "flattening" a pattern like this. What might be a use case where one such thing was needed in this flattened hierarchy? And might there be a different way to accomplish it?


A transversal thought: at the moment a block has options in both the toolbar and in the inspector. I recall @critterverse thinking a lot about this split back in the day, and it remains a bit messy.

As configuration tools in Global Styles → Blocks increasingly get added and mature, it's also becoming clear that if you need to be able to configure a block default, it has to be present in the inspector. It cannot live only in the block toolbar, lest it just won't be fully accessible there. (Because you might be styling a Featured Image on a template that doesn't yet have a featured image inserted in the canvas to select).

This could suggest that every action present in the block toolbar must, somehow, also be present in the inspector. The block toolbar would still afford an immediate and intuitive access point, but nevertheless the option has to be present in the inspector. Which means absorbing controls in an interface like this could potentially be even simpler still.

Something to think about.

@jameskoster
Copy link
Contributor

I don't feel strongly about this. But I do kind of feel like having to select a layer kind of goes against the main purpose of "flattening" a pattern like this.

I don't feel strongly either. It's on my list to test this PR with different block configurations, I think that will help to make a decision.

@@ -789,3 +789,13 @@ export const hasChildBlocksWithInserterSupport = ( state, blockName ) => {
return hasBlockSupport( state, childBlockName, 'inserter', true );
} );
};

export const __unstableIsContentBlock = createSelector(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you think of expanding the existing naming (example) and use something along the lines of __experimentalHasContentRoleAttribute? As the first time I ran into this, it was not clear what a "content block" was.

);
}

function BlockNavigatorScreen( { block } ) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you think of extracting these components to its own file? The amount of supporting components/utils is high and introduces noise when one wants to understand the high-level flow.

blockTypes={ blockTypes }
/>
) ) }
{ showSelectedBlock && (
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can actually still select blocks that don't have content. The question is what we do in that situation. This is what happens now:

selected-block.mp4

My first instinct is that this interaction is at odds with what this feature wants to achieve (hide blocks with no content). So, what do you think of showing the top-level block inspector controls when this happens?

);
}

function BlockInspectorAbsorvedBy( { absorvedBy } ) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've had troubles to parse what BlockInspectorAbsorvedBy and absorvedBy meant. I'm not sure about the right naming here and wanted to share some ideas to see if we can come up with a better naming schema: BlockInspectorLockedBlocks and topLevelLockedBlock?

@oandregal
Copy link
Member

Hey, I've reviewed parts of this code (listview, blockinspector) and need to finish it.

In the meantime, I have a conceptual doubt. I've read some of the linked issues and the relationship between this lock and the "block lock" mechanism we have in place is not clear to me. What's the difference between:

Captura de ecrã de 2022-08-12 13-49-59

And this other lock:

Captura de ecrã de 2022-08-12 13-49-41

In principle, it sounds like the work here could go into the "lock modal" at a visual level. Conceptually, the lock in this PR feels like a "special/smart" lock that does a few things beyond what the other locks do (affects the inspector and listview) though fall into the boat. Does that make sense? It'd be helpful to finalize the technical review to have more context about these things.

@jorgefilipecosta
Copy link
Member Author

Hey, I've reviewed parts of this code (listview, blockinspector) and need to finish it.

In the meantime, I have a conceptual doubt. I've read some of the linked issues and the relationship between this lock and the "block lock" mechanism we have in place is not clear to me. What's the difference between:

Captura de ecrã de 2022-08-12 13-49-59

And this other lock:

Captura de ecrã de 2022-08-12 13-49-41

In principle, it sounds like the work here could go into the "lock modal" at a visual level. Conceptually, the lock in this PR feels like a "special/smart" lock that does a few things beyond what the other locks do (affects the inspector and listview) though fall into the boat. Does that make sense? It'd be helpful to finalize the technical review to have more context about these things.

The other locks allow restrictions on the block like movement or removal, and that's it. This lock is something more advanced. It not only applies restrictions of removal and movement but also tries to make things nested in an area look like a single block, where only the blocks with content are editable.

@jorgefilipecosta
Copy link
Member Author

Hi @jameskoster, @jasmussen, @oandregal, thank you for the reviews.

We need a way to handle non-text content like images. In the example above it should be possible to swap the image source.

Images are going to be content when #43038 is merged.

I would add that it might be worth keeping the parent selector, though. It will be helpful in configurations where child blocks fill the height/width of the parent.

I would say not the parent because we don't want a hierarchy concept, but on all the toolbars the top block that has the lock would appear as the parent, so we always have a way to select it even if children take up all the space. It would appear as if all the content blocks are direct children no matter what other blocks are in the middle.

So here are the things we should try/next steps.

  • Remove the inspector when there is a content lock. Based on this feedback from @jameskoster.

If it's not a lot of work, it could be interesting to try a version of this where you cannot access the settings panels.

  • Correct the labels to "Edit" and "Done".
  • Remove child blocks from the list view when the block has content locking.
  • Simplify the toolbar and just show some tools. This one is more nuanced e.g: we can not hide almost everything from the toolbar on images as that would make it impossible to replace the image, but on text blocks, we can have a simplified version.

Does this list of next experiments seems correct, or is there anything I'm missing/should not be tested now?

@jasmussen
Copy link
Contributor

Sounds good to me.

Simplify the toolbar and just show some tools. This one is more nuanced e.g: we can not hide almost everything from the toolbar on images as that would make it impossible to replace the image, but on text blocks, we can have a simplified version.

Just to clarify, it would be the exact same categories we remove across all inner blocks, it would not be a curated list. Specifically, it would be the "mover group" and the ellipsis, always. So in the case of paragraphs and images, it would be these sections:
Screenshot 2022-08-15 at 09 45 44
Screenshot 2022-08-15 at 09 45 52

@oandregal
Copy link
Member

oandregal commented Aug 16, 2022

I've given this a try using the blockquote that can have innerblocks and also the cite which is a richtext field. Note how:

  • the paragraph within the quote is listed in the listview
  • the cite within the quote is not listed
  • the quote itself is listed
Unlocked Locked
Captura de ecrã de 2022-08-16 14-21-17 Captura de ecrã de 2022-08-16 14-21-24

I'll have a look at what can we do here in the context of Nik's comment about how the nuances of __experimentalRole at #43038 (review)

@oandregal
Copy link
Member

I've given this a try using the blockquote that can have innerblocks and also the cite which is a richtext field. Note how:

I gave this a shot and it looks like we need to live with this for now. The issue is that the quote's cite is not a block so it's only editable if we make the quote itself editable. If we remove the "role=content" from the quote atts (see), there's no way for the user to edit the cite.

@github-actions
Copy link

github-actions bot commented Aug 17, 2022

Size Change: +1.73 kB (0%)

Total Size: 1.24 MB

Filename Size Change
build/block-editor/index.min.js 161 kB +1.47 kB (+1%)
build/block-editor/style-rtl.css 15.2 kB +90 B (+1%)
build/block-editor/style.css 15.2 kB +89 B (+1%)
build/block-library/index.min.js 188 kB +17 B (0%)
build/blocks/index.min.js 49.6 kB +60 B (0%)
ℹ️ View Unchanged
Filename Size
build/a11y/index.min.js 982 B
build/annotations/index.min.js 2.76 kB
build/api-fetch/index.min.js 2.26 kB
build/autop/index.min.js 2.14 kB
build/blob/index.min.js 475 B
build/block-directory/index.min.js 7.05 kB
build/block-directory/style-rtl.css 990 B
build/block-directory/style.css 991 B
build/block-editor/default-editor-styles-rtl.css 378 B
build/block-editor/default-editor-styles.css 378 B
build/block-library/blocks/archives/editor-rtl.css 61 B
build/block-library/blocks/archives/editor.css 60 B
build/block-library/blocks/archives/style-rtl.css 65 B
build/block-library/blocks/archives/style.css 65 B
build/block-library/blocks/audio/editor-rtl.css 150 B
build/block-library/blocks/audio/editor.css 150 B
build/block-library/blocks/audio/style-rtl.css 122 B
build/block-library/blocks/audio/style.css 122 B
build/block-library/blocks/audio/theme-rtl.css 110 B
build/block-library/blocks/audio/theme.css 110 B
build/block-library/blocks/avatar/editor-rtl.css 116 B
build/block-library/blocks/avatar/editor.css 116 B
build/block-library/blocks/avatar/style-rtl.css 59 B
build/block-library/blocks/avatar/style.css 59 B
build/block-library/blocks/block/editor-rtl.css 161 B
build/block-library/blocks/block/editor.css 161 B
build/block-library/blocks/button/editor-rtl.css 441 B
build/block-library/blocks/button/editor.css 441 B
build/block-library/blocks/button/style-rtl.css 505 B
build/block-library/blocks/button/style.css 505 B
build/block-library/blocks/buttons/editor-rtl.css 292 B
build/block-library/blocks/buttons/editor.css 292 B
build/block-library/blocks/buttons/style-rtl.css 275 B
build/block-library/blocks/buttons/style.css 275 B
build/block-library/blocks/calendar/style-rtl.css 207 B
build/block-library/blocks/calendar/style.css 207 B
build/block-library/blocks/categories/editor-rtl.css 84 B
build/block-library/blocks/categories/editor.css 83 B
build/block-library/blocks/categories/style-rtl.css 79 B
build/block-library/blocks/categories/style.css 79 B
build/block-library/blocks/code/editor-rtl.css 53 B
build/block-library/blocks/code/editor.css 53 B
build/block-library/blocks/code/style-rtl.css 103 B
build/block-library/blocks/code/style.css 103 B
build/block-library/blocks/code/theme-rtl.css 124 B
build/block-library/blocks/code/theme.css 124 B
build/block-library/blocks/columns/editor-rtl.css 108 B
build/block-library/blocks/columns/editor.css 108 B
build/block-library/blocks/columns/style-rtl.css 406 B
build/block-library/blocks/columns/style.css 406 B
build/block-library/blocks/comment-author-avatar/editor-rtl.css 125 B
build/block-library/blocks/comment-author-avatar/editor.css 125 B
build/block-library/blocks/comment-content/style-rtl.css 92 B
build/block-library/blocks/comment-content/style.css 92 B
build/block-library/blocks/comment-template/style-rtl.css 187 B
build/block-library/blocks/comment-template/style.css 185 B
build/block-library/blocks/comments-pagination-numbers/editor-rtl.css 123 B
build/block-library/blocks/comments-pagination-numbers/editor.css 121 B
build/block-library/blocks/comments-pagination/editor-rtl.css 222 B
build/block-library/blocks/comments-pagination/editor.css 209 B
build/block-library/blocks/comments-pagination/style-rtl.css 235 B
build/block-library/blocks/comments-pagination/style.css 231 B
build/block-library/blocks/comments-title/editor-rtl.css 75 B
build/block-library/blocks/comments-title/editor.css 75 B
build/block-library/blocks/comments/editor-rtl.css 834 B
build/block-library/blocks/comments/editor.css 832 B
build/block-library/blocks/comments/style-rtl.css 632 B
build/block-library/blocks/comments/style.css 630 B
build/block-library/blocks/cover/editor-rtl.css 605 B
build/block-library/blocks/cover/editor.css 607 B
build/block-library/blocks/cover/style-rtl.css 1.55 kB
build/block-library/blocks/cover/style.css 1.55 kB
build/block-library/blocks/embed/editor-rtl.css 293 B
build/block-library/blocks/embed/editor.css 293 B
build/block-library/blocks/embed/style-rtl.css 410 B
build/block-library/blocks/embed/style.css 410 B
build/block-library/blocks/embed/theme-rtl.css 110 B
build/block-library/blocks/embed/theme.css 110 B
build/block-library/blocks/file/editor-rtl.css 300 B
build/block-library/blocks/file/editor.css 300 B
build/block-library/blocks/file/style-rtl.css 253 B
build/block-library/blocks/file/style.css 254 B
build/block-library/blocks/file/view.min.js 346 B
build/block-library/blocks/freeform/editor-rtl.css 2.44 kB
build/block-library/blocks/freeform/editor.css 2.44 kB
build/block-library/blocks/gallery/editor-rtl.css 948 B
build/block-library/blocks/gallery/editor.css 950 B
build/block-library/blocks/gallery/style-rtl.css 1.53 kB
build/block-library/blocks/gallery/style.css 1.53 kB
build/block-library/blocks/gallery/theme-rtl.css 108 B
build/block-library/blocks/gallery/theme.css 108 B
build/block-library/blocks/group/editor-rtl.css 337 B
build/block-library/blocks/group/editor.css 337 B
build/block-library/blocks/group/style-rtl.css 57 B
build/block-library/blocks/group/style.css 57 B
build/block-library/blocks/group/theme-rtl.css 78 B
build/block-library/blocks/group/theme.css 78 B
build/block-library/blocks/heading/style-rtl.css 76 B
build/block-library/blocks/heading/style.css 76 B
build/block-library/blocks/html/editor-rtl.css 327 B
build/block-library/blocks/html/editor.css 329 B
build/block-library/blocks/image/editor-rtl.css 876 B
build/block-library/blocks/image/editor.css 873 B
build/block-library/blocks/image/style-rtl.css 627 B
build/block-library/blocks/image/style.css 630 B
build/block-library/blocks/image/theme-rtl.css 110 B
build/block-library/blocks/image/theme.css 110 B
build/block-library/blocks/latest-comments/style-rtl.css 284 B
build/block-library/blocks/latest-comments/style.css 284 B
build/block-library/blocks/latest-posts/editor-rtl.css 213 B
build/block-library/blocks/latest-posts/editor.css 212 B
build/block-library/blocks/latest-posts/style-rtl.css 463 B
build/block-library/blocks/latest-posts/style.css 462 B
build/block-library/blocks/list/style-rtl.css 88 B
build/block-library/blocks/list/style.css 88 B
build/block-library/blocks/media-text/editor-rtl.css 266 B
build/block-library/blocks/media-text/editor.css 263 B
build/block-library/blocks/media-text/style-rtl.css 507 B
build/block-library/blocks/media-text/style.css 505 B
build/block-library/blocks/more/editor-rtl.css 431 B
build/block-library/blocks/more/editor.css 431 B
build/block-library/blocks/navigation-link/editor-rtl.css 705 B
build/block-library/blocks/navigation-link/editor.css 703 B
build/block-library/blocks/navigation-link/style-rtl.css 115 B
build/block-library/blocks/navigation-link/style.css 115 B
build/block-library/blocks/navigation-submenu/editor-rtl.css 296 B
build/block-library/blocks/navigation-submenu/editor.css 295 B
build/block-library/blocks/navigation-submenu/view.min.js 423 B
build/block-library/blocks/navigation/editor-rtl.css 1.96 kB
build/block-library/blocks/navigation/editor.css 1.96 kB
build/block-library/blocks/navigation/style-rtl.css 2.04 kB
build/block-library/blocks/navigation/style.css 2.03 kB
build/block-library/blocks/navigation/view-modal.min.js 2.78 kB
build/block-library/blocks/navigation/view.min.js 443 B
build/block-library/blocks/nextpage/editor-rtl.css 395 B
build/block-library/blocks/nextpage/editor.css 395 B
build/block-library/blocks/page-list/editor-rtl.css 363 B
build/block-library/blocks/page-list/editor.css 363 B
build/block-library/blocks/page-list/style-rtl.css 175 B
build/block-library/blocks/page-list/style.css 175 B
build/block-library/blocks/paragraph/editor-rtl.css 174 B
build/block-library/blocks/paragraph/editor.css 174 B
build/block-library/blocks/paragraph/style-rtl.css 260 B
build/block-library/blocks/paragraph/style.css 260 B
build/block-library/blocks/post-author/style-rtl.css 175 B
build/block-library/blocks/post-author/style.css 176 B
build/block-library/blocks/post-comments-form/editor-rtl.css 96 B
build/block-library/blocks/post-comments-form/editor.css 96 B
build/block-library/blocks/post-comments-form/style-rtl.css 493 B
build/block-library/blocks/post-comments-form/style.css 493 B
build/block-library/blocks/post-date/style-rtl.css 61 B
build/block-library/blocks/post-date/style.css 61 B
build/block-library/blocks/post-excerpt/editor-rtl.css 73 B
build/block-library/blocks/post-excerpt/editor.css 73 B
build/block-library/blocks/post-excerpt/style-rtl.css 69 B
build/block-library/blocks/post-excerpt/style.css 69 B
build/block-library/blocks/post-featured-image/editor-rtl.css 507 B
build/block-library/blocks/post-featured-image/editor.css 505 B
build/block-library/blocks/post-featured-image/style-rtl.css 166 B
build/block-library/blocks/post-featured-image/style.css 166 B
build/block-library/blocks/post-template/editor-rtl.css 99 B
build/block-library/blocks/post-template/editor.css 98 B
build/block-library/blocks/post-template/style-rtl.css 282 B
build/block-library/blocks/post-template/style.css 282 B
build/block-library/blocks/post-terms/style-rtl.css 73 B
build/block-library/blocks/post-terms/style.css 73 B
build/block-library/blocks/post-title/style-rtl.css 100 B
build/block-library/blocks/post-title/style.css 100 B
build/block-library/blocks/preformatted/style-rtl.css 103 B
build/block-library/blocks/preformatted/style.css 103 B
build/block-library/blocks/pullquote/editor-rtl.css 135 B
build/block-library/blocks/pullquote/editor.css 135 B
build/block-library/blocks/pullquote/style-rtl.css 326 B
build/block-library/blocks/pullquote/style.css 325 B
build/block-library/blocks/pullquote/theme-rtl.css 167 B
build/block-library/blocks/pullquote/theme.css 167 B
build/block-library/blocks/query-pagination-numbers/editor-rtl.css 122 B
build/block-library/blocks/query-pagination-numbers/editor.css 121 B
build/block-library/blocks/query-pagination/editor-rtl.css 221 B
build/block-library/blocks/query-pagination/editor.css 211 B
build/block-library/blocks/query-pagination/style-rtl.css 282 B
build/block-library/blocks/query-pagination/style.css 278 B
build/block-library/blocks/query-title/style-rtl.css 63 B
build/block-library/blocks/query-title/style.css 63 B
build/block-library/blocks/query/editor-rtl.css 439 B
build/block-library/blocks/query/editor.css 439 B
build/block-library/blocks/quote/style-rtl.css 213 B
build/block-library/blocks/quote/style.css 213 B
build/block-library/blocks/quote/theme-rtl.css 223 B
build/block-library/blocks/quote/theme.css 226 B
build/block-library/blocks/read-more/style-rtl.css 132 B
build/block-library/blocks/read-more/style.css 132 B
build/block-library/blocks/rss/editor-rtl.css 202 B
build/block-library/blocks/rss/editor.css 204 B
build/block-library/blocks/rss/style-rtl.css 289 B
build/block-library/blocks/rss/style.css 288 B
build/block-library/blocks/search/editor-rtl.css 165 B
build/block-library/blocks/search/editor.css 165 B
build/block-library/blocks/search/style-rtl.css 396 B
build/block-library/blocks/search/style.css 393 B
build/block-library/blocks/search/theme-rtl.css 114 B
build/block-library/blocks/search/theme.css 114 B
build/block-library/blocks/separator/editor-rtl.css 146 B
build/block-library/blocks/separator/editor.css 146 B
build/block-library/blocks/separator/style-rtl.css 233 B
build/block-library/blocks/separator/style.css 233 B
build/block-library/blocks/separator/theme-rtl.css 194 B
build/block-library/blocks/separator/theme.css 194 B
build/block-library/blocks/shortcode/editor-rtl.css 464 B
build/block-library/blocks/shortcode/editor.css 464 B
build/block-library/blocks/site-logo/editor-rtl.css 461 B
build/block-library/blocks/site-logo/editor.css 461 B
build/block-library/blocks/site-logo/style-rtl.css 192 B
build/block-library/blocks/site-logo/style.css 192 B
build/block-library/blocks/site-tagline/editor-rtl.css 86 B
build/block-library/blocks/site-tagline/editor.css 86 B
build/block-library/blocks/site-title/editor-rtl.css 84 B
build/block-library/blocks/site-title/editor.css 84 B
build/block-library/blocks/social-link/editor-rtl.css 184 B
build/block-library/blocks/social-link/editor.css 184 B
build/block-library/blocks/social-links/editor-rtl.css 674 B
build/block-library/blocks/social-links/editor.css 673 B
build/block-library/blocks/social-links/style-rtl.css 1.39 kB
build/block-library/blocks/social-links/style.css 1.39 kB
build/block-library/blocks/spacer/editor-rtl.css 322 B
build/block-library/blocks/spacer/editor.css 322 B
build/block-library/blocks/spacer/style-rtl.css 48 B
build/block-library/blocks/spacer/style.css 48 B
build/block-library/blocks/table/editor-rtl.css 494 B
build/block-library/blocks/table/editor.css 494 B
build/block-library/blocks/table/style-rtl.css 611 B
build/block-library/blocks/table/style.css 609 B
build/block-library/blocks/table/theme-rtl.css 175 B
build/block-library/blocks/table/theme.css 175 B
build/block-library/blocks/tag-cloud/style-rtl.css 239 B
build/block-library/blocks/tag-cloud/style.css 239 B
build/block-library/blocks/template-part/editor-rtl.css 235 B
build/block-library/blocks/template-part/editor.css 235 B
build/block-library/blocks/template-part/theme-rtl.css 101 B
build/block-library/blocks/template-part/theme.css 101 B
build/block-library/blocks/text-columns/editor-rtl.css 95 B
build/block-library/blocks/text-columns/editor.css 95 B
build/block-library/blocks/text-columns/style-rtl.css 166 B
build/block-library/blocks/text-columns/style.css 166 B
build/block-library/blocks/verse/style-rtl.css 87 B
build/block-library/blocks/verse/style.css 87 B
build/block-library/blocks/video/editor-rtl.css 561 B
build/block-library/blocks/video/editor.css 563 B
build/block-library/blocks/video/style-rtl.css 174 B
build/block-library/blocks/video/style.css 174 B
build/block-library/blocks/video/theme-rtl.css 110 B
build/block-library/blocks/video/theme.css 110 B
build/block-library/common-rtl.css 1.01 kB
build/block-library/common.css 1 kB
build/block-library/editor-elements-rtl.css 75 B
build/block-library/editor-elements.css 75 B
build/block-library/editor-rtl.css 10.9 kB
build/block-library/editor.css 10.9 kB
build/block-library/elements-rtl.css 54 B
build/block-library/elements.css 54 B
build/block-library/reset-rtl.css 478 B
build/block-library/reset.css 478 B
build/block-library/style-rtl.css 11.9 kB
build/block-library/style.css 11.9 kB
build/block-library/theme-rtl.css 695 B
build/block-library/theme.css 700 B
build/block-serialization-default-parser/index.min.js 1.1 kB
build/block-serialization-spec-parser/index.min.js 2.83 kB
build/components/index.min.js 197 kB
build/components/style-rtl.css 11.5 kB
build/components/style.css 11.6 kB
build/compose/index.min.js 12 kB
build/core-data/index.min.js 15.5 kB
build/customize-widgets/index.min.js 11.3 kB
build/customize-widgets/style-rtl.css 1.38 kB
build/customize-widgets/style.css 1.38 kB
build/data-controls/index.min.js 653 B
build/data/index.min.js 8.06 kB
build/date/index.min.js 32 kB
build/deprecated/index.min.js 507 B
build/dom-ready/index.min.js 324 B
build/dom/index.min.js 4.69 kB
build/edit-navigation/index.min.js 16 kB
build/edit-navigation/style-rtl.css 4 kB
build/edit-navigation/style.css 4.01 kB
build/edit-post/classic-rtl.css 546 B
build/edit-post/classic.css 547 B
build/edit-post/index.min.js 30.5 kB
build/edit-post/style-rtl.css 6.94 kB
build/edit-post/style.css 6.94 kB
build/edit-site/index.min.js 57.8 kB
build/edit-site/style-rtl.css 8.22 kB
build/edit-site/style.css 8.2 kB
build/edit-widgets/index.min.js 16.5 kB
build/edit-widgets/style-rtl.css 4.35 kB
build/edit-widgets/style.css 4.35 kB
build/editor/index.min.js 41.5 kB
build/editor/style-rtl.css 3.66 kB
build/editor/style.css 3.65 kB
build/element/index.min.js 4.68 kB
build/escape-html/index.min.js 537 B
build/format-library/index.min.js 6.75 kB
build/format-library/style-rtl.css 571 B
build/format-library/style.css 571 B
build/hooks/index.min.js 1.64 kB
build/html-entities/index.min.js 448 B
build/i18n/index.min.js 3.77 kB
build/is-shallow-equal/index.min.js 527 B
build/keyboard-shortcuts/index.min.js 1.78 kB
build/keycodes/index.min.js 1.81 kB
build/list-reusable-blocks/index.min.js 1.74 kB
build/list-reusable-blocks/style-rtl.css 835 B
build/list-reusable-blocks/style.css 835 B
build/media-utils/index.min.js 2.93 kB
build/notices/index.min.js 953 B
build/nux/index.min.js 2.05 kB
build/nux/style-rtl.css 732 B
build/nux/style.css 728 B
build/plugins/index.min.js 1.94 kB
build/preferences-persistence/index.min.js 2.22 kB
build/preferences/index.min.js 1.3 kB
build/primitives/index.min.js 933 B
build/priority-queue/index.min.js 612 B
build/react-i18n/index.min.js 696 B
build/react-refresh-entry/index.min.js 8.44 kB
build/react-refresh-runtime/index.min.js 7.31 kB
build/redux-routine/index.min.js 2.74 kB
build/reusable-blocks/index.min.js 2.21 kB
build/reusable-blocks/style-rtl.css 256 B
build/reusable-blocks/style.css 256 B
build/rich-text/index.min.js 10.4 kB
build/server-side-render/index.min.js 1.61 kB
build/shortcode/index.min.js 1.53 kB
build/token-list/index.min.js 644 B
build/url/index.min.js 3.61 kB
build/vendors/react-dom.min.js 38.5 kB
build/vendors/react.min.js 4.34 kB
build/viewport/index.min.js 1.08 kB
build/warning/index.min.js 268 B
build/widgets/index.min.js 7.2 kB
build/widgets/style-rtl.css 1.18 kB
build/widgets/style.css 1.19 kB
build/wordcount/index.min.js 1.06 kB

compressed-size-action

@mtias
Copy link
Member

mtias commented Sep 13, 2022

@oandregal @jorgefilipecosta it confused me a lot to see the value being noContent, that seems quite obscure. I understand in a sense we are doing the opposite of lock.content by only allowing content to be modified. But if that was the concern I'd suggest contentOnly or something else that is more clear.

@oandregal
Copy link
Member

Yeah, that was my concern. I've prepared #44131 to update noContent to contentOnly. I cannot find a better alternative and I agree noContent is confusing.

@fabiankaegy fabiankaegy added the Needs Dev Note Requires a developer note for a major WordPress release cycle label Sep 13, 2022
@fabiankaegy
Copy link
Member

I've just added the Needs Dev Note Label as I think this will be very impactful in WordPress 6.1 :)

CC: @bph

@femkreations femkreations added the Needs User Documentation Needs new user documentation label Sep 20, 2022
@richtabor
Copy link
Member

richtabor commented Sep 27, 2022

Just to be clear for documentation purposes (as I think the PR name may be a bit misleading) but this mechanism locks everything but content blocks, yea?

And should we refer to this as "Content-only locking"? Not too thrilled with that term myself.

@jameskoster
Copy link
Contributor

It locks child block position / layout, addition, and removal. Text and attributes like image source remain editable. The objective was to make complex groups feel more like single blocks.

"Content-only editing" might be better? "Group template" could be an option, but "template" is obviously a loaded word already. "Flattened groups"...? Naming is hard.

@adamziel
Copy link
Contributor

#44521 makes the new experimental/unstable selectors introduced in this PR private.

@fabiankaegy
Copy link
Member

Out of curiosity, is there a mechanism to limit which user roles have the ability to "Modify" the actual blocks?

CleanShot 2022-09-30 at 11 52 50@2x

I tried to look through the code to see whether it was possible but it didn't seem to be the case.

I think it would be a great addition to this feature to be able to control which user role levels have the ability to modify the actual block structure / vs which roles can only edit the content :)

Thanks in advance for any feedback :)

annezazu added a commit that referenced this pull request Oct 13, 2022
Building off of the launch of this new functionality in 6.1, this updates the curation resource to include information about content lock ability: #43037
@jasmussen
Copy link
Contributor

Created #45263 as a small followup that should be easy.

fabiankaegy pushed a commit that referenced this pull request Oct 28, 2022
* Updating curation document to include content lock ability

Building off of the launch of this new functionality in 6.1, this updates the curation resource to include information about content lock ability: #43037

* Slight update to the children blocks language

* Update to use "content only editing" and clarify block usage
@jorgefilipecosta
Copy link
Member Author

Out of curiosity, is there a mechanism to limit which user roles have the ability to "Modify" the actual blocks?

As referred to previously in a core editor chat, for now, we did not implement role-based restrictions, but it is something we can consider in the future. Thank you for the suggestion 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Patterns A collection of blocks that can be synced (previously reusable blocks) or unsynced Needs Dev Note Requires a developer note for a major WordPress release cycle Needs User Documentation Needs new user documentation [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

Successfully merging this pull request may close these issues.