Skip to content
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

Merged
merged 15 commits into from
Feb 7, 2019
Merged

Add search block #13583

merged 15 commits into from
Feb 7, 2019

Conversation

noisysocks
Copy link
Member

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.

search

  • 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

@noisysocks noisysocks added [Feature] Blocks Overall functionality of blocks New Block Suggestion for a new block Needs Design Feedback Needs general design feedback. [Feature] Widgets Screen The block-based screen that replaced widgets.php. Needs Accessibility Feedback Need input from accessibility labels Jan 30, 2019
@noisysocks noisysocks added this to the 5.1 (Gutenberg) milestone Jan 30, 2019
@noisysocks noisysocks mentioned this pull request Jan 30, 2019
3 tasks
@gziolo gziolo requested a review from ajitbohra January 30, 2019 08:26
Soean
Soean previously requested changes Jan 30, 2019
Copy link
Member

@Soean Soean left a 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.

gziolo
gziolo previously requested changes Jan 30, 2019
Copy link
Member

@gziolo gziolo left a 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">
Copy link
Member

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?

Copy link
Member Author

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.

Copy link
Member

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

Copy link
Member Author

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.

@gziolo
Copy link
Member

gziolo commented Jan 30, 2019

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 🎉

Copy link
Contributor

@talldan talldan left a 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 😄

packages/block-library/src/search/edit.js Outdated Show resolved Hide resolved
packages/block-library/src/search/index.js Outdated Show resolved Hide resolved
packages/block-library/src/search/edit.js Outdated Show resolved Hide resolved
return (
<Fragment>
<div className="wp-block-search">
<RichText
Copy link
Contributor

@talldan talldan Jan 30, 2019

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?

Copy link
Member Author

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

Copy link
Contributor

@talldan talldan Jan 31, 2019

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.

Copy link
Member Author

@noisysocks noisysocks Jan 31, 2019

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 \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 gziolo added the Needs Copy Review Needs review of user-facing copy (language, phrasing) label Jan 30, 2019
@gziolo
Copy link
Member

gziolo commented Jan 30, 2019

@michelleweber would you mind helping to polish translations proposed?

@afercia afercia added the [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). label Jan 30, 2019
@afercia
Copy link
Contributor

afercia commented Jan 30, 2019

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
Copy link
Contributor

afercia commented Jan 30, 2019

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:

screenshot 2019-01-30 at 14 54 26

For accessibility a search form should always have a button

@michelleweber
Copy link

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

@melchoyce
Copy link
Contributor

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:

image

@ZebulanStanphill
Copy link
Member

@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
Copy link
Contributor

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
Copy link
Contributor

afercia commented Jan 30, 2019

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
Copy link
Member

@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 /-->
Copy link
Member

@aduth aduth Feb 25, 2019

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:

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See #14122 for fix

youknowriad pushed a commit that referenced this pull request Mar 6, 2019
* Adding search widget block

Co-authored-by: Rachel Cherry <bamadesigner@gmail.com>

* 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 <robert@noisysocks.com>

* Remove superfluous 'your'

Co-Authored-By: noisysocks <robert@noisysocks.com>

* 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
youknowriad pushed a commit that referenced this pull request Mar 6, 2019
* Adding search widget block

Co-authored-by: Rachel Cherry <bamadesigner@gmail.com>

* 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 <robert@noisysocks.com>

* Remove superfluous 'your'

Co-Authored-By: noisysocks <robert@noisysocks.com>

* 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
@JoshuaJarman
Copy link

JoshuaJarman commented Mar 31, 2020

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
Copy link
Member Author

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
Copy link

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
Copy link
Member Author

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

This was referenced Apr 30, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Blocks Overall functionality of blocks [Feature] Widgets Screen The block-based screen that replaced widgets.php. [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). New Block Suggestion for a new block
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add Block: Search