[Block Library]Rename Query and QueryLoop blocks to QueryLoop and PostTemplate respectively #32283
Conversation
ntsekouras
added
[Package] Block library
ntsekouras
requested review from
mcsf,
youknowriad,
mtias,
aristath,
gziolo,
jameskoster,
jasmussen,
priethor and
a team
ntsekouras
requested review from
ajitbohra,
nerrad,
ntwb,
spacedmonkey and
TimothyBJacobs
as code owners
|
Size Change: -870 B (0%) Total Size: 1.03 MB
ℹ️ View Unchanged
|
|
Why not just leave the code-level naming as it is, and update the user-facing naming? Most users will never see the code-level naming anyway. |
|
Big +1 from me on making these block names (and descriptions – that can come later I suppose) more user-friendly. A couple of thoughts on the proposals here: I'm not convinced that adding "Loop" to the Query block name really helps all that much. I acknowledge that if you're a WordPress developer then "Loop" aids recognition of the block purpose, but does it communicate that message more clearly than "Query" on its own? For the average user, "Query" and "Loop" are equally challenging, but since this is a more technical, template-centric block that might be ok? The key here will probably be getting the description right. We should be mindful of using the "Template" label in a block name due to the fact that templates already exist as a different (and complex) feature. Anything that muddies the waters there probably isn't super helpful. That said I'm struggling to come up with a better suggestion :D Perhaps "Post" alone might work, if we describe its template-like nature in the description? Otherwise we're kind of scrambling around for "template" synonyms. |
That could be a way simpler option in terms of changes, but it would be inconsistent with all the other blocks and could definitely create confusion for the users that will see the code, like theme authors. |
|
Great refactor @ntsekouras, everything seems to work as expected! As far as the new names themselves, I'm on the same boat as @jameskoster. Moreover, I believe both blocks should have a similar name that lets users understand the inner block belongs to the parent, similarly to If I were to suggest a different naming approach, |
|
Thinking about the UX relationship between the query block and its variations (like the Posts List – #32268) I wonder if something like this might work:
So when you insert the Posts block on its own, it behaves as a custom query with all the associated display options and filters, and simplified structure (no pagination). But when it is wrapped inside the Global Query block (which is only available when editing a template) then... you guessed it, it inherits the query from the URL. In this case the layout options remain and pagination can be added, but the filters are removed. |
@jameskoster That actually involves technical implications with innerBlocks and query context, and |
Inconsistent with other blocks how? Isn't the whole idea of block variations to show a different name to the user from what's in the code? If there are going to be multiple variations with different names, then at least one will have to be mismatched with the code. Given that's unavoidable, you might as well avoid inflicting a breaking change after a months-long "outreach program" that has encouraged users to add this block to their sites. (I can't believe this actually has to be explained.) |
|
I'm basically describing the Posts variation of the Query block which we have an issue for here: #32268. In terms of this PR, it would still just be a case of updating the names (and probably the icons). This feels like a good step in isolation, but it's really just one small part of a bigger puzzle. I'm trying think a little more holistically about the UX we want to create in #30910, and aim for that while working on these smaller pieces. I totally appreciate the the underlying technicals that will connect all these things would need to happen separately. |
As you can see this renaming is under discussion and not finalized. There might be no renaming at all depending on the feedback. This PR handles the 'bigger' approach and if go with the renaming and we end up changing just the |
|
If we were doing a block name change we would likely add a case for handling the name, like we have done with other block renames without breaking anything. That said, I think |
I can make these changes to move this forward. So the final question is if we rename |
|
I still think something simple like "Posts" can potentially work for both the Query Loop and a Query variation for displaying posts. If I insert a "Posts" block I see all the options to create my custom query like so:
But if I put a "Posts" block inside a Query block in the template editor then the options from before aren't available – they are inherited from the Query instead:
In terms of UX, the result is the perception of a single block for displaying posts regardless of context (post editing or template editor). The posts can be specific, or inherited from the global query. This is of course based on the notion that the Query block itself is restricted to the template editor. To reiterate, these are different blocks that use the same name and description. So I acknowledge we'd need to figure out things like how/when they appear in the inserter to avoid duplication. That seems relatively straight-forward though... the Perhaps this is too far out, I don't know :) But it seems important to consider not only the names of these blocks in isolation, but other parts of the UX, such as exactly where the Query block will be surfaced, the names of Query variations, and so on. |
I think this PR can be limited to the base/generic names for the blocks. The block variation proposal for handling things differently through So we should take into account that we could have a possible handling through variations but we need to decide on the best name for |
|
In that case "Post Template" seems like a fair solution, at least as an interim. It's certainly an enhancement on "Query Loop" :) I still have some reservations about using the term "Template" but don't really have any alternative suggestions. We should probably update the description of this block as well, perhaps something like:
The Query block itself could do with a better description too, but that is a little tricker as it currently has to account for multiple contexts (inheriting from URL or not). Perhaps that can wait until we know for sure whether it will actually be surfaced in the post editor or not. |
ntsekouras
force-pushed
the
rename/query-and-loop
branch
from
86be9de to
fcf36f2
Compare
|
I'm closing this in favor of #32514. It was much simpler to create a new PR than reverting so many renamings here that included Please continue the discussions in the new PR. |
ntsekouras
removed
the
Backport to WP 6.7 Beta/RC
Description
Part of: #30910
This PR rename
QueryandQueryLoopblocks toQueryLoopandPostTemplaterespectively.Notes
QueryLoopandunregisterthe coreQuerypatterns. If this lands we'll need to make the pattern changes and back port to core as well.Queryblock but this is not needed right now as the block has been renamed, so I have deleted it in this PR.tt1-blocksversion with the old block. This produces block invalidations and thereforeconsole.errorlogs that make the tests fail. I'll look into this more but this must be done in coordination with the update oftt1-blocktheme and then update the version that GB tests are using. I have created a draft PR intheme-experimentsrepo here: [tt1-blocks]: Update Query block renaming theme-experiments#265Please test carefully and if you have some time it would be great to check about any missing strings that might be used for example in css class names or such details. I think I've covered it all but lots of moving parts with renaming. Also be vigilant with the fact that the
Queryblock has been renamed toQueryLoopso it might be a bit confusing to see the changes asQueryLoopwas an existing block.Testing instructions
Queryblock in a page/FSE and make changes in editor and view front-end as well.