Last modified: 2008-04-15 10:33:32 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 10457 - Reorganize Special:Specialpages
Reorganize Special:Specialpages
Product: MediaWiki
Classification: Unclassified
Special pages (Other open bugs)
All All
: Normal enhancement with 4 votes (vote)
: ---
Assigned To: Mark Clements (HappyDog)
Depends on:
  Show dependency treegraph
Reported: 2007-07-03 21:39 UTC by Aryeh Gregor (not reading bugmail, please e-mail directly)
Modified: 2008-04-15 10:33 UTC (History)
7 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---

Patch to group Specialpages list into sections - v1 (16.32 KB, patch)
2008-03-26 12:43 UTC, Mark Clements (HappyDog)

Description Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-07-03 21:39:55 UTC
Okay, when we had like ten special pages the current setup may have been fine, but I count 59 special pages on enwiki filed under "for all users".  First-pass suggested organization:

* General page lists
** All pages
** All pages with prefix
** Categories
** Disambiguation pages
** Redirects

* Maintenance page lists
** Articles with the fewest revisions
** Articles with the most categories
** Articles with the most revisions
** Broken redirects
** Cross-namespace links
** Dead-end pages
** Double redirects
** Long pages
** Most linked to categories
** Most linked to images
** Most linked to pages
** Most linked-to templates
** Oldest articles
** Orphaned pages
** Pages without language links
** Protected pages
** Short pages
** Uncategorized categories
** Uncategorized images
** Uncategorized pages
** Uncategorized templates
** Unused categories
** Unused files
** Unused templates

* Tools
** CategoryTree
** Cite
** Expand templates
** Export pages
** File path
** MIME search
** Random article
** Random redirect
** Search
** Upload file

* Logs and information
** Blocked IP addresses and usernames
** Book sources
** External links
** Files
** Gallery of new files
** Logs
** New pages
** Recent changes
** Statistics
** System messages
** User contributions
** Users
** Version
** Wanted categories
** Wanted pages
** Wikimedia Board of Trustees election
** Wikimedia wikis

* Personal pages
** My preferences
** My watchlist
** Sign in / create account

* Restricted special pages (as now)

This should be done in multiple columns for better readability, I guess using floats or something so it displays in one column if there's not enough available space, but that might be best as a separate bug.  Many of these should also be merged with each other: most obviously wanted pages/categories, uncategorized X, unused X, most linked to X, and so on, but also things like All pages/Categories/Redirects, and preferably pairs like Short/Long pages as well.  But that's definitely another bug.  As is showing all special pages, which I think is the most expected and useful thing to do and I've never been clear on why we don't.
Comment 1 Rob Church 2007-07-03 21:41:57 UTC
Note that in the forthcoming changes to reporting (in branch), reports are split off into a separate section (and some *are* merged together); the list looks quite a bit tidier.
Comment 2 Raimond Spekking 2008-03-05 15:46:38 UTC
Special:Specialpages reworked with r31590. The page is customizable by editing [[MediaWiki:specialpages-tpl]]. 
Comment 3 Robin Pepermans (SPQRobin) 2008-03-05 16:50:40 UTC
I have some questions/comments:

* What happens with special pages of extensions?
* When there is a new special page in MediaWiki, I assume the developer has to add it to every translated message?

An idea could be to use {{int:specialpages-blabla}} in the headings of the "specialpages-tpl" message, so the message shouldn't be translated to other languages.
Comment 4 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-03-05 16:51:44 UTC
Those were pretty much exactly my comments.  :)
Comment 5 Brion Vibber 2008-03-05 19:10:24 UTC
Reverted in r10457.

This is far too fragile. It's a bad interface (witness the huge troubles with sidebar customization as it is), doesn't handle extensions well, doesn't handle localization well, and is generally just going to make things confusing and inconsistent.

Resolving as WONTFIX.
Comment 6 Brion Vibber 2008-03-05 19:21:48 UTC
Sorry, that's r31595. Cut-and-pasted wrong number. :)
Comment 7 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-03-06 00:25:30 UTC
Reopening, since none of the concerns expressed have to do with the bug itself, they have to do with Raymond's implementation.  The message interface should not be used, except of course for the messages themselves (e.g., titles of special page groupings).  The issue itself remains valid.  See the above-linked thread for discussion on alternative implementations.
Comment 8 Mark Clements (HappyDog) 2008-03-26 12:43:06 UTC
Created attachment 4766 [details]
Patch to group Specialpages list into sections - v1

Further to our discussion a couple of weeks ago on wikitech-l, here is the first draft of my suggested solution.  This is just the basic method of implementation - there are various extra features that I would like to add if the general method is approved (which can be added as part of this patch, or later as separate features) plus there are several questions that need discussion before final implementation.

The new page lists pages by section, where 'section' is defined as part of each special page definition.  'section' can be any text, which allows extensions to create new sections if needed.  In order to avoid a lot of single item sections, any single-item sections are merged with the general 'miscellaneous' section.

Some questions:
* 'misc' is always at the bottom of the list, but the earlier sections are sorted alphabetically.  It might be better to have a fixed 'logical' order, based on most common usage.  In this case unrecognised categories (i.e. those added by extensions) would probably be listed alphabetically between the built-in sections and the misc section.
* Currently each section consists of an h3 header, followed by an un-ordered list.  Would it be better to do this as nested un-ordered lists?

Some suggested improvements:
* It might be better to merge the restricted pages into the main list, highlighting restricted items (e.g. with an *) and noting that they are restricted and not available to all users.  (Ideally it would also indicate the restriction (bureaucrats only, sysadmins only, etc.) but I'm not sure whether this information is easily available.) What do people think about this?
* CSS classes needs to be added - will do that when the overall structure is fixed.

Note that the sections I have used are based on my own structure, as I've only just seen this bug and the suggested layout above.  I am happy to change the groupings if the above method is thought to be better, but I've held off doing it until I see what feedback it gets.
Comment 9 Mark Clements (HappyDog) 2008-03-26 12:44:09 UTC
Forgot to mention - the above patch is against MW 1.12.0, not HEAD.
Comment 10 Raimond Spekking 2008-04-15 10:33:32 UTC
Done by Aaron with r33197.

Note You need to log in before you can comment on or make changes to this bug.