-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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 search block #13583
Add search block #13583
Conversation
7e82e51
to
5778c3c
Compare
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.
Just did a short test, works great. Just one improvement: If I add a custom class, it is not added to the form.
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.
Let's also update CHANGELOG.md
and request minor version update for the next package release.
We discussed that yesterday during Core JS weekly chat: https://make.wordpress.org/core/2019/01/29/javascript-chat-summary-january-29-2019/
@Soean - I realized we didn't do it for RSS block, so it would be good to open a separate PR and fix that.
|
||
return ( | ||
<Fragment> | ||
<div className="wp-block-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.
Should it be also using form
to ensure that CSS is properly applied if someone uses a tag name specific selectors?
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 that likely? We already have the problem of the <label>
being a <div>
because of some RichText
. Making this a <form>
means that we'd have to add a onSubmit={ ( event ) => event.stopPropagation() }
which I find a little distracting.
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 don't know what is the best way moving forward, I just wanted to raise this so we could discuss and come up with something solid as this is going to be replicated in other places :)
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 prefer to leave it how it is. We ought to encourage edit()
and save()
having whatever markup is appropriate for the task at hand. Semantically, what we have here is not a form.
Yes, it is close to being ready in my opinion. If we apply changes by the end of the week we can move it to 5.0 (Gutenberg) milestone 🎉 |
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 had a couple of minor nitpicks, but this looks good 😄
return ( | ||
<Fragment> | ||
<div className="wp-block-search"> | ||
<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.
I think this should have an aria-label
—other blocks seem to achieve that by using the placeholder
prop. Also perhaps multiline={ false }
?
edit: multiline={ false }
doesn't seem to prevent multiple lines. Bug?
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.
Good catch—added the placeholder
prop so that there's a label.
#13570 is a ticket that tracks adding multiline={ false }
which looks like it was removed a while ago. For now, I think it's fine to support line breaks—I can't think of any reason we ought to forbid them! 🙂
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.
Was sure I could remember multiline={ false }
working in the editor, but I must have dreamed it 😴. My feeling is that it's a bit unusual for a label to be multiple lines.
Thanks for the fixes, will re-review in a bit.
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.
You didn't dream it! 😀 I think that we removed support for multiline={ false }
when refactoring how RichText
works in the lead up to 5.0.
I did a little audit of line breaks in the Search block's attributes and I'm OK with how it is currently:
label
:<br>
s are allowed in a<label>
so we permit it. This is consistent with e.g. captions in the Image block.placeholder
:<br>
s or\n
s are not allowed in aplaceholder=""
so we forbid it.buttonText
:<br>
s are allowed in a<button>
so we permit it. This is consistent with e.g. the button text in a Button or File block.
@michelleweber would you mind helping to polish translations proposed? |
Adding the Accessibility label in addition to the "needs..." one so the team can search for all the widget-blocks related issues in an easier way. |
It would be great for this block to not encourage the use of placeholders as replacement for labels, see https://core.trac.wordpress.org/ticket/40331 So instead of a default
More importantly: On top: the new search block, followed by the classic search widget: For accessibility a search form should always have a button |
Sure, you can specify what bits exactly you'd like reviewed? |
@melchoyce They may be putting On that note, I think the search button should have a visible label as well... actually, why not allow the user to edit the button text as well? |
If the search button had a visible label, what would be ideal? I don't think it makes sense for us to use Search as an input label, and a button label. |
I'd tend to think the visible label should be in the hands of the authors. Gutenberg shouldn't force a search field with no visible, properly associated, If authors opt to not have a visible label, then that's their responsibility. Ideally, in the same way Gutenberg does for the headings hierarchy and color contrast, a visible label should be the recommended option. Authors should be educated, not forced to follow an opinionated choice. |
@melchoyce I guess "Submit", "Go", or "Enter" would be fine defaults if "Search" isn't used for the button label. Alternatively, the button could be labeled "Search" and the label preceding the search input could be "Search this site" or something like that by default. Whatever the case, both the preceding label and button should be editable. |
@@ -0,0 +1 @@ | |||
<!-- wp: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.
The fact that this markup does not match core__search__custom-text.html
should be alarming; it's the entire purpose of these fixtures to guarantee.
<!-- wp:search {"label":"Custom label","placeholder":"Custom placeholder","buttonText":"Custom button text"} /--> |
Running npm run fixtures:regenerate
locally seems to produce some changes for me which produce a result more to what's expected.
However, it's still very concerning that:
- The build passes despite these markups being entirely different
- The build passes despite there being local changes to commit after running
npm run fixtures:regenerate
Edit: Upon further investigation, it's not strictly accurate for me to claim that the entire point of these fixture tests is to verify equivalence between the original and serialized sources. In many cases, this is true (or at least they should be "equivalent"). Others, we're clearly testing for a different result (e.g. core__text__converts-to-paragraph
). However, the fact we're not programmatically enforcing some equivalence in the majority of cases leads to situations just like this one where we aren't carefully considering whether the serialized output makes sense given the input (in this instance, it definitely doesn't). I'd conclude that we need to either (a) enforce some equivalence between the original and serialized outputs and make exceptions only where appropriate, (b) in some other way enforce some consciousness about the serialized output, or (c) abandon the fixtures tests altogether.
Related:
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.
See #14122 for fix
* Adding search widget block Co-authored-by: Rachel Cherry <[email protected]> * Search block: Move away from legacy get_search_form() markup Changes the Search block to render its own search form markup, instead of the same markup that get_search_form() renders. This lets us fully match the design spec. * s/Placeholder text/Placeholder Text/ Co-Authored-By: noisysocks <[email protected]> * Remove superfluous 'your' Co-Authored-By: noisysocks <[email protected]> * Search: Add button and inline placeholder editing * Update CHANGELOG * Search block: Support custom CSS classes * Search block: Add aria-label to placeholder <input> * Search block: Style label as bold in theme.scss * Search block: Add aria-label to all inputs * Search block: Use ellipsis at end of input placeholders * Search block: Display placeholder in 'placeholder' attribute, not 'value' * Revert "Search block: Display placeholder in 'placeholder' attribute, not 'value'" This reverts commit 154cddc. * Search block: Remove placeholder attribute when there is a placeholder value * Search block: Fix placeholder attribute receiving false instead of undefined
* Adding search widget block Co-authored-by: Rachel Cherry <[email protected]> * Search block: Move away from legacy get_search_form() markup Changes the Search block to render its own search form markup, instead of the same markup that get_search_form() renders. This lets us fully match the design spec. * s/Placeholder text/Placeholder Text/ Co-Authored-By: noisysocks <[email protected]> * Remove superfluous 'your' Co-Authored-By: noisysocks <[email protected]> * Search: Add button and inline placeholder editing * Update CHANGELOG * Search block: Support custom CSS classes * Search block: Add aria-label to placeholder <input> * Search block: Style label as bold in theme.scss * Search block: Add aria-label to all inputs * Search block: Use ellipsis at end of input placeholders * Search block: Display placeholder in 'placeholder' attribute, not 'value' * Revert "Search block: Display placeholder in 'placeholder' attribute, not 'value'" This reverts commit 154cddc. * Search block: Remove placeholder attribute when there is a placeholder value * Search block: Fix placeholder attribute receiving false instead of undefined
sorry to have to ask here, but searched everywhere. which block does one use to display the search results? block template linked to the search slug renders but which block do we use in that block template to display the paginated search results? thanks. |
There isn't a block to display search results, yet. Right now the search block will take the user to a page which uses the search WordPress template. |
i see. thanks. we are building a number of pure gutenberg only sites right now, using the block wp_template to theme template mapping so that the only php template file we have is a functions file, no template files other than that, everything else is pure blocks and block templates. we have every feature working on all the sites so far using only blocks except search results. looks like we'll have to write a custom block for that one last piece. pure gutenberg sites are soooo close, this is the last piece. 👍 |
Agree they're close! After you've built a custom search results block, I'd strongly encourage you to contribute it to Core by opening a PR in this repository. WordPress is better together! 💪 |
Continuation of #4501.
Closes #1800.
Implements the design in #1800 (comment).
Adds a Search block allowing users to place a search field anywhere they like.
get_search_form()
, see Adding core search widget block #4501 (review) for contextProps to @bamadesigner for all her hard work on this in #4501.
To test