Wikimedia Bugzilla is closed!

I imagine having a textbox with common suggestions (hardcoded into a mediawiki ns page) would be better then a pure drop down, as the full list might be long (look at the inactive tags on 'pedia), but we still want to enable the user to input any tag they desire.

Created attachment 9366 [details]
Patch against trunk

Oke, I had a go at this. A dropdown list is added to RecentChanges, Contributions, History and NewPages. 

*Tags to put in the dropdown for RC, Contribs and History are taken from MediaWiki:tag-filter-dropdown-list 
*Tags to put in the dropdown for NewPages are taken from MediaWiki:tag-filter-newpages-dropdown-list
*Non-existing tags in these messages are excluded from the dropdown
*If there are no (existing) tags listed in the message, the dropdown is not shown
*The textbox is always shown
*When a tag in the dropdown is selected, it is used and the textbox is ignored
*When the 'other'-item in the dropdown is selected, the tag in the textbox is used
*A new GET-parameter is used: 'tagfilterdropdown'

Created attachment 9367 [details]
Patch against trunk

The code looks very good, except for minor detail of using 'or' instead of '||'.

The user interface could perhaps be better, but that can be improved later if necessary.

In testing I see:
 Warning: implode(): Invalid arguments passed in /www/sandwiki/includes/specials/SpecialRecentchanges.php on line 611

My wiki doesn't have any defined tags. It is probably also the reason why I don't see any filtering interface in the first place. 

Anyway, looks like changing return '' to return array() in ChangeTags::buildTagFilterWithDropdown fixes the warning.

Marking "reviewed."  MrBlueSky, could you revise your patch per Niklas's code review?  Thanks!

I also found (and fixed) the problem with implode on this patch when I
looked at it.  Also, like Niklas, I didn't have a good way to test it
since I didn't have tags on my wiki.

To fix the implode problem, replace “return '';” on line 201 with
“return array();”

Created attachment 9390 [details]
Patch against trunk

The only easy way to test tag-related things is AFAIK to create abuse filters which attaches them to changes. Neither the core nor commonly used extensions (besides AbuseFilter) use tags. 

I have revised the patch per Niklas's code review. And I made two other changes:
*I removed the check for valid tags. When all abuse filters which use a certain tag are removed, the tag is no longer in table 'valid_tag'. But there could still be changes which have that tag attached and users might want to look for them. When non-existing tags are specified it probably makes more sense anyway to just put them in the list and have it noticed and fixed than to hide them.
* 'MediaWiki:tag-filter-dropdown-list' and 'MediaWiki:tag-filter-newpages-dropdown-list' simply take one tag per line, because it's possible users want to have tags starting with an asterik.

(In reply to comment #8)
> *I removed the check for valid tags. When all abuse filters which use a certain
> tag are removed, the tag is no longer in table 'valid_tag'. But there could
> still be changes which have that tag attached and users might want to look for
> them. When non-existing tags are specified it probably makes more sense anyway
> to just put them in the list and have it noticed and fixed than to hide them.

Yeah, searching for tags that are no longer be used on new edits should be possible.

This won't cause a lit of ancient tags since mw_recentchanges is frequently truncated/shortened.

Oh, it doesn't actually query it (prolly not indexed)..

Changing "reviewed" to "need-review" because MrBlueSky's new patch awaits review.  Thanks for the patch!

In order to properly review this, I need to find out how to add tags before this change is made.  Clues? point me to some docs?

(In reply to comment #12)
> In order to properly review this, I need to find out how to add tags before
> this change is made.  Clues? point me to some docs?

Honestly, direct db manipulation is easiest way ;) . If you don't want to do that you need to install abuse filter, and make some filters that tag stuff (You should be able to steal filters from wikimedia wikis. MW.org has a filter that tags any edit adding ?> for example)

See also [[mw:Manual:Tags]] which isn't exactly high on details

btw, another possible way of doing this that comes to mind, is re-use the search drop-down suggestion code, and make suggestions while users type.

I'm a bit befuddled by this comment:

+	 * @param $msgkey String: message key for the message which contains a (newline delimited)
+	 *        list of tags to put in the dropdown list. If the message contains no valid tags
+	 *        or doesn't exist the dropdown list is omitted and only a text field is created.


however in the function body, it also checks self::listDefinedTags() and if there aren't any in there, the list ends up empty.

Should it be combining these two lists, or filtering one by the other, or something else? It kinda looks like you have to hardcode the set of things that you can select in messages, of which there's at least two to maintain. What's the intention behind this?

Created attachment 9727 [details]
Tag against trunk

Oh, i'm sorry: that's an old comment which I should have changed. 

If $wgUseTagFilter is false or there are no defined tags, no filter form is returned. Otherwise a textfield is created, and when the specified message contains text, a dropdown is created too.

There are indeed 2 messages for specifying the selectable tags, one for newpages and one for RC, history and contribs. This way admins can choose usefull tags (or to not have a dropdown menu at all). Another possibility would of course be to always put all defined tags in the dropdown but on some wikis (wp-en) this would result in a lot of clutter.

Applied patch in r108850.  Thanks for the patch!

Reverted as trunk is in code freeze for 1.19 release.  Congrats on commit access MrBlueSky.  Please review comments for r108850.

MrBlueSky: Thanks again for the patch.  Are you interested in updating it and using developer access to directly suggest it into our Git source control system?

https://www.mediawiki.org/wiki/Developer_access

https://www.mediawiki.org/wiki/Git/Workflow#How_to_submit_a_patch

*** Bug 25876 has been marked as a duplicate of this bug. ***

I have submitted a change (and abandoned) in Gerrit: [[gerrit change 4363]].

The problem with that implementation is that configuration has to be done using system messages, which is neither userfriendly nor flexible. It should have a nice GUI instead. But actually I think its better to create this functionally as a Javascript gadget, so the people who create and maintain the gadgets at a project can create something which fits the project. For example: on wp-nl, where I enabled such a gadget [1] we have only 7 labels (which almost never change), so a textfield isn't useful and a simple dropdown suffices.

[1] http://nl.wikipedia.org/wiki/MediaWiki:Gadget-labelfilter.js

Gerrit change #4363

The patchset was for "Dropdown for tags in rc, contribs, history and newpages".

Bartosz, would you be interested in taking this issue on?

I am currently waiting for somebody to review one of my own patches in gerrit, and nobody seems interested. I'm not sure if I will be able to without overburdening myself.

Anyway, what's the issue about now? Integrating the gadget into core? That seems like a bad idea, as it wouldn't be configurable, and retrieving the tags from the API on each call would be quite inefficient, if it's even possible. Or reviving MrBlueSky's changeset? I'm not the best person to do this, PHP is not my forte.

MrBlueSky / Seb35 / Krinkle:

(In reply to comment #24 by Matma.Rex)
> Anyway, what's the issue about now? Integrating the gadget into core? That
> seems like a bad idea, as it wouldn't be configurable, and retrieving the
> tags from the API on each call would be quite inefficient, if it's even
> possible. Or reviving MrBlueSky's changeset? I'm not the best person to do
> this, PHP is not my forte.

This is a little more important now that VE is in beta – I think people often filter RC by the 'visualeditor' tag to look for breakage. The dropdown list should just use the same data that [[Special:Tags]] uses.

CC'ing James Forrester.

Sounds like a nice improvement.

Change 80781 had a related patch set uploaded by Matmarex:
Add a dropdown list for the tag selector

https://gerrit.wikimedia.org/r/80781

I don't know enough about this feature to weigh in intelligently, If the tag list is short a popup might be a reasonable option, however if it is long enough to require scrolling another solution might need to be arrived at.

The list includes all tags "maintained" by extensions (VisualEditor, MobileFrontend and GettingStarted use these, VE 2, the rest 1 each), as well as all active AbuseFilter tags (hopefully not more than a dozen or so, depending on the wiki). Should be acceptable for a dropdown list.

Will this dropdown menu be cluttered by inactive tags and tags from deleted filters (bug 18908)? E.g. the "link vandalism" from English Wikipedia, which is not used anymore:
https://en.wikipedia.org/wiki/Special:Tags

Helder, no, assuming I understand how this works. Special:Tags and this would use different methods - the special page shows all tags that were ever used, while the dropdown would only use the ones explicitly defined using the ListDefinedTags hook.

I asked Reedy to check this on en.wp and the total there is 40 active tags - a little long-ish for a dropdown, but manageable. It's surely shorter on saner wikis.

(For reference, en.wp's Special:Tags shows 90 tags right now.)

90 tags seems like too much for a popup. What about a form field or a combo box with type ahead.

It's 40 for the "popup" (actually a dropdown), 90 only on the special page.

HTML form dropdowns (<select>s) also support search-by-typing in all browsers I'm aware of.

40 or 90 feels overwhelming in a popup on some browsers that is going to take up the full height of the screen. Scrolling in popup can be very difficult for some users.

I think bug 48243 is almost a duplicate of this bug. A drop-down menu for tags seems silly. I'd suggest autocomplete (suggestions).

(In reply to comment #37)
> I think bug 48243 is almost a duplicate of this bug. A drop-down menu for
> tags seems silly. I'd suggest autocomplete (suggestions).

I disagree - autocomplete is great where the search-space is huge and rapidly-changing, but in a restricted (and externally-set, relatively-static) context, it's better to provide some form of latent discoverability than expect users to know what it might be called (or start with).

Created attachment 13275 [details]
jquery.chosen() applied to the tag selector dropdown

Maybe we could use jquery.chosen to get the best of both worlds (screenshot attached). The implementation would be trivial (on top of what I proposed it amounts to adding the jquery.chosen ResourceLoader module and calling `$('.mw-tagfilter-input').chosen()`).

I don't think this is used in core already, but it is definitely included and supported (some of the Labs management extensions use it, I believe, and support is integrated in HTMLForm as well).

(I'm leaning towards a simple select box myself, but this could be a compromise.)

(The particular graphical elements it adds are almost all configurable, see the gallery at http://harvesthq.github.io/chosen/ .)

(In reply to comment #38)
> I disagree - autocomplete is great where the search-space is huge and
> rapidly-changing, but in a restricted (and externally-set, relatively-static)
> context, it's better to provide some form of latent discoverability than
> expect users to know what it might be called (or start with).

A full index (e.g., [[Special:Tags]]) allows users to browse through all tags (in the same way that [[Special:AllPages]] allows users to browse through all page titles). The solutions being proposed here seem short-sighted. While there may "only" be about 90 tags today (which is an overwhelming number in a drop-down menu), does anyone expect this number to stay relatively low or decrease in the future?

The reason autocomplete (or suggestions) are already used within MediaWiki for page titles apply to this input field as well. We should also note that Bugzilla itself uses an autocomplete/suggestions system for its keywords field. A drop-down menu seems like a non-starter to me.

To continue with the best of both worlds idea, why not supply the list of tags for the dropdown if the number of tags is lower than X, otherwise use only auto-completion API?

(In reply to comment #42)
> To continue with the best of both worlds idea, why not supply the list of
> tags
> for the dropdown if the number of tags is lower than X, otherwise use only
> auto-completion API?

Yes, we only need something to implement it. MatmaRex is right that we already use it successfully elsewhere: Rillke added it to Translate, for instance.

Change 80781 abandoned by Bartosz Dziewoński:
Add a dropdown list for the tag selector

Reason:
Needs to be done differently.

https://gerrit.wikimedia.org/r/80781

More reasons to first use autocompletion where possible: bug 64829 comment 8 on bug 21383.