Requests for comment/Drop actions in favour of page views and special pages
| Drop actions in favour of page views and special pages | |
|---|---|
| Component | General |
| Creation date | |
| Author(s) | Daniel Friesen |
| Document status | in discussion See Phabricator. |
We currently handle pages with the following patterns:
- &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.
Actions to be taken in implementation
[edit]Relocate functional logic about what tabs/actions are relevant to a page
[edit]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]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)
Problems solved here
[edit]- Edit pages and other actions will become easily linkable via a Special:Edit/Foo pattern.
- Special:Search and Special:MovePage will be cloaked by /w/ and no longer suffer problems that &action=edit doesn't have.
- SkinTemplate won't be hardcoding logic about actions relevant to a page.
- Bug 26918: Create a clean interface to plug in (other/any) editor frontends; they could be available beside each other using Special:WikiEditor/..., Special:VisualEditor/..., Special:FCKEditor/...
- ...
Issues possibly introduced here
[edit]- Current robots.txt files may be insufficient
- The plan includes outputting index.php?title=&action= urls for those titles we're already doing it for, and a few more where it should be done so current robots.txt files should be fine
- By deprecating action URLs, we will be forcing extensions using the MediaWikiPerformAction and UnknownAction hooks to update
- This can avoid immediate breakages by not deprecating the URLs just yet, but discouraging them in documentation.
- At 15:01, 31 August 2011 (UTC) there are 27 extensions in Subversion using these hooks. See page source for details.
- Imagine:
/api.php?action=Special:Delete&titles=.... Page/action differentiation makes a lot of sense.- Title interpolation is already short circuited for the api, this shouldn't have any effect on the api. Dantman 07:39, 6 September 2011 (UTC)
- ...