happy.melon.wiki wrote:

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

ayg wrote:

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.

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.

ayg wrote:

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.

More special pages would be a big step backwards since it would make the UI even more broken.

happy.melon.wiki wrote:

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.

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...

ayg wrote:

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.

happy.melon.wiki wrote:

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.

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.

(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.

happy.melon.wiki wrote:

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?

attachment diff.txt ignored as obsolete

happy.melon.wiki wrote:

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?

Attached:

(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.

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.

*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*

mhershberger wrote:

Unassigning default assignments. http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/54734

fixed with r79398