Page MenuHomePhabricator

Use article path URLs for editing, previewing skins, etc.
Open, LowestPublicFeature

Description

Author: onekopaka

Description:
Very easy fix. If clean URLs are in use we should use things like this:
wiki/index.php/Sandbox?action=edit

Currently we do things like this:
wiki/index.php?title=Sandbox&action=edit

The first is much cleaner, and used by competing wiki software such as MoinMoin.

They work just the same, see the URL, which is demonstrating the first style of URLs.
Works like this just fine on Wikimedia sites:
wiki/Sandbox?action=edit

This task matches Clean up URLs.


Version: 1.11.x
Severity: enhancement
URL: http://onekopakaspace.strangled.net/wiki/index.php/User:Deathgleaner/HybridSandbox?action=edit

Details

Reference
bz12619

Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 21 2014, 10:07 PM
bzimport set Reference to bz12619.
bzimport added a subscriber: Unknown Object (MLST).

Then what happens when someone uses path to query rewrites?

/wiki/Sandbox?action=edit
becomes:
/index.php?title=Sandbox?action=edit
Then no-one is able to edit...

Something like this is already possible if someone configures it that way in $wgActionPaths.
Things like this should not be automatic, because there is a strong chance that new setups may be broken by it.

(The rewrite case mentioned in comment #1 would be due to misconfigured rewrite rules -- you should use the QSA option, otherwise you break various forms in the system as it is.)

While it would be possible to append various options direct to a plain view path, there are several arguments against it. Chief among them are my favorites:

First, the lack of a consistent prefix for non-view links means they can't be excluded cleanly from robots.txt; this can lead to excessive search spider traffic. (Meta tags will keep edit pages and such out of indexes, but the spider has to load the pages to reach the meta tags.)

Second, autocomplete algorithms in browser URL bars will sometimes pick up such URLs, and you find yourself acccidentally hitting enter for a different action than you intended. Personally I find that a bit annoying. :)

The first is functional and the second is merely aesthetic, but I consider them worthy. :) My own preference for prettier action URLs is to add additional prefixes with $wgActionPaths and either stub scripts or rewrite rules, eg /edit/Sandbox

(In reply to comment #2)

First, the lack of a consistent prefix for non-view links means they can't be
excluded cleanly from robots.txt;

This is no longer the case as search engines now support glob rules: https://www.mediawiki.org/wiki/Requests_for_comment/Clean_up_URLs#Migration

Second, autocomplete algorithms in browser URL bars will sometimes pick up
such
URLs, and you find yourself acccidentally hitting enter for a different
action
than you intended. Personally I find that a bit annoying. :)

At least in Chrome, the same is actually true for the ugly /w/index.php?title=...&action=..., but in that case it is harder to get to the actual article URI by just deleting the query.

Spage subscribed.

This bug is in the spirit of Clean up URLs RFC after it was slimmed down, so I'm joining them in the RFC process.

(And I support it.)

@GWicke (and @onekopaka), the Architecture Committee would like to discuss your RFC next week, can you attend the RFC office hour April 1?

Do you have a patch implementing this change?

I think there are two decisions:

  1. Do we do this on Wikimedia wikis?
  2. Do we make this the default for new MediaWiki installations? (without changing URLs on existing wikis).

@Spage, my focus is currently more on the API portion, which is discussed in T95229: Set up an API base path for REST and action APIs. I'm still supportive of the effort to clean up edit paths etc as well, but would welcome if somebody else would champion / implement it.

Status approved by Tim Starling in http://tools.wmflabs.org/meetbot/wikimedia-office/2015/wikimedia-office.2015-04-08-21.00.html 2015-04-08 IRC RFC discussion, with the caveat that a permanent redirect should be considered over a varnish rewrite.

Now we need implementation.

Why was the RFC simply accepted with absolutely no discussion over the negative effects of blacklisting /wiki/*? which I brought up on wikitech-l and on the RFC's talkpage:

https://www.mediawiki.org/wiki/Talk:Requests_for_comment/Clean_up_URLs#robots.txt

Making this change will make it impossible to fix the bugs in indexing of MediaWiki installations, and discussion has just skipped straight over these negative effects and approved it.

In reply to T14619#1192903:

I've created a subtask T95625 for robots.txt mentioning your concerns, on the theory that this task is about the intention and the subtasks are about the implementation. Drag this task to "under discussion" on #MediaWiki-RfCs if you want the architecture committee to reopen it.

Krinkle renamed this task from cleaner URLs for editing, previewing skins, etc. to Use article path URLs for editing, previewing skins, etc..Jan 6 2016, 9:14 PM
Krinkle removed a subscriber: wikibugs-l-list.

Note that a bug has been identified with this url pattern, which may need to block further adoption of it. It's not blocked conceptually though, and the bug is certainly fixable: T123276: URL parameters do not work with pages that have "?" in their names

Aklapper changed the subtype of this task from "Task" to "Feature Request".Feb 4 2022, 11:02 AM
Aklapper removed subscribers: Spage, GWicke.