The way you completely lose your page tabs when switching to Special:MovePage has been a bother to me for awhile... it's bad interface design to have a set of tabs linking to other pages with the same set of tabs, but to have a single one of them strangely point to a page where those tabs completely disappear.
1.18 has a new feature now. From a special page you can call $skin->setRelatedTitle and $skin->setRelatedTitle. Calling setRelatedTitle will mark a title as relevant to the current page, doing so will cause some parts of the ui (namely the page tabs) to display things relevant to that page. Calling setRelatedUser likewise will cause some parts of the ui (namely the toolbox) to display things that they would display if you were on the user's userpage. These methods are currently used by Special:MovePage (title), Special:Undelete (title), Special:Contributions (user), and Special:BlockIp (user). If you have another special page you feel is relevant enough to use these methods feel free to tweak it's code.
Daniel Friesen wrote:
1.18 has a new feature now. From a special page you can call $skin->setRelatedTitle and $skin->setRelatedTitle. Calling setRelatedTitle will mark a title as relevant to the current page, doing so will cause some parts of the ui (namely the page tabs) to display things relevant to that page. Calling setRelatedUser likewise will cause some parts of the ui (namely the toolbox) to display things that they would display if you were on the user's userpage. These methods are currently used by Special:MovePage (title), Special:Undelete (title), Special:Contributions (user), and Special:BlockIp (user). If you have another special page you feel is relevant enough to use these methods feel free to tweak it's code.
If you remember to in the future, please include links to the specific code revisions you're referring to. This helps people understand what you're talking about and comment on the revisions as appropriate without having to hunt.
I assume you're referring to these revisions: * http://www.mediawiki.org/wiki/Special:Code/MediaWiki/79398 * http://www.mediawiki.org/wiki/Special:Code/MediaWiki/79399
It looks like a nice usability fix. :-) (Now to get Special:MovePage turned into ?action=move....)
MZMcBride
On 01/03/2011 07:23 AM, MZMcBride wrote:
I assume you're referring to these revisions:
- http://www.mediawiki.org/wiki/Special:Code/MediaWiki/79398
- http://www.mediawiki.org/wiki/Special:Code/MediaWiki/79399
It looks like a nice usability fix. :-) (Now to get Special:MovePage turned into ?action=move....)
I could see arguments for going the other way too. For example, writing [[Special:History/Page|history]] would be _so_ much more convenient than <span class="plainlinks">[{{fullurl:Page|action=history}} history]</span> (and very few people outside this list probably even know that one can do the latter).
But I do generally agree that the lack of a clear and logical distinction between actions and special pages is ugly and sometimes confusing (...not to even mention Special:Search...).
On 11-01-03 03:59 AM, Ilmari Karonen wrote:
On 01/03/2011 07:23 AM, MZMcBride wrote:
I assume you're referring to these revisions:
- http://www.mediawiki.org/wiki/Special:Code/MediaWiki/79398
- http://www.mediawiki.org/wiki/Special:Code/MediaWiki/79399
It looks like a nice usability fix. :-) (Now to get Special:MovePage turned into ?action=move....)
I could see arguments for going the other way too. For example, writing [[Special:History/Page|history]] would be _so_ much more convenient than <span class="plainlinks">[{{fullurl:Page|action=history}} history]</span> (and very few people outside this list probably even know that one can do the latter).
But I do generally agree that the lack of a clear and logical distinction between actions and special pages is ugly and sometimes confusing (...not to even mention Special:Search...).
I remember seeing some discussion somewhere about someone putting together alias special pages like [[Special:Edit/page]] for some of the page actions. I can't remember where that was.
Here's something Nikerabbit pointed out. He was thinking that Special:Contributions should also include a userpage and user talk tab.
Initially I didn't do this because it wasn't a straight related title. A "user" has both a userpage and a talkpage and it doesn't make sense for Special:Contributions to include an edit/move/etc... tab for either page since it's not linked to a specific title but the user itself. Hence, to give Special:Contributions those tabs, we would have to turn the namespace section into a "Userpage / Usertalk / Specialpage" triple set of tabs on special pages, adding a condition into that section of code which till now has been given the pattern of never outputting any tab other than specialpage.
On Mon, Jan 3, 2011 at 12:23 AM, MZMcBride z@mzmcbride.com wrote:
It looks like a nice usability fix. :-) (Now to get Special:MovePage turned into ?action=move....)
I'd do the opposite -- stop using actions other than view, and move everything to special pages. (Of course we'd still support the old-style URLs forever for compat, just not generate them anywhere.) The set of things that are done by actions is small, fixed, and incoherent: edit, history, delete, protect, watch; but not move, undelete, export, logs, related changes. The distinction is historical -- I assume most or all of the action-based ones came about before we had such a thing as special pages. It would be cleaner if we only had special pages for doing non-view actions.
On 01/03/2011 11:09 PM, Aryeh Gregor wrote:
On Mon, Jan 3, 2011 at 12:23 AM, MZMcBridez@mzmcbride.com wrote:
It looks like a nice usability fix. :-) (Now to get Special:MovePage turned into ?action=move....)
I'd do the opposite -- stop using actions other than view, and move everything to special pages. (Of course we'd still support the old-style URLs forever for compat, just not generate them anywhere.) The set of things that are done by actions is small, fixed, and incoherent: edit, history, delete, protect, watch; but not move, undelete, export, logs, related changes. The distinction is historical -- I assume most or all of the action-based ones came about before we had such a thing as special pages. It would be cleaner if we only had special pages for doing non-view actions.
I think we've had both actions and special pages from the beginning (well, since r403 at least). I suspect it's just that adding new special pages was easier than adding new actions, so people tended to pick the path of least resistance.
On 04/01/11 12:12, Ilmari Karonen wrote:
On 01/03/2011 11:09 PM, Aryeh Gregor wrote:
On Mon, Jan 3, 2011 at 12:23 AM, MZMcBridez@mzmcbride.com wrote:
It looks like a nice usability fix. :-) (Now to get Special:MovePage turned into ?action=move....)
I'd do the opposite -- stop using actions other than view, and move everything to special pages. (Of course we'd still support the old-style URLs forever for compat, just not generate them anywhere.) The set of things that are done by actions is small, fixed, and incoherent: edit, history, delete, protect, watch; but not move, undelete, export, logs, related changes. The distinction is historical -- I assume most or all of the action-based ones came about before we had such a thing as special pages. It would be cleaner if we only had special pages for doing non-view actions.
I think we've had both actions and special pages from the beginning (well, since r403 at least). I suspect it's just that adding new special pages was easier than adding new actions, so people tended to pick the path of least resistance.
Special pages are nice because they have a base class with lots of features. They are flexible and easy to add.
The main problem with actions is that most of them are implemented in that horror that is Article.php.
We could have a class hierarchy for actions similar to the one we have for special pages, with a useful base class and some generic internationalisation features. Each action would get its own file, in includes/actions. This would involve breaking up and refactoring Article.php, which I think everyone agrees is necessary anyway.
The reason actions exist, distinct from special pages, is that it was imagined that it would be useful to have a class hierarchy for Article, along the lines of its child class ImagePage. Actions were originally implemented with code like:
if ( $namespace == NS_IMAGE ) { $wgArticle = new ImagePage( $wgTitle ); } else { $wgArticle = new Article( $wgTitle ); } $wgArticle->$action();
CategoryPage and the ArticleFromTitle hook were later added, extending this abstraction. An object-oriented breakup of action UIs would need code along the lines of:
$wgArticle = MediaWiki::articleFromTitle( $wgTitle ); $actionObject = $wgArticle->getAction( $action ); $actionObject->execute();
That is, a factory function in the Article subclass would create a UI object. Each action could have its own base class, say ImagePageViewAction inheriting from ViewAction. It's possible to have the same level of abstraction with special pages:
class SpecialEdit { function execute( $subpage ) { $article = MediaWiki::articleFromTitle( $subpage ); $ui = $article->getEditUI(); $ui->edit(); } }
So it could be architecturally similar either way, plus or minus a bit of boilerplate. But special pages wouldn't automatically be specialised by article type, so code common to all article types may end up in the special page class. This could be a loss to flexibility, especially for extensions that use the ArticleFromTitle hook.
I agree that special page subpages are a nice way to implement actions, at least from the user's point of view. The URLs are pretty and can be internationalised. Drupal has a similar URL scheme, and it works for them.
However, in MediaWiki, the use of special subpages makes the handling of long titles somewhat awkward. Many database fields for titles have a maximum length of 255 bytes, and this limit is exposed to the user. To allow titles approaching 255 bytes to be moved etc., there is a hack in Title.php which lifts the length limit for NS_SPECIAL only. This means that the names of special subpages cannot, in general, be stored in title fields in the database. This has rarely been a problem so far, but if we move to using special subpages exclusively, we may see a few bugs filed along these lines.
Of course, an action URL can't be stored as a title either, so it's not much of a point in their favour.
Just some thoughts for discussion.
(I know Aryeh makes up his mind about things like this rather faster than I do; I look forward to his reply which will no doubt tell me all the reasons why he's not changing his position.)
-- Tim Starling
On Wed, Jan 5, 2011 at 2:32 AM, Tim Starling tstarling@wikimedia.org wrote:
Special pages are nice because they have a base class with lots of features. They are flexible and easy to add.
The main problem with actions is that most of them are implemented in that horror that is Article.php.
This is from a developer's perspective, not a user's. I was only really thinking about user-visible consistency. From that perspective, I think it's clear that using only special pages with no actions would be an improvement. I don't think the URL differences need to be reflected in the code. If you really liked, you could implement the special pages as wrappers around the current code, so the special page just called the same Article method as now (maybe with a bit of refactoring).
(I know Aryeh makes up his mind about things like this rather faster than I do; I look forward to his reply which will no doubt tell me all the reasons why he's not changing his position.)
Happy to oblige.
wikitech-l@lists.wikimedia.org