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

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
bzimport raised the priority of this task from to Lowest.
bzimport set Reference to bz12619.
bzimport added a subscriber: Unknown Object (MLST).
bzimport created this task.Jan 14 2008, 1:06 AM

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

GWicke added a comment.Jan 3 2014, 5:08 PM

(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 added a subscriber: Spage.

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

Spage moved this task from Inbox to Backlog on the TechCom-RFC board.Feb 26 2015, 7:08 PM
Spage assigned this task to GWicke.Mar 25 2015, 8:59 PM

@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).
fbstj awarded a token.Apr 8 2015, 7:17 AM
GWicke added a comment.EditedApr 8 2015, 5:07 PM

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

Spage updated the task description. (Show Details)Apr 8 2015, 8:32 PM
Spage removed GWicke as the assignee of this task.Apr 9 2015, 1:49 AM

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.

Spage updated the task description. (Show Details)Apr 9 2015, 1:51 AM
Spage moved this task from Under discussion to Approved on the TechCom-RFC board.

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.

Spage added a comment.EditedApr 9 2015, 10:09 PM
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 TechCom-RFC if you want the architecture committee to reopen it.

Nemo_bis removed a subscriber: Nemo_bis.Apr 10 2015, 7:50 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 1 2015, 10:08 AM
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.