Header search plugin

plugin
82

First post wikified.

5 Likes
83

I’d like to suggest a change from the word “options” towards a :gear: icon. What do you think?
(Maybe as drop down menu with all important settings, like the Hamburger Menu)

It’s multilingual and saves limited space.

1 Like
84

Alternatively I would suggest the :mag: icon that is by default used as the search icon. That the “options” are linked to the search bar isn’t always immediately obvious, especially not with the search bar aligned to the right.

1 Like
85

You know how sometimes you stumble on a solution and feel silly for not realising it earlier?

It turns out that if we move the search-context stuff into the dropdown (like it is in the search menu) and add a search icon, it solves the visual issue you’re both referring too and also solves various space issues with having the search-context suff in the header.

26 PM
26 PM1090×116 26.2 KB

With results:

18 PM
18 PM1092×794 120 KB

Incidentally, it now looks and functions very similarly to Facebook header search.

Commits:

Note, the right alignment CSS has changed as a result, see the first post of this topic:

cc @terraboss @nawthor

10 Likes
86

Well done. The plugin looks much more intuitive.

I‘d like to share another idea:
(Only for desktop clients with mouse input): What if the search field will become visible, in case, the user hover over the search symbol? The search field plop out from the right side next to the original location. This would save space and is would make the UX much more responsive.

2 Likes
87

I’m not entirely sure I understand what you’re describing, but it sounds like you’re talking about hiding the search input in the header by default? This basically the normal Discourse search UI. No plugin required :slight_smile:

2 Likes
88

Thanks a lot for the work on this. But I noticed a bug. If you enter a topic and scroll until the header search bar is replaced by the default search icon, the search drop-down has an unnecessary additional search icon inside:
image

5 Likes
89

Thanks, fixed: https://github.com/angusmcleod/discourse-header-search-theme/commit/f7ce916b66f5ab5ca3f4635222d29b590b02a28a

6 Likes
90

that styling though… this is on the default theme.

Screen_Shot_2018-02-03_at_11_30_31_AM
Screen_Shot_2018-02-03_at_11_30_31_AM.png742×108 4.71 KB

2 Likes
91

:bowing_man:

Fixed:

7 Likes
92

Thanks for this plugin.

At my site I see a different layout in the search content

This is i the layout at at standard search bar inside a topic
29

This is when I use the plugin
52

Any reason why the result lists layout differ?

1 Like
93

Thanks for the feedback :sun_with_face:

By differ, do you mean:

  • blue text colour of the titles;

  • width reduction of the container (which makes more of the text wrap); and/or

  • the context filter box appears in one screenshot but not in the other?

Width reduction

By default the header search input is thinner than normal Discourse search as there is less space in the header. You can change this on your instance if you wish.

All the header search size calculations, e.g. for the responsive break point (the point at which the search header is hidden because the screen is too thin), or the width of the results window, are ultimately derived from the width of the .search-header class, so you can safely make the search header wider just by increasing the width of that class.

i.e. Set the width of the .search-header class in Admin > Customize > CSS

.search-header {
  width: /// your desired width - default is 350px
}

Topic title color

Personally I think the search results titles should be black as this it makes the .search-highlight of the search term easier to see.

There is a minor inconsistency with how topic title styles are treated in core Discourse. Compare, for instance, the topic titles in the lists in /u/username/activity. Some are black, some are blue. All lists of topics are links to topics, so I’m not sure the answer is that ‘links’ are blue (technically speaking this is actually the answer, i.e. an anchor tag (<a>) is being used, however this doesn’t solve the product-level inconsistency).

But this is minor point, and your implication is right that by default they should reflect the core style (made that change). If anyone wants to change this, just set this CSS rule to whatever you like

.header-search-enabled .search-header a, .header-search-enabled .search-header a:visited {
  color: $tertiary;
}

Different context filters in the screenshots

Were those searches were made in different discovery contexts (i.e. when viewing different topic lists or topics)? The context filters seem to be working fine on my testing, e.g. (taken on my sandbox)

37%20AM
37%20AM736×720 89 KB

4 Likes
94

Thanks for a very loooooong description :slight_smile:

Well yes, basicly my question was how to let the 2 search result list to have the same style/format.

I will look at the code snippets above!

But again a very nice plugin, thanks for the answer!!

2 Likes
95

just upgraded core:

49%20PM

and now header search looks like:

52%20PM

oh noes…

96

Thanks, fixed:

4 Likes
97

** Please note ***

I am removing support for this plugin in favour of the Header Search Theme.

The functionality is exactly the same, but with the advantages of:

  • No site stability risk.
  • Themes now have setting support.
  • Themes are easier to update, particularly now with the theme api.
  • Any future header search functionality can be handled within a theme.
  • It removes duplication, which is a source of engineering risk.
4 Likes
98

I am moving this to #plugin:broken-plugin for now, I know it is not stricly broken but its better to move it now than forget about it and move it later.

7 Likes