Proposal: Add a "Rename Block" feature in List View

[samxmunoz]

Issue

The list view is a valuable tool for navigating throughout a page - but it can get confusing which "Column" or "Paragraph" (etc) corresponds to which item without hovering.

In addition, when passing off to clients it could be helpful to rename blocks in the List View for easier content updating instructions.

Proposed Solution

Add a "Rename Block" option, perhaps here (see screenshot):

[richtabor]

I agree. A different approach, but similar request to this issue here: #33583

[ronalfy]

I really like this idea.

Some of commented how this could be stored. Why not just HTML comments in the post content.? We’re already doing that anyways, and the labels are able to be exported pretty easily.

[Mamaduka]

Related PR #40393.

[jdcohan]

I do like this idea. My workaround has been to give (almost) every block an HTML anchor (which then shows up next to the block name in List View).

[samxmunoz]

Nice work around @jdcohan, however since HTML anchors can't have spaces, I assume it's not very "human readable".

[jdcohan]

Nice work around @jdcohan, however since HTML anchors can't have spaces, I assume it's not very "human readable".

@samxmunoz -
It works for my purposes:

(It is, after all, a workaround. And you might notice I'm reusing anchor names. Truth be told, in many cases I'm entering CLASS names as temporary HTML Anchors. That helps me with my CSS rules.)

All that said, I do like your feature request and would love for it to be implemented.

[JJJ]

I agree. A different approach, but similar request to this issue here: #33583

That issue and this one combined together is a single must-have UX enhancement IMO.

(Imagine using any other design software without the ability to rename/relabel your layers/tracks/groups/effects/etc...)

Whoever takes this on should take special care with what to name the feature and the data. We are quickly running out of synonyms for title/name/label/text/nickname type stuffs. 🍒

[TonyGravagno]

As to naming, I think this request subject should itself be renamed. The request is not really to rename a block, but to add context to a block.

To be specific, we don't want to rename Column, Group, or Paragraph, but to be clear that, as an example, the Pricing Column has Features Group which includes a Paragraph that describes a feature.

That is, this is about metadata. about a block instance.

I'm thinking this can be implemented within the existing markup:

<!-- wp:paragraph {
  "align":"center",
  "textColor":"background",
  "context-name":"Feature",
} -->
<p class="has-text-align-center has-background-color has-text-color">This is a feature!</p>
<!-- /wp:paragraph -->

Or consider putting all metadata in a single attribute:

"meta: {
  "context-name":"Feature",
  "save-callback":"maybeBlockChanged",
  "render-callback":"myBlockDisplayed"
},

(Hmmm, block callbacks on editor save or front-end rendering?)

The new context-name can be set like any other block detail, in the Settings sidebar - as can any other metadata later.

A wp_option can be set to display the context-name attribute before or after the block name - or instead of the block name where a context-name is available:

Undoubtedly, someone will later ask for custom styling on the context-names - including changing the colors, before/after surrounding characters, etc ... that detail would be in wp_options, not in each node.

I can also imagine requests to find blocks/nodes by context-name, to find all templates that include a block with a specific context-name, or even a global rename of a context-name.

I cannot think of other metadata that we would want. But assuming someone does come up with a useful request in the future, I think the code for adding and using metadata, and initially this context-name, should be well-documented from the start.

Good docs of the initial implementation would faciliate later enhancements, modularization (single function that processes all metadata for a node), hooks (dynamic text replacement in the List View based on page or template?) and other requests that seem likely but that we just can't conceive yet.

[getdave]

Related

#42605
#40393

[getdave]

@Mamaduka Should we close this one in favour of canonical #33583?

[Mamaduka]

@getdave, that makes sense to me 👍

Closing as "duplicate".