-
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
Query Title: add Search and 404 page titles #33515
Conversation
# Conflicts: # lib/blocks.php # packages/block-library/src/index.js # packages/block-library/src/query-title/block.json # packages/block-library/src/query-title/edit.js # packages/block-library/src/query-title/index.js # packages/block-library/src/query-title/index.php # packages/block-library/src/query-title/variations.js
Based on original work in WordPress#27989
Merged in by mistake
👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @mikachan! In case you missed it, we'd love to have you join us in our Slack community, where we hold regularly weekly meetings open to anyone to coordinate with each other. If you want to learn more about WordPress development in general, check out the Core Handbook full of helpful information. |
}, | ||
{ | ||
name: 'search-title', | ||
title: __( 'Search Title' ), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do these need to be variations or could we just infer from context what to display? As a template author, what happens if I only have index.html
with archive title added?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we're able to infer what to display from the page context that would work better I think. This would be much quicker for creating and editing templates. I'll look into this, thanks!
} else { | ||
titleElement = ( | ||
<div { ...blockProps }> | ||
<RichText |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason to use RichText here rather than an H* element like we do for the Archive title?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure actually, I pulled this from the previous work on the search title in #27989. I'm guessing the intent was to use the additional functionality you get from RichText, but using the H* / TagName would be easier to read and maintain because there are fewer props. I'll try it out with just the H* tag.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
RichText
should be used if text is meant to be editable
👋 - thanks for working on this! Why would we need a |
The main benefit is for i18n. If we just add a title that says "Nothing found" then it won't be translated, whereas a block like this will be. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for working on this @mikachan !
I've left some comments and in general I'm not sure what we gain by not using block variations. Is it mostly because we want users to insert just one block (Query Title
) in archive, search, and 404
? What are other benefits and how they are compared to block variations benefits/restrictions.
In addition if we go this way, we should add a deprecation for this block (removal of type
attribute).
if ( $is_archive ) { | ||
$title = get_the_archive_title(); | ||
} | ||
if ( $is_search ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nitpick: we could make this elseif
.
); | ||
|
||
// Use placeholder content if new Query Title block is added | ||
if ( content === '' ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We shouldn't add the placeholder to content here as the user will not be able to clear the input and write something new.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah yeah I can see this problem when I try to clear the input. If I use a non-empty default placeholder such as 'Query title' rather than checking for an empty string, it looks like I can clear the input safely from the editor.
I'm not sure this is the correct fix though, as this logic was mainly because my use of useEffect
was overwriting the custom content when a new query title block was added. I'll try and fix this as part of a useEffect
refactor.
case 'archive': | ||
// translators: Title for archive template. | ||
content = _x( 'Archive title', 'archive template title' ); | ||
titleElement = <TagName { ...blockProps }>{ content }</TagName>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
content
is not used in archive
so there is no reason to assign it to content.
It should be <TagName { ...blockProps }>{ _x( 'Archive title', 'archive template title' ) }</TagName>;
case '404': | ||
// translators: Title for 404 template. | ||
content = _x( 'Nothing found', '404 template title' ); | ||
titleElement = <TagName { ...blockProps }>{ content }</TagName>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO this should be editable. I don't think every user should want Nothing found
as a title without the ability to change it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If they want to edit it can't they just add their own heading block?
} | ||
|
||
// Update content based on current template | ||
useEffect( () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems hacky to me 😄 . We use React's implementation details to update the content after the first render and by updating the content
attribute, we also create an undo
level in history. That's one of the reasons I had block variations in mind back then. The php
handling remains the same, the above content
attribute handling is done by the variations and we can provide a bit more specific info for the block (BlockCard etc..).
An alternative, if this approach is preferred, is to use __unstableMarkNextChangeAsNotPersistent
here and a new variable for the first content
(to avoid changing the existing content
var).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Haha I wasn't sure where else to turn so I jumped to useEffect
! Thanks so much for the detailed explanation.
As soon as I moved this logic from the variations file to edit.js, I could see the advantage of using variations. However, as @scruffian has just mentioned above, I think the advantage to not using variations is that the user (or a theme) only needs to insert one block, and the block works the content out itself based on context (i.e. the template).
With that in mind, I'm going to attempt your suggested alternative. Thanks for the suggestion and input, it's really helped me understand this more.
Content is not used in archive
This allows the user to delete the block content and write something new
The benefit I see is it means a simple theme can just have one index.html and the block will handle all scenarios... |
I can't see this unless I'm missing something. If you have only an So in cases like |
Yeah I see what you mean, the way I've currently structured this means that this block still wouldn't work by itself on a single I'm not sure how (or the best way) to achieve this... I think one of the biggest things I'm struggling with for the single Another approach I've just been trying out is allowing users to set the title content from the Inspector Controls in the right sidebar. With this, I'm thinking the block would show placeholder text (similar to how the archive title currently works), and then the user could customise the title variation contents in the sidebar, with something like this: My latest commits are for this approach, although not fully tested yet, it's more of a proof of concept at the moment. Any thoughts on this would be appreciated, and apologies for any lack of understanding on my part! |
The way I see if, if the block is used on a page on which it doesn't have any default content then it would simply output nothing. That's what I added the early return and changed the default content to an empty string. I'm not a fan of the idea of putting the content in the sidebar as we want the default experience to be one of direct manipulation. |
"type": { | ||
"content": { | ||
"type": "string", | ||
"default": "Query title placeholder" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd avoid non-translatable default values in block.json
attributes
.
Put the default text in the edit component instead and make it translatable.
} | ||
$tag_name = isset( $attributes['level'] ) ? 'h' . (int) $attributes['level'] : 'h1'; | ||
$align_class_name = empty( $attributes['textAlign'] ) ? '' : "has-text-align-{$attributes['textAlign']}"; | ||
$wrapper_attributes = get_block_wrapper_attributes( array( 'class' => $align_class_name ) ); | ||
if ( 'Query title placeholder' === $title || empty( $title ) ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As per my other comment, this should be translatable
Now defaults to empty string
Allow search and 404 titles to be edited via usual block editor
Content attribute no longer exists
Yeah, I agree. It's a bit of an odd pattern as well as I'm guessing we'd never really want users editing content via the settings controls. I tried this as a way to allow the user to edit multiple types of title context at once, but I think maybe I'm over-complicating things... I've just pushed some changes that go back to using the editor as usual, with a couple of tweaks:
My aim here was to capture both allowing the user to edit the search and 404 titles when they're added to specific templates, but if not, still allow for a context-based title if the block is added to the |
I talked to @mtias about this and we decided that this is an unnecessary optimisation that can make things worse for the user. By providing specific search and 404 templates, we will make it easier for users to understand which template relates to which page. If we want everything to inherit from index that actually makes it harder for users to understand the templating system. However, if the user has search or 404 templates then they can easily make edits to them. On the other hand, if the user does not have search or 404 templates then nothing will break, the page titles on the 404 and search pages will just be empty. |
Description
This PR addresses #33476 and is predominantly based on the work in #27989.
The change re-introduces a search title to the Query Title block from #27989 and adds a new 404 title to the same block. Both use the
_x()
function to provide translatable titles: "Search results for %search%" is used for the search title and "Nothing found" is used for the 404 title.I've tried to be as mindful as possible of the previous discussion in #27989 and cherry-picked the search title changes in line with the current archive title, but I'd love to get some ideas on any other approaches or thoughts.
How has this been tested?
In emptytheme and Blockbase by using the editor to add Query Title blocks to the search, 404, archive, and index templates.
Screenshots
Types of changes
Non-breaking change which adds functionality.
Checklist:
*.native.js
files for terms that need renaming or removal).