Page MenuHomePhabricator

Foo?action=info should rather be Special:PageInfo/Foo instead
Closed, DuplicatePublic

Description

Foo?action=info should rather be Special:PageInfo/Foo instead


Version: unspecified
Severity: enhancement

Details

Reference
bz41836

Related Objects

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 12:46 AM
bzimport set Reference to bz41836.
bzimport added a subscriber: Unknown Object (MLST).

I believe this is a duplicate of another bug. I know this has come up previously on wikitech-l.

Basically, actions are all inconsistent. Special:MovePage, Special:Undelete, etc. vs. ?action=history, ?action=protect, ?action=edit, etc. There are concerns with switching to Special pages (such as page links only tracking up to 255 bytes) and there are concerns with switching to actions (such as not having a title to work with).

Generally, if we switch to Special pages, I think we'll end up with Special:Action/Edit/Foo or something. Maybe.

Is there any reason you think the info action in particular should be switched to a (dedicated) Special page?

To juice up Daniel:

Title?action=* should be Special:../Title..

(In reply to comment #1)

Basically, actions are all inconsistent. Special:MovePage, Special:Undelete,
etc. vs. ?action=history, ?action=protect, ?action=edit, etc. There are
concerns with switching to Special pages (such as page links only tracking up
to 255 bytes) and there are concerns with switching to actions (such as not
having a title to work with).

If we were doing it all over again--we'd be writing special pages and not action urls. The only reason we've still got them is for legacy reasons. I remember complaining when actions were rewritten that we were wasting our time solidifying architecture that should just die.

Generally, if we switch to Special pages, I think we'll end up with
Special:Action/Edit/Foo or something. Maybe.

Special:Action/Foo/Bar is just as bad as title=Bar&action=Foo. Comment #2 is the way I'd like to see it...
Special:History/Foo, Special:Edit/Foo, etc etc etc.

Is there any reason you think the info action in particular should be switched
to a (dedicated) Special page?

Because *all* actions should be special pages. We should kill every last one of these blasted actions and have them redirect to appropriate special pages.

Design-wise I don't see how this is a good idea at all. Other than cosmetic differences, what's the difference between article?action=foo and Special:foo/article? If anything, the distinction is separate for a good reason. Actions should be reserved for just that, actions, i.e., operations that affect a singular article, such as edit/move/view/delete/undelete/etc.

(In reply to comment #5)

Design-wise I don't see how this is a good idea at all. Other than cosmetic
differences, what's the difference between article?action=foo and
Special:foo/article? If anything, the distinction is separate for a good
reason. Actions should be reserved for just that, actions, i.e., operations
that affect a singular article, such as edit/move/view/delete/undelete/etc.

It is actually the opposite. To the user the difference is just url cosmetics, but that's quite irrelevant in this discussion. Though the pages for an action and a special page look very similar, they are built in very different ways. And the problems we had with the tab and toolbox adapting to the correct page shows this problem.

We're talking about the backend usage of using a SpecialPage vs. Action subclasses. The proposed situation here is that over the years the differences for having these separately (where Actions were formerly just methods on the Article class) have reduced if not, become no longer applicable.

For example the following ones are all related to a page (query):

  • Special:WhatLinksHere
  • action=view
  • action=history
  • action=info

And these as well (more manipulations of state, less information retrieval):

  • action=delete
  • Special:Undelete
  • Special:MovePage
  • action=purge
  • action=edit
  • action=protect

So it makes sense to have one back-end interface for pages, and have a method for setting the page context (which would affect the tab bar, page title and toolbox).

One interesting difference is that actions don't take parameters (you can't go to action=history and enter a page name, but you can go to Special:WhatLinksHere and enter a page name).

  • Bug 41930 has been marked as a duplicate of this bug. ***

A year later... what is the status of this report? Can you agree on a plan to resolve it?

(In reply to comment #8)

A year later... what is the status of this report? Can you agree on a plan to
resolve it?

Like most normal and lower priority bugs, it hasn't been worked on and just needs someone with enough cycles to do the work. It's not hard.

If the plan is clear and its implementation is not hard, would it make sense to propose it as a Google Code-in task?

https://www.mediawiki.org/wiki/Google_Code-In

One interesting difference is that actions don't take parameters (you can't go to action=history and enter a page name, but you can go to Special:WhatLinksHere and enter a page name).

Actions take parameters. Though I think you meant inputs here, given the parenthetical? An easy example is action=edit, which has plenty of inputs. Even if you do mean URL(?) parameters, actions such as action=history take those for sure. As do action=edit and action=delete.

For what it's worth, I'm still not sure whether the info action should be an action or a Special page. Consequently, I don't know if this task is actionable.