&action= which can end up being handled through an Action class, the MediaWikiPerformAction hook, the UnknownAction hook, handled as a hardcoded list in a switch deciding what Article class method to call, or as the history action is handled in that switch by creating a new HistoryPage and running it.

Special pages executed from Special:* pages.

Articles handled through an Article class

Articles in certain namespaces handled through an ImagePage or CategoryPage class.

The proposal is to replace this with these patterns:

Articles handled by a class handling the view of an article

Special articles like File: and Category: handled by a subclass of the class handling an article's view

SpecialPage classes accessible through a Special:* page, &action=, or a $wgActionPath style $wgSpecialPagePath.

Relocate functional logic about what tabs/actions are relevant to a page[edit | edit source]

These are currently is hardcoded into SkinTemplate which is a bad place for them as skin systems are not supposed to handle functional logic like this but rather how to present that functional information.

The functional logic declaring tabs/actions for a page would be relocated to classes in charge of handling the view of a type of page.

SpecialPages should also extend a base class for classes in charge of the view of a page and take on a similar role in generating the tabs ui component for a page. Most special pages will inherit their tabs from SpecialPage and get the usual "Special" NS tab and no action tabs. Others may define their own custom tabs and have those in the page. And others like Special:Movepage or a Special:Edit will have a WikiPage for the page they are editing and will defer their own set of tabs to that of the page they are editing.

Migrate existing actions to special pages and implement transitions to the new pattern[edit | edit source]

Actions inside /includes/actions/ as well as actions still built into Article will be converted into Special: page implementations in /includes/specials/.

Actions have $wgActionPaths which don't work for special pages, for this reason a $wgSpecialPagePaths will likely supplant it. For compatibility with old configs when we've migrated actions to special pages Setup.php will likely convert $wgActionPaths to $wgSpecialPagePaths.

When actions are completely eliminated we can replace the &action= compatibility code with code that instead converts ?title=Foo&action=Bar into ?title=Special:Bar/Foo, this will have two side effects. Making things like ?title=Foo&action=whatlinkshere and ?title=Foo&action=movepage work and also bringing the special page i18n to actions so things like ?title=Foo&action=移動 will work too. It's a little odd but technically ?action=recentchanges could work if a user explicitly wrote it. It could be advantageous to make sure things like Special:Contributions/User:Foo function so that things like ?title=User:Foo&action=block will start working.

Building action links is easier in code than special page links for actions, so we should definitely add that handling into getLocalURL so that we can continue using $title->getLocalURL('action=edit'); and start using $title->getLocalURL('action=whatlinkshere'); too. The addition of $wgSpecialPagePaths should also be accounted for.

On installations like Wikipedia actions have another advantage in how they generate /w/index.php?title=Foo&action=edit type paths which allow them to be implicitly hidden from bots using robots.txt and a disallow rule on /w/. To prevent an issue where we start outputting /wiki/Special:Edit/Foo and undo that we can include a registry of special pages which should output long urls. All the actions we convert to special pages will be included. And other special pages like MovePage and Special which are equally problematic can be added to this. SpecialPages on this list will output in the format /w/index.php?title=Foo&action=edit taking advantage of the action->special mapping. The addition of a path to $wgSpecialPagePaths will override this behaviour for that special page. SpecialPages like Special:Search which are usually created as /wiki/Special:Search when included on the list will start outputting like /w/index.php?action=search. (This could actually permit Wikipedia to remove 33 lines of robots.txt code dedicated to hiding Special:Search from search engines)