Special:PrefixIndex should have a simpler initial interface
Closed, ResolvedPublic

Description

In fall 2009, some English Wikipedians surfaced an important issue, but apparently did not find a way to get any action taken on their conclusions.

Summary:
The "Special:PrefixIndex" function, which is only a couple clicks away from any page, by default includes a listing of all mainspace articles, alphabetically. Thus, on English Wikipedia, it starts with "!!!Fuck You!!!", a thrash metal album.

The Wikipedians discussing this suggested that the initial view of the "Special:PrefixIndex" page should not include ANY articles until a search string has been entered. Seems perfectly reasonable, but needs a techy to implement.


Version: unspecified
Severity: major
URL: http://en.wikipedia.org/wiki/Wikipedia_talk:Special:PrefixIndex#Inappropriate_default_search.3F

bzimport added a project: MediaWiki-Interface.Via ConduitNov 21 2014, 11:03 PM
bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz23923.
Peteforsyth created this task.Via LegacyJun 11 2010, 10:31 PM
Catrope added a comment.Via ConduitJun 12 2010, 2:15 PM

Suggest WONTFIX. Special:Prefixindex is really just a special mode of Special:Allpages, which does the same thing AFAIK.

MaxSem added a comment.Via ConduitJun 12 2010, 2:49 PM

If some project doesn't like the default implementation for some weird reason (there's [[WP:NOTCENSORED]], by the way), they could tweak it with site JS.

Peteforsyth added a comment.Via ConduitJun 12 2010, 4:23 PM

pete.public.email wrote:

Max, just to be clear about the request: nobody suggested censoring Wikipedia.

The Wikipedians who discussed this felt that there was no benefit or encyclopedic value to showing the first n articles alphabetically, which is an arbitrary sample generally beginning with punctuation characters. The fact that the first entry is !!!Fuck You!!! is just the thing that started the discussion, not the justification for making a change.

Could you explain your suggestion? I don't know what "site JS" is, or how one would go about tweaking it to meet this need.

Peteforsyth added a comment.Via ConduitJun 12 2010, 4:47 PM

pete.public.email wrote:

Roan, The idea that Special:PrefixIndex is a special case of Special:Allpages makes sense, and I don't think the original folks requesting this realized it (I know I didn't). And of course a page intended to list "all pages" has to start somewhere, so I doubt there's any desire to change Special:Allpages behavior in this way.

But I'm not sure I understand how this relationship between the features affects the original request. Is it impossible, or very difficult, to change the default first display of Special:PrefixIndex without changing the behavior of Special:PrefixIndex? What's the issue that makes you suggest not fixing it?

MZMcBride added a comment.Via ConduitJun 12 2010, 5:06 PM

Regardless of the underlying original reason for requesting this change, I think it's reasonable to say that there isn't any good particular reason that the initial form shows entries.

A user navigates to [[Special:PrefixIndex]] to find all pages beginning with some character. To show results before the user has entered anything is confusing and unnecessary.

I've adjusted the bug summary to be clearer and less ideological.

Catrope added a comment.Via ConduitJun 12 2010, 6:31 PM

(In reply to comment #4)

Roan, The idea that Special:PrefixIndex is a special case of Special:Allpages
makes sense, and I don't think the original folks requesting this realized it
(I know I didn't). And of course a page intended to list "all pages" has to
start somewhere, so I doubt there's any desire to change Special:Allpages
behavior in this way.

But I'm not sure I understand how this relationship between the features
affects the original request. Is it impossible, or very difficult, to change
the default first display of Special:PrefixIndex without changing the behavior
of Special:PrefixIndex? What's the issue that makes you suggest not fixing it?

I have no idea how difficult this is, it's just that to me this request made no sense. But I agree that the current behavior arguably doesn't make sense either.

What Max meant by "site JS" is that you can put some JavaScript in [[MediaWiki:Common.js]] that would then hide these links. This should be easy for someone with JS experience (and there's plenty of them out there, enwiki has a fairly large base of custom JS).

bzimport added a comment.Via ConduitOct 24 2010, 3:27 PM

Bryan.TongMinh wrote:

(In reply to comment #5)

Regardless of the underlying original reason for requesting this change, I
think it's reasonable to say that there isn't any good particular reason that
the initial form shows entries.

Especially since we do that with every search-like form I believe.

bzimport added a comment.Via ConduitOct 24 2010, 3:33 PM

Bryan.TongMinh wrote:

Fixed in r75314.

Peteforsyth added a comment.Via ConduitOct 24 2010, 6:14 PM

pete.public.email wrote:

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

brion added a comment.Via ConduitOct 25 2010, 11:50 PM

There was a regression which caused no results to be shown for the prefix '0', as this evaluates to false in boolean context -- this is what the isset checks were there for, as they don't give that false negative. Ah, PHP. :)

Fixed in r75402; comparing against '' does the job we want here just fine.

bzimport added a comment.Via ConduitOct 26 2010, 7:08 AM

Bryan.TongMinh wrote:

Oh the joys of PHP. Thanks Brion :)

MZMcBride added a comment.Via ConduitNov 20 2010, 9:08 AM
  • Bug 26024 has been marked as a duplicate of this bug. ***
Jidanni added a comment.Via ConduitNov 20 2010, 1:09 PM

Created attachment 7842
Jimmy Wales appeal seeming to lead into offensive line coincidence

Here just for the record is the odd juxtaposition of the fund raising appeal vs. the dirty words, if one clicks the link on the pre-fixed bug to get to that page.

attachment FYATS.JPG ignored as obsolete

bzimport added a comment.Via ConduitNov 20 2010, 1:28 PM

matthew.britton wrote:

(In reply to comment #13)

Created attachment 7842 [details]
Jimmy Wales appeal seeming to lead into offensive line coincidence

Here just for the record is the odd juxtaposition of the fund raising appeal
vs. the dirty words, if one clicks the link on the pre-fixed bug to get to that
page.

That's no different to what would happen on viewing any other "offsensive" title, and I don't see how it's related to this bug.

attachment FYATS.JPG ignored as obsolete

Chad added a comment.Via ConduitNov 20 2010, 5:36 PM

The content of attachment 7842 has been deleted by

Chad H. <innocentkiller@gmail.com>

who provided the following reason:

Bogus

The token used to delete this attachment was generated at 2010-11-20 17:36:38 UTC.

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.