Help talk:Extension:AdvancedSearch

Jump to navigation Jump to search

About this board

Feedback and discussion page for the AdvancedSearch feature.

I like the older Advanced Search feature better

George Ho (talkcontribs)

I see that the newer Advanced Search feature will become default to many other wikis on November 28. However, 18,000+ enwiki users enabling the feature is not tremendous as another Beta Feature enabled by 80,000+ enwiki users. Also, the namespace selection window in the newer version is very small, making the scrolling more time-consuming than the older one. Moreover, I can simply type any -word OR something NOT anything, so I guess I'm a bit more advanced user than others probably.

Can the "Hide the improved version of the Advanced Search" be made please? Or what about asking the communities whether to enable the feature by default?

TheDJ (talkcontribs)

You can organise a vote in advance and create a ticket linking to consensus that you dont want it. As always.

George Ho (talkcontribs)

At en-WP's Village Pump, right? Or what about meta-wiki's central forum? Or where else?

Wargo (talkcontribs)

If for one wiki only - locally.

George Ho (talkcontribs)

However, the change would affect most users of all of the local wikis, so I was thinking every wiki.

Wargo (talkcontribs)

If you want to start discussion to affect only on enwiki you can start it on enwiki.

Wargo (talkcontribs)

Yes, communities will kill developers after they notice the change! And what Tech Ambassadors should say then? Will be possible to restore old interface in individual preferences?

Michael Schönitzer (WMDE) (talkcontribs)

Hi George Ho! Thank you for your feedback to this extension. The feature can be very useful for new or not so tech-savvy users, which is something that test with users and feedback has shown repeatedly. But we understand that some more experienced users would prefer the previous interface. That’s why there will be an option to allow every user to disable the feature in their settings. Beside that the new interface also allows to use keywords in the main search-bar as before.

George Ho (talkcontribs)

I see the option "Don’t show the Advanced Search interface". I find it somewhat confusing or misleading; there is the "Advanced" button when the feature is opted-out. Can it be rephrased or something?

Michael Schönitzer (WMDE) (talkcontribs)

We are considering alternative names for the option, but are not sure yet about what it could be called. If you have ideas feel free to share with us.

George Ho (talkcontribs)

How about either "Hide the improved version of the Advanced Search interface" (similar to other "Hide the improved version of..." options) or "Revert back to old version of the Advanced Search interface"?

Michael Schönitzer (WMDE) (talkcontribs)

I created a phabricator-task for that: T213274 – this way it's on our radar.

This post was hidden by Michael Schönitzer (WMDE) (history)
Reply to "I like the older Advanced Search feature better"
YBG (talkcontribs)

it is really hard to select namespaces. Two ideas for improvement:

  1. Put the [x] box on the left hand side of the namespace. That way, if you want to delete a consecutive bunch of namespaces, it is just a matter of clicking multiple times in the same position.
  2. Change the drop-down into a two-column table format so that all of the talk pages are on the same line as their non-talk partner. Then you could scan the list much easier.

Thanks for considering!

Gryllida (talkcontribs)

I like the second idea. It is really helpful.

MichaelSchoenitzer (talkcontribs)

I realised this by adding the following CSS to my common.css:

.mw-advancedSearch-ui-itemMenuOptionWidget {
    display: inline-block;
    width: 46%;
    border-top: none;
    border-bottom: 1px solid #c8ccd1;
Michael Schönitzer (WMDE) (talkcontribs)

Thank you for this feedback – it's very valuable for us! We will investigate possible improvements of the namespace-selector. Are there some combinations of namespaces that you use very often?

YBG (talkcontribs)

Can't think of any namespace combos. But I did think of another feature - it would be really nice to be able to exclude subpages, either in all selected namespaces or perhaps on a namespace-by-namespace basis. There may be a way to do it now, but I haven't been able to figure out how.

Michael Schönitzer (WMDE) (talkcontribs)

I think it's currently not possible to exclude subpages. You can propose this to the Wikimedia Search Platform. They build the search, we just build the user-interface.

Reply to "Hard to select namespaces"

Issue:Temporary flash of search text

1 (talkcontribs)


It seems the advancedsearch temporarily stores its search text in the text area and then quickly removes it. This creates a jarring experience.

Steps to reproduce:

  1. Go to


Note that just before it loads the advanced search interface it shows "bots intitle:test" temporarily. Then a few seconds later the intitle part is hidden. See, .


It just shows "bots" within the input box.


This may yet be another drawback of not implementing a critical interface using html, and building it using javascript. Aside from the "jumpy" nature of the loading, it also feels as if pushes the text from the input box to the "advanced parameters" area.

Reply to "Issue:Temporary flash of search text"
Summary by Michael Schönitzer (WMDE)

Hi, thank you for the proposal. I created a phabricator-task for it, so that we have all proposed improvements in one place:

Wargo (talkcontribs)

Add possibility to clear namespace selection to start selecting from scratch. Current method: click "All" to select all, then again to select none.

Issue: Exact this search does not match exact string

5 (talkcontribs)


Searching for "exact this text" doesn't find only the exact string

Steps to reproduce:

  1. Search for "brand of popcorn in North America" ->
  2. Search it using advanced search :


Step 2 above matches step 1, e.g. it only finds words that exactly contain "brand of popcorn in North America". Exactly in that order.


It currently also finds strings like:

Popcorn (popped corn, popcorns or pop-corn) is a variety of corn kernel, which expands and puffs up when heated. A popcorn kernel's strong hull contains

Proposed solution:

  1. Either make the "exact text" match the string exactly with no further words, e.g. step 1 above;
  2. Or create a separate input box for an "exact match" if it is working as expected. (talkcontribs)

Basically it seems to be doing an OR search, e.g. "brand" OR "of" OR "popcorn" OR "in" OR "North America", which is unexpected. (talkcontribs)

Hmm, just noticed that the tooltip help claims that it must always have quotations marks. This makes no sense whatsoever. If the user has to add quotation marks, then they can just type directly in the main search box, rather than use "advanced search".

Having also tried the suggested syntax, it also doesn't seem remotely sensible, .

It finds the page, probably because the search string contains a comma.

TheDJ (talkcontribs)

I agree that this seems unintuitive

Michael Schönitzer (WMDE) (talkcontribs)

Hey, thanks to both of you for your input! The usability of this field turned out to be more tricky than one might think. Our tests confirm that while the current version works better than previous attempts it still is not very intuitive. So we are aware that it's still not great yet. There's also a ticket about this.

Reply to "Issue: Exact this search does not match exact string"
اميرة الضلال (talkcontribs)

ان الواجهة الجديدة جميلة جدا

Michael Schönitzer (WMDE) (talkcontribs)


TJones (WMF) (talkcontribs)

I just tried the extension on English Wikipedia, and after searching, I saw my query flash in the query box for a moment, but then it disappeared. I recently suggested the extension to someone who wants to learn more of the advanced syntax, but didn't realize the constructed query was hidden. Some users would rather type their queries, and could use the extension as a learning tool (and/or to remember a keyword you haven't used in months), but hiding the query makes that harder.

Michael Schönitzer (WMDE) (talkcontribs)

Hi, there should not be any query flashing at all. This probably was an already fixed bug. We considered the behavior you suggested for the same reasons as you did but decided against for technical and UX reasons. We still want to help the users to learn the keywords with our extension. That is why we have the info-icons next to each search option, when hovering the option is explained including how this can be used by keyword.

TJones (WMF) (talkcontribs)

Would it be possible to have a URL parameter or developer setting or some other way to display the generated query? In discussion of exact search it's not at all clear what's happening (though it seems likely to be either "term1" OR "term2" or "term1" "term2"), and seeing the generated query would make it clear what is happening, so we could have a more well-informed discussion about what should be happening, or how it should be described so people interpret it correctly.

Michael Schönitzer (WMDE) (talkcontribs)

Hey, thank you for the proposal. I created a Ticket for this to have it on our list of potential improvements.

Reply to "Why is the generated query hidden?"
Summary by Michael Schönitzer (WMDE)

An option to disable the feature has been added.

Tacsipacsi (talkcontribs)

How can I get rid of this “feature”? When it was in beta, I turned it on, and then turned off within a minute. It may be useful for beginners, but not for power users like me. It takes up half of the screen by showing options and checkboxes I will hardly ever use. It loads for seconds after the full page load (meaning I will click on a completely different link if I’m unlucky enough), because it uses JavaScript for a purpose for which static HTML-based version could be a solution. I will simply not use its fancy tools, because typing the appropriate prefix is much faster, and I don’t want to waste my resources for it.

Stjn (talkcontribs)

Bad loading speed of this tool was raised before without any real resolution from the team working on the tool. It doesn’t matter, though: yet again, Wikimedia Germany ignores any concerns from non-German users and pushes through their wishes without asking other communities.

Igel B TyMaHe (talkcontribs)

Same question. How to turn it off when it will have implemented?

Kyykaarme (talkcontribs)

I can't find a way to turn it off in de-wiki so that's not a good sign. The mass message was sent about 24 hours ago and it was unclear because it just said it will be "default", but so are compact language links and the new recent changes and I don't use those either. Could we please get an answer on if or not this can be turned off by individual users? My home wiki currently has 128 users who are using this in beta and I would like to inform everyone else if there's anything they can do about it after Thursday.

Abiyoyo (talkcontribs)

1. Very slow loading speed. Why use heavy js where simple html form is an obvious option? 2. Selecting namespaces is tricky and time consuming. The old html form with checkboxes was a faster and more convenient way. 3. The idea to give less experienced users a more friendly interface to search syntax is great. But the implementation turned out to be inconvenient. Please give an option to turn this feature off.

Michael Schönitzer (WMDE) (talkcontribs)

Thank you all for your feedback to this extension. The feature can be very useful for new or not so tech-savvy users, which is something that feedback has shown repeatedly. But we understand that some more experienced users would prefer the previous interface. That’s why there will be an option to allow every user to disable the feature in their settings. Beside that the new interface also allows to use keywords in the main search-bar as before.

Hasty deployment process. Hold on

Summary by Michael Schönitzer (WMDE)

An option to opt-out does exist in the user preferences.

Abiyoyo (talkcontribs)

I will be especially grateful if the deployment process is revised according to good old Wikipedia principles: "Any changes to the software must be gradual and reversible. We need to make sure that any changes contribute positively to the community, ... in full consultation with the community consensus".

In ru-wiki we had a notice posted only two days before planned deployment without any option to object. It is anything but 'gradual deployment in full community consensus'. Please revise the deployment process to a more friendly to communities, get the feedback before deployment in a sensible manner with an appropriate time to discuss. Please hold on the deployment in ru-wiki (and maybe some other projects) and get the community feedback first.

Mike Novikoff (talkcontribs)

I second that. It is obvious that many users (in ruwiki, at the very least) will be upset about the update, they already are, and would like to opt out. So please don't deploy it yet, it should be discussed and most likely made optional.

TheDJ (talkcontribs)

Users are always upset. It's the single thing you can count on whenever a change is being made. Is there a reason why they can't bear the interface for 7 days while they vote to get it disabled ?

Mike Novikoff (talkcontribs)

Where the voting takes place?

TheDJ (talkcontribs)

Wherever you want, it's your own community.

Michael Schönitzer (WMDE) (talkcontribs)

Thank you for your feedback, we try to work as community centered as possible, doing multiple feedback rounds, user testings and a long beta phase. The extension was a beta feature for about a year, to give everyone the opportunity for feedback before the feature becomes default. We also deployed Advanced Search gradually: First on a handful of wikis to rule out any bigger blockers. Now more wikis will follow.

The feature can be very useful for new or not so tech-savvy users, which is something that feedback has shown repeatedly. But we understand that some more experienced users would prefer the previous interface. That’s why there will be an option to allow every user to disable the feature in their settings.

Mike Novikoff (talkcontribs)

Thank you for good news, it will be much less of a problem then.

Abiyoyo (talkcontribs)

Thank you very much, Michael. An option in the settings is ok for me. There would have been be less questions and bothering if the cross-wiki announce emphasized it. Thank you.

Hartz (talkcontribs)

I'd argue that this is not as useful in Wiktionary as it is in Wikipedia. No one has explained why this feature should be adopted in Wiktionaries. Wiktionary is just a dictionary and we search by the title. Now the implementation of this feature is happening tomorrow 28th November and no one has explained how the feature helps (is of use) in Wiktionaries.

TheDJ (talkcontribs)

No one has given feedback in 12 months on why it wouldn't be useful..

Translated: Communities have responsibilities as well....

Michael Schönitzer (WMDE) (talkcontribs)

Hi Hartz, thank you for your feedback. It is possible that this feature will be less useful in Wiktionary than in Wikipedia, but we still think that it will be useful to some Wiktionary users. You can still do everything you did with the old search interface with the new one and if you dislike the new interface you will be able to disable it in your user settings. If you think that Wiktionaries would need different search options, we’d be interested to hear your suggestions. We did not yet got much feedback from Wiktionaries.

Kusurija (talkcontribs)

The new Extension:AdvancedSearch interface did find for me existing string in '''no''' way. I knew, that that string really exists, because I '''did''' write it. Please, return the older system, which wasn't lying about existence/nonexistence of concrete string.

If some improvement for Wictionaries, so create better ability to find special letters (with unusual diacritics) as e.g. ệ OR ử OR ů; or for korean ability e. g. find part ㅈ in sylable 존 or in whole word 존재.

Michael Schönitzer (WMDE) (talkcontribs)

Hello Kusurija, we did not change anything on the functionality of the search but only reworked the search interface. The development of the search engine is done by the discovery team at the Wikimedia Foundation. If a search that previously worked now does not work anymore you might want to report this to them.

Reply to "In Wiktionaries"