-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Full Site Editing: Template block names, descriptions, and placeholders #26856
Comments
I myself have to admit seeing a sea of 'post' before blocks did make me think of ways to do this better. This is a great summary @jameskoster. My own preference would be to remove the 'post' and I think that works in most, if not all cases. I am really keen on the tidying of placeholders, after stumbling onto some myself and finding them to needs some iterations, I really like these suggestions. |
In which cases do you not think it works? Let's refine! |
I think for me it's where some are really close to others, it works but it's open to interpretation and that's not solved by removing or not the 'post', there is a deeper issue to also explore. I don't want to derail this issue but will loosely explain. For example, 'tag' results now in: Another, 'comments': Here my concern is between comment and comments specifically. That isn't solved by the post before though, which is why I agree in having this iteration. |
The only conflict I see is: The other 2 I am lightly concerned with are just a little 'rough' considering close counterparts. They aren't the end of the world, but it seems odd to have one version with a descriptive prefix and one without:
|
If we can settle on an appropriate generic prefix I think that would solve these issues, but I'm struggling for ideas there. "Post" is misleading as outlined in the OP. "Content" feels ok... "Content Title", "Content Author", etc. But what do we do with the Content block? We can't have "Content Content" :D Perhaps "Entry" could work instead? 🤔 Then again maybe context will be adequate in making the blocks feel intuitive. If I'm editing my product template and see a "Title" block, I think it would be fairly intuitive what the purpose of that block is. Likewise if I'm editing an archive, etc. I'm inclined to suggest that we start with the simplest convention, and expand if required. |
Originally I was thinking that lack of prefix might make sense for most of them. And only the ones with conflicts or similar names need to be expanded upon. BUT this does create an inconsistency throughout the group of these entity blocks.
Perhaps! Going through this list of blocks and changing "Post" to "Entry" seems like it might be a bit of a step up while preserving the consistency in prefix. Although I wonder how clear "Entry" is as well. Would a new user consider a page to be an entry? If I try to put my NU hat on I could see interpereting 'Entry' as something like a post and not a page as well. 🤔 That said, it definitely has the benefit over "Post" in not confusing between the postType 'post' and the fact that everything is a Post of some type. |
Yeah, I feel like we're combining two subtly different issues here, and they should probably be separated and addressed sequentially:
I think it is difficult to determine whether the second point is true without first seeing how the blocks behave in context. IE when you're in the flow of editing a template / template part. Like you said, they may feel a little rough, and if they do we can open another issue to explore solutions. |
I would add: |
For 3, could we consider renaming the existing "Categories" block to "Post Categories", since that block only returns |
So rename the existing "Categories" block to "Post Categories", and the existing FSE "Post Categories" block to "Categories"? Couldn't this swap create a fair amount of confusion? |
Only if you're a regular user of both blocks, and in that case the icon still offers some familiarity. I don't suppose there are all that many people using the FSE categories block seeing as all FSE features are basically still in beta. |
True! Although the standard "Categories" block goes beyond FSE. On a development note, I am not sure if adding backwards compatibility to rename "Categories" to "Post Categories" would be messed up if we have another block renamed from "Post Categories" to "Categories" as well. 🤔 That is, Im not sure if we can swap those markup names |
We definitely can't swap the block names (core/*) without breaking changes. Though I'm really curious what we'd want to swap things here ?
|
I'm not sure I agree with the removal of the "post" prefix in these block names (all of them actually). A "Page" is a "post" in WordPress Land. Post has actually two different meaning in WordPress and in this particular case, we're just using the "Post Type" one. For me it's important to keep the connection to "post type" somehow in the title. |
That isn't true for categories that are added as a custom taxonomy though, correct? For example WooCommerce adds categories for products, but those wouldn't appear in the "Categories" block. For a site owner running a store more than a blog, I think they would expect a generic "Categories" block to display their product categories. The notion of swapping was to purely make the block name more explicit.
So is that block restricted to the
Totally understand that, but it is a concept that I suspect is lost on the vast majority of users. It seems unlikely that the average person understands that a Page is a
I suppose there are a couple of options there...
Any preferences or other options there? |
The block uses To give more context the "categories" block was built as a drop-in replacement for the "categories" widget but it should be seen as a starting point.
No, it's not, it's for any post type. But it's important to understand that it shows categories of a "single post", the one being rendered. (that could be of any post type). That is the main difference between, the two blocks.
These Post* blocks are essentially for themers (for now) and I don't really expect these users to not know that. I'm all for finding a better wording but I do think having a prefix here that is consistent across all the
No, we shouldn't be doing that, that block can be dropped in a "single.html" template and work the same depending on the post type of the post being rendered.
I still think there's history with "Post" being the generic name for these in WordPress and I'm really very unsure whether we should be changing that adhoc in these blocks. I like "Entry" but it's too generic, a category can be an entry too. So I still have a preference for the current names personally. |
I appreciate that most people using the site editor at first will probably be able to understand this convention, but one of the most exciting things about the FSE project is making the theme editing experience more accessible to less tech-savvy users. So down the road I still think that seeing a "Post Title" block in the "Page" template could confuse people. Atm I am kind of leaning towards "The Title" and "The Content" because it makes sense for any post type and harmonises with the template tags that existing themers will be familiar with. It doesn't translate well to the post editor, but I'm not sure how often these blocks will be used in that context. Having said that, I am also happy to stick with the "Post" prefix and address it later if needed. For now we can focus on the descriptions and placeholders. |
Are we ready to continue with updating the descriptions and placeholder contents? |
@carolinan yes, we need to. Previews are also missing for most of these blocks. We may need to break this down in to smaller issues though as it is quite a big task. I opened #30029 for the placeholders/previews specifically, which feels like the most pressing item. |
Closing this in favor of #35501 |
We currently have a variety of blocks with names that are prefixed "Post":
This prefix can be misleading as these blocks will render the content of any post type. When editing a Page template for example, it is confusing to see a "Post Title" block, since that template will only resolve to display pages, not posts. It gets even more confusing with ambiguous templates like Single, Singular, Index...
Below is a table of the existing template blocks along with what I think we should try renaming them to, updated descriptions, and placeholder content where appropriate.
Todays date
Todays date
Post Comment
innerblock.Note: You'll notice the repetition of "a post, page, or any other content-type". I'm sure we can find a more succinct way to say this.
Putting everything together, we can gather a rough idea of what editing the
Single
template from the Twenty Twentyone theme might look like:Related items:
The text was updated successfully, but these errors were encountered: