Page MenuHomePhabricator

Make clean script path the default canonical url for the Main Page
Closed, DuplicatePublic

Description


Objective

Make the wiki's main page available at a canonical URL that is consistent regardless of wiki's language or configuration.

This would mean that by default when installing MediaWiki at /w:

  • Viewing https://wiki.example/w it will respond HTTP 200 OK, and render the Main Page.
  • The link in the sidebar for the Main Page points at /w.
  • <link rel=canonical> on the Main page (no matter what url it is viewed through) refers to https://wiki.example/w.
Advantages according to T120085
  • Faster page load times, by avoiding a common redirect.
  • Not exposing the internally inconsistent naming conventions of our wikis in search results.
  • Improved SEO for third-parties (not applicable to WMF), per Avoid Landing Page Redirects.

Other reasons:

  • Easier for test tooling by having a consistent and predictable url for the main page.
  • Having a canonical URL that doesn't become a redirect (or dead) when the wiki's configuration is changed, or if the page is renamed for other reasons.

Details

Supported web servers all responds with index.php when viewing the script path. As such, I think we can and should enable this by default.

I'm proposing though, that the default is limited to using the script path as the canonical url, not the domain root. It depends on site configuration whether the domain root is actually rewritten to MediaWiki or not. That is, a domain may have something else at its root and only serve MediaWiki through a sub directory, for example.

Assuming we implement this in a simple and configurable way, then site administrators that do rewrite their domain root to MediaWiki can also flip a configuration switch that will make all the above refer to / instead. The how-to guide at https://www.mediawiki.org/wiki/Manual:Short_URL/Apache also recommends this by default.

As such, most third-party wikis and all WMF wikis, use this already. Without such rewrite, users would not find the wiki when navigating to the website's domain name. Notable exceptions are websites having a wiki as a secondary aspect and not on its own (sub)domain.

See also

T120085 proposes this for for Wikipedia and/or other WMF wikis. We should probably experiment more there fist before considering this as the default.

Event Timeline

Krinkle created this task.Feb 22 2019, 1:58 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 22 2019, 1:58 AM

Would it perhaps be better to have it as a redirect to Main_Page (or whichever page the admin wants it to point to) ? Without a redirect, the canonical URL would also get cached in Varnish (could be exempted, but...), and it can also mistakenly be taken for the landing page (which it is not).

Krinkle moved this task from Inbox to Backlog on the TechCom board.Mar 6 2019, 9:37 PM
Krinkle moved this task from Backlog to Inbox on the TechCom board.
Krinkle edited projects, added TechCom-RFC; removed TechCom.Mar 6 2019, 10:07 PM
Anomie added a subscriber: Anomie.Mar 7 2019, 3:21 PM

Would it perhaps be better to have it as a redirect to Main_Page (or whichever page the admin wants it to point to) ?

That's the status quo. See for example https://en.wikipedia.org/wiki/.

That strikes me as odd, since (1) this task was just announced in the TechCom Radar email, and (2) that task is about WMF, while this one is about MediaWiki's defaults. This seems the better one for an RFC, IMO.

@Anomie I don't think the decision of whether MW will have such an option would require an RFC. That seems trivial to decide on between +2'ers and/or escalate to CPT if it affects long-term maintenance costs.

Likewise, I also don't think it would require an RFC to decide over its default value. That seems like a product decision CPT may execute on its own. If wider consultation is preferred and the RFC venue is where you'd like to do so, then I'd be happy to help host that conversation when the time comes as an RFC, no problem.

What I'm personally more interested in, however, is how enabling for WMF would impact WMF's technical stack, and what WMF would like for its readership experience. That's definitely RFC-scope and the harder question to answer. I choose the older of the two as the destination for the merge.

Krinkle updated the task description. (Show Details)Mar 9 2019, 9:50 PM
Aklapper removed a subscriber: Anomie.Oct 16 2020, 5:38 PM