Manual talk:Very short URL

From MediaWiki.org
Jump to: navigation, search

Contents

[edit] Terrible

this guide is god awful. Why not move each way that a person can modify a Very short url to the talk page until a couple of other people confirm that it works, or somehow keep track of which way works Odessaukrain 08:30, 6 October 2007 (UTC)

I moved, The ampersand problem, a terrible explanation to talk (here).

The decent solutions will go to the another page.

The kludge and mediawiki expanation, according to other editors doesnt work and can have really bad consequences.

[edit] The ampersand problem

A correct edit URL in this scheme would look like:

http://wiki.site.tld/Article_Name?action=edit

One of the many problems with this scheme is that you cannot separate edit pages and other dynamic content from the plain page views in robots.txt. This means you either must hide your entire site from search engines, or you will receive much more load from spiders than you would like.

After rewriting, we want the URL to look like this:

http://wiki.site.tld/index.php?title=Article_Name&action=edit

There is no need to patch Apache -- using [QSA] on the rewrite rule does this automatically.

[edit] MediaWiki

Function getLocalURL in includes/Title.php needs to be modified as follows. As of 1.5.5 this was line 781:

-  $url = "{$wgScript}?title={$dbkey}&{$query}";
+  $url = "/{$dbkey}?{$query}";

As noted above, this will destroy the ability to separate dynamic requests from page views in robots.txt and will create useless extra traffic for your server. It is highly recommended that you do not do this.

Function view in includes/RawPage.php needs to be modified as follows. As of 1.5.5 this was line 73:

-  if( strcmp( $wgScript, $url ) ) {
+  if( 0 and strcmp( $wgScript, $url ) ) {

This disables protection against a cross-site scripting vulnerability for Internet Explorer clients. DO NOT DO THIS if you want to cater to broken software products!


In LocalSettings.php, make sure these variables are set as follows:

$wgScript = "";
$wgScriptPath = "";
$wgArticlePath = "/$1";

Fin.

$wgScript should always be set to an actual URL path to the script. Making it empty may create invalid form actions and other URLs, and may break on some browsers.

[edit] Kludge

If you aren't going to use a patched Apache server, do the following:

  • Apply the changes to MediaWiki as instructed in the previous section, except that the line in includes/Title.php has an ampersand instead of a question mark:
$url = "/{$dbkey}&{$query}";
  • Apply the changes to httpd.conf as instructed above, except:
    • The RewriteMap line is omitted;
    • The final RewriteRule line is:
RewriteRule ^/(.*)$ /index.php?title=$1 [L]

This solution generates URLs that contain ampersands where the question marks should be. The RewriteRule will insert the question mark in the proper place.

In practice, it works fairly well. Smart URLs, such as those used in Firefox, will need to have an ampersand where the question mark would normally be. There may be other situations in which it could cause problems.

Don't do this either -- it will create a large number of broken links if you ever change back to a correct configuration. It's also completely unnecessary, as the problem it's meant to solve doesn't require patching Apache. Use the [QSA] option on the rewrite rule. (The ampescape patch is for a different issue, which as far as I can see this would not help with.)

Odessaukrain 18:48, 6 October 2007 (UTC)

Personal tools
Namespaces

Variants
Actions
Navigation
Support
Download
Development
Communication
Print/export
Toolbox