Last modified: 2012-10-02 18:15:04 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T20789, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 18789 - Page move should have more similar UI to delete, edit, etc. (keep tabs at top and highlight appropriate one, ...)
Page move should have more similar UI to delete, edit, etc. (keep tabs at top...
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Interface (Other open bugs)
unspecified
All All
: Normal enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
http://en.wikipedia.org/wiki/Foo
: patch, patch-need-review
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-13 19:40 UTC by Brion Vibber
Modified: 2012-10-02 18:15 UTC (History)
7 users (show)

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


Attachments
Allows special pages to use the UI of other pages (12.69 KB, patch)
2009-05-14 21:44 UTC, Happy-melon
Details
Fix the missing links (13.55 KB, patch)
2009-05-14 21:53 UTC, Happy-melon
Details

Description Brion Vibber 2009-05-13 19:40:43 UTC
To aid in UI consistency, some common actions such as page moving which are currently implemented as special pages ought to be transitioned into an 'action' URL parameter.

This'll keep the tab display more consistent.

Note that existing Special:MovePage URLs and internal links should continue to work -- they could forward to the new action=move.

Not sure if action=move or action=rename would be better.
Comment 1 Happy-melon 2009-05-13 22:15:12 UTC
Or, action=delete should be reimplemented as Special:DeletePage.  Which would be *much* cleaner in the codebase (moves largely unrelated code out of Article.php, etc), is semantically clearer IMO, and keeps the tab display more consistent :P
Comment 2 Aryeh Gregor (not reading bugmail, please e-mail directly) 2009-05-13 22:18:26 UTC
Agree that if this kind of change is made at all, actions should be moved to special pages, not vice versa.  It would be nice if everything was just based on page name and we could retire the "action" parameter entirely.
Comment 3 Trevor Parscal 2009-05-13 22:36:35 UTC
The goal of this bug was to correct the UI inconsistency of special pages which are accessed via tabs. If we are to move more code out into special pages, which sounds well supported as a good move for code cleanliness, we need to provide a way to solve the UI inconsistency as well or we will actually make the UI worse.
Comment 4 Aryeh Gregor (not reading bugmail, please e-mail directly) 2009-05-13 22:46:47 UTC
Oh, I see.  I wasn't getting that.  I've adjusted the summary to be more suitable: the point is that you want stuff like keeping the same tabs on the top (instead of becoming just "special page").  This is a UI issue, not implementation.  There are probably a lot of ways in which it differs . . . all the toolbox links and whatnot.
Comment 5 Brion Vibber 2009-05-14 20:44:17 UTC
More special pages would be a big step backwards since it would make the UI even more broken.
Comment 6 Happy-melon 2009-05-14 20:57:06 UTC
What do you mean? Is it broken in more ways than just having the wrong tabs? It seems to me that things like permissions, robot policies, caching, etc, can be more cleanly set in a special page system than in the action= system.  The UI is broken, IMO, due to its inconsistency, not because of the use of special pages per se.
Comment 7 Trevor Parscal 2009-05-14 20:59:32 UTC
What if there was a special way to register a special page as an action.

class ActionPage extends SpecialPage {
 /* stuff here that makes the special page behave like an action */
}

Then we moved all existing actions into ActionPage classes...
Comment 8 Aryeh Gregor (not reading bugmail, please e-mail directly) 2009-05-14 21:19:22 UTC
That's what I was thinking, yes.  But that would probably require a lot of refactoring if we wanted to avoid code duplication.  Making MovePage an action would admittedly be simpler, most likely.
Comment 9 Happy-melon 2009-05-14 21:28:25 UTC
I'm just looking at playing with SkinTemplate.php to allow a second Title object to be specified, the Title of the page to render most of the UI for.  Tabs are working fine now; just the sidebar.  It's probably not as clean as it could be *within* SkinTemplate.php, but the external interface is fairly nice - just a new $wgUser->getSkin->setTitleForTabs( $titleObj ) function to call from any required special page.
Comment 10 Trevor Parscal 2009-05-14 21:30:29 UTC
Just because we add the ActionPage class and it's functionality with the UI doesn't mean we have to migrate all actions immediately. They can migrate over time... SkinTemplate is what's generating the list of actions for monobook (and other SkinTemplate based skins) - so the extra code to grab actions registered from ActionPage classes would go there. As we move actions into ActionPage classes, we just update that function accordingly until everything is migrated. This will also make for a much better way to make page actions in the future.
Comment 11 Brion Vibber 2009-05-14 21:33:58 UTC
(In reply to comment #7)
> What if there was a special way to register a special page as an action.
> 
> class ActionPage extends SpecialPage {
>  /* stuff here that makes the special page behave like an action */
> }
> 
> Then we moved all existing actions into ActionPage classes...

Yuck. Why? We've already got a perfectly good way to register actions.
Comment 12 Happy-melon 2009-05-14 21:44:45 UTC
Created attachment 6118 [details]
Allows special pages to use the UI of other pages

Try this; it tweaks Special:MovePage to display all the paraphenalia of the page that's being moved.  The tabs work, and work very nicely; the sidebar currently doesn't: the WhatLinksHere, RecentChanges and Permalink links *are* processed by SkinTemplate::buildNavUrls(), but are then removed somewhere downstream; I'm not sure where. Thoughts?
Comment 13 Happy-melon 2009-05-14 21:53:30 UTC
Created attachment 6119 [details]
Fix the missing links

Found it; it was being eaten by the Monobook output template.  Yet another area where there's unhealthy amounts of obfuscation and duplication.  But meh.  What do people think of this method?
Comment 14 Roan Kattouw 2009-05-15 10:49:22 UTC
(In reply to comment #11)
> (In reply to comment #7)
> > What if there was a special way to register a special page as an action.
> > 
> > class ActionPage extends SpecialPage {
> >  /* stuff here that makes the special page behave like an action */
> > }
> > 
> > Then we moved all existing actions into ActionPage classes...
> 
> Yuck. Why? We've already got a perfectly good way to register actions.
> 

Yes, but the handlers for these actions are often in the 'wrong' classes (mostly Article), resulting in poor DB/UI separation. Of course putting the UI for an action in its own class is no guarantee for proper separation, as evidenced by the way subpage moving was implemented.
Comment 15 Daniel Friesen 2011-02-10 05:07:47 UTC
1.18 supports $sk->setRelevantTitle( ... ); now and is used in Special:Movepage so that the tabs stay the same. SkinTemplate was also tweaked so that the movepage tab will be selected like the other tabs are.
Comment 16 p858snake 2011-04-30 00:10:08 UTC
*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*
Comment 17 Bugmeister Bot 2011-08-19 19:12:44 UTC
Unassigning default assignments. http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/54734
Comment 18 db [inactive,noenotif] 2012-10-02 18:15:04 UTC
fixed with r79398

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


Navigation
Links