Add search block

[noisysocks]

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.

• Users can customise the label by editing it inline
• Users can customise the placeholder text using the block inspector
• Our own custom markup is used instead of get_search_form(), see Adding core search widget block #4501 (review) for context

Props to @bamadesigner for all her hard work on this in #4501.

To test

1. Create a new post
2. Insert the Search block
3. Publish the post
4. Type a query into the search field you just added
5. Press Enter

[Soean]

Just did a short test, works great. Just one improvement: If I add a custom class, it is not added to the form.

[gziolo]

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.

[gziolo]

Should it be also using form to ensure that CSS is properly applied if someone uses a tag name specific selectors?

[noisysocks]

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.

[gziolo]

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 :)

[noisysocks]

😄 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.

[gziolo]

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 🎉

[talldan]

I had a couple of minor nitpicks, but this looks good 😄

[talldan]

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?

[noisysocks]

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! 🙂

[talldan]

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.

[noisysocks]

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 \ns are not allowed in a placeholder="" 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.

[gziolo]

@michelleweber would you mind helping to polish translations proposed?

[afercia]

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.

[afercia]

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 Enter a search keyword or phrase I'd consider to either:

• leave it empty by default and keep the placeholder setting in the sidebar (even if the sidebar is not ideal for the reason @gziolo mentioned)
• or use a default Optional placeholder... which of course is not rendered in the front end, and explore to make the field editable as @gziolo proposed, thus removing the setting from the sidebar

More importantly:
I'm not sure why this block is removing the Search button. The classic Search widget prints out a search button and that's recommended and expected.

On top: the new search block, followed by the classic search widget:

For accessibility a search form should always have a button

[michelleweber]

Sure, you can specify what bits exactly you'd like reviewed?

[melchoyce]

Looking at some major sites (Google, Amazon, Twitter, Amazon) their search fields don't have a visible label — are they doing something else to make it a11y-compliant?

Quick idea to include a button, based on how some of the aforementioned sites do it:

[ZebulanStanphill]

@melchoyce They may be putting aria-labels on their search bars. However, this is less-than-ideal; visible labels should always be preferred.

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?

[melchoyce]

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.

[afercia]

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, <label> element over an aria-label. That would mean forcing a decreased level of accessibility.

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.

[ZebulanStanphill]

@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.

[aduth]

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.

gutenberg/test/integration/full-content/fixtures/core__search__custom-text.html

Line 1 in dffa8d3

<!-- 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:

• Refactor: Move block fixtures to e2e-tests package #13658 (comment)
• Testing: Remove beautification from block fixtures #8294

[aduth]

See #14122 for fix

[JoshuaJarman]

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.

[noisysocks]

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.

[JoshuaJarman]

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. 👍

[noisysocks]

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! 💪