Aaron recently committed an update to Special:SpecialPages [1] which adds the long-awaited functionality of splitting the list of pages up into shorter manageable sub-lists. Hurrah! However he didn't notice bug 10457 [2] which deals with this issue and which (a) has a couple of suggested groupings for the various pages and (b) already had a patch (which I contributed) for solving this same problem.
Before 1.13 comes out and this ends up in an official release I would like to open up some discussion about a couple of points:
#1 - Extensions
My patch was written to allow extensions to easily add themselves to a particular section, with any non-categorised extensions falling through into a 'misc' section at the bottom. This was deliberately designed to be backward compatible and easy to use.
In Aaron's method, SpecialPage:setGroup( $pagename, $group ) is the code to use, which has two potential drawbacks: * Extensions need to explicitly check which version of MW they are running on before calling the code, otherwise errors will occur in earlier versions which don't have this function. * It requires an extra function call - this may not be a major problem (and may just be a subjective matter of coding style), but it is if it causes the SpecialPage class to be loaded permaturely (I don't know if this is the case or not).
It would be good to get a bit of feedback on the two methods used to see which is considered better in terms of both future-proofing and backwards-compatibility (and of course any other considerations that may apply). Of course, if there's no particular benefit to either method then we should use the one that's already in place.
#2 - Grouping
There have now been three proposed groupings of the special pages. Aaron's (currently live on WMF sites), Mine (in the patch I attached to the bug) and Simetrical's (in the initial bug description). Obviously, I think mine is best, but I don't think any of them are quite right yet. It would be good to get some discussion and settle on a decent order.
Also, in my view there should be no sections with just a single item (my code avoids this by moving single-item sections into 'miscellaneous', which would be an easy thing to add to Aaron's code) and also the default sections should not be as big as (for example) 'Other special pages' currently is.
Thanks to Aaron for getting this long-awaited feature into core.
- Mark Clements (HappyDog)
[1] http://svn.wikimedia.org/viewvc/mediawiki?view=rev&revision=33197 [2] https://bugzilla.wikimedia.org/show_bug.cgi?id=10457
Agreed, SpecialPage:setGroup( $pagename, $group ); is not good to use. We used to use SpecialPage:addPage( Object ); to add in new special pages. Except this ends up loading both the SpecialPage class, and the class for the extension. Honestly I'm guilty of still using it because I only recently found out that even before I started using it the thing had been depreciated and the proper way to add a new special page was to add the array with it's class name and constructor to $wgSpecialPages. However, the current setGroup actually just appends to $wgSpecialPageGroups. So we should be treating this in the same way. The SpecialPage addPage and setGroup functions do exist. But they should be both considered depreciated functions there only for compatibility with old extensions and the misinformed. Everyone should be using $wgSpecialPages and $wgSpecialPageGroups in their extensions.
Honestly, now that I think about it anything added to $wgExtensionFunctions probably shouldn't be part of a big class integral to an extension. For cleanest code it should probably still be ok to have a class with the name of the extension and have it contain the various MagicWord hook methods, ExtensionFunctions and such. But leave SpecialPage classes and methods for anything like ParserFunctions in other classes in other files which will only be loaded when and if needed.
Though I would like to improve on the style:
Take a look at Special:Version's look: http://dev.wiki-tools.com/wiki/Special:Version But look at Special:SpecialPages: http://dev.wiki-tools.com/wiki/Special:SpecialPages
Special:Version uses some nice styles, and tables, and even borders things. All by default. But Special:SpecialPages uses ugly boxes. I'd say they could use some margin and bordering on them. Actually on the note of the looks... Open up Special:SpecialPages, and then reduce the width of your browser. Notice that blank space? Inspecting the elements you see something... Special:SpecialPages is reserving an entire td for a third column that is never used. Either remove the td making it 2 columns, or actually use 3 columns. No reason to stick in a huge gap which could either be used to reduce the large height that Special:SpecialPages still takes up, or avoid any line breaking when the screen size is reduced.
And lastly, we have those headings... Special:SpecialPages is still outputting the awful "Special pages for all users" and "Restricted special pages" headers. Not only are they completely ugly when paired with the grey boxes, and take up even more space then they do. It's quite pointless to have them with all these other nice headings. We should either merge restricted special pages into the categorization (We could always give them a different class and highlight them, or add something like an asterisk (*) on the end of them with a note "* Restricted special page you have access to" at the bottom... And if you find that ugly, but note that the css class isn't very good for those without css... Then do both, and put the asterisked stuff there, but put it inside of a span with a class to hide it when css is enabled...), or we should make "Restricted special pages" smaller and style it similarly to the boxes. Basically shrink it down so it's only a little heavier in size, and doesn't have the margin of the others so it is a bit wider. But whatever the case, "Special pages for all users" should never show up... Especially when there are no restricted pages... Think about it, what's the point of saying a bunch of pages are for everyone, when you're not even able to see any restricted pages at all. I kinda like the former. It lets me search for a page I want by it's category, not by first trying to figure out if it's restricted or not.
~Daniel Friesen(Dantman) of: -The Gaiapedia (http://gaia.wikia.com) -Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) -and Wiki-Tools.com (http://wiki-tools.com)
Mark Clements wrote:
Aaron recently committed an update to Special:SpecialPages [1] which adds the long-awaited functionality of splitting the list of pages up into shorter manageable sub-lists. Hurrah! However he didn't notice bug 10457 [2] which deals with this issue and which (a) has a couple of suggested groupings for the various pages and (b) already had a patch (which I contributed) for solving this same problem.
Before 1.13 comes out and this ends up in an official release I would like to open up some discussion about a couple of points:
#1 - Extensions
My patch was written to allow extensions to easily add themselves to a particular section, with any non-categorised extensions falling through into a 'misc' section at the bottom. This was deliberately designed to be backward compatible and easy to use.
In Aaron's method, SpecialPage:setGroup( $pagename, $group ) is the code to use, which has two potential drawbacks:
- Extensions need to explicitly check which version of MW they are running
on before calling the code, otherwise errors will occur in earlier versions which don't have this function.
- It requires an extra function call - this may not be a major problem (and
may just be a subjective matter of coding style), but it is if it causes the SpecialPage class to be loaded permaturely (I don't know if this is the case or not).
It would be good to get a bit of feedback on the two methods used to see which is considered better in terms of both future-proofing and backwards-compatibility (and of course any other considerations that may apply). Of course, if there's no particular benefit to either method then we should use the one that's already in place.
#2 - Grouping
There have now been three proposed groupings of the special pages. Aaron's (currently live on WMF sites), Mine (in the patch I attached to the bug) and Simetrical's (in the initial bug description). Obviously, I think mine is best, but I don't think any of them are quite right yet. It would be good to get some discussion and settle on a decent order.
Also, in my view there should be no sections with just a single item (my code avoids this by moving single-item sections into 'miscellaneous', which would be an easy thing to add to Aaron's code) and also the default sections should not be as big as (for example) 'Other special pages' currently is.
Thanks to Aaron for getting this long-awaited feature into core.
- Mark Clements (HappyDog)
[1] http://svn.wikimedia.org/viewvc/mediawiki?view=rev&revision=33197 [2] https://bugzilla.wikimedia.org/show_bug.cgi?id=10457
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
"DanTMan" dan_the_man@telus.net wrote in message news:48244173.7020208@telus.net...
Agreed, SpecialPage:setGroup( $pagename, $group ); is not good to use. We used to use SpecialPage:addPage( Object ); to add in new special pages. Except this ends up loading both the SpecialPage class, and the class for the extension. Honestly I'm guilty of still using it because I only recently found out that even before I started using it the thing had been depreciated and the proper way to add a new special page was to add the array with it's class name and constructor to $wgSpecialPages. However, the current setGroup actually just appends to $wgSpecialPageGroups. So we should be treating this in the same way. The SpecialPage addPage and setGroup functions do exist. But they should be both considered depreciated functions there only for compatibility with old extensions and the misinformed. Everyone should be using $wgSpecialPages and $wgSpecialPageGroups in their extensions.
Honestly, now that I think about it anything added to $wgExtensionFunctions probably shouldn't be part of a big class integral to an extension. For cleanest code it should probably still be ok to have a class with the name of the extension and have it contain the various MagicWord hook methods, ExtensionFunctions and such. But leave SpecialPage classes and methods for anything like ParserFunctions in other classes in other files which will only be loaded when and if needed.
[SNIP]
So, is anything going to happen regarding this? The important issue, I think, is to sort out the implementation of the low-level stuff (i.e. how you specify the section that a page goes under) as this will start being used by extensions, and we don't want it to change once it has been officially released.
This needs to be fixed soon, before 1.13 comes out!
As I said, I submitted a patch that works in a slightly different way, and this is in bug 10457, but it needs someone to take a look at it. In my view it is important that it works in a backward-compatible way, so extensions don't have to do version-sniffing in order to know whether they can use this functionality or not. It should also be done in a way that doesn't force classes to be loaded prematurely, and I don't know if my method does that or not.
The rest of your suggestions are generally good, but as they are about the display (output) it is less critical that those kinds of things are resolved speedily.
- Mark Clements (HappyDog)
Mark Clements wrote:
So, is anything going to happen regarding this? The important issue, I think, is to sort out the implementation of the low-level stuff (i.e. how you specify the section that a page goes under) as this will start being used by extensions, and we don't want it to change once it has been officially released.
Er, like this maybe?
$wgSpecialPageGroups['Pagename'] = 'groupname';
-- brion vibber (brion @ wikimedia.org)
Yup, I've been using that style for awhile now. http://svn.nadir-point.com/viewvc/mediawiki-extensions/trunk/ScriptCommons/S...
Whatever changes in the background, extensions will still be using the $wgSpecialPagegroups and $wgSpecialPages arrays.
~Daniel Friesen(Dantman) of: -The Gaiapedia (http://gaia.wikia.com) -Wikia ACG on Wikia.com (http://wikia.com/wiki/Wikia_ACG) -and Wiki-Tools.com (http://wiki-tools.com)
Brion Vibber wrote:
Mark Clements wrote:
So, is anything going to happen regarding this? The important issue, I think, is to sort out the implementation of the low-level stuff (i.e. how you specify the section that a page goes under) as this will start being used by extensions, and we don't want it to change once it has been officially released.
Er, like this maybe?
$wgSpecialPageGroups['Pagename'] = 'groupname';
-- brion vibber (brion @ wikimedia.org)
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
wikitech-l@lists.wikimedia.org