Last modified: 2008-09-26 10:40:00 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 13348 - Respect wgArticlePath and wgActionPaths options for all URLs
Respect wgArticlePath and wgActionPaths options for all URLs
Status: RESOLVED INVALID
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
1.12.x
All All
: Normal enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
http://wiki.hardwood-investments.net/...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-13 21:11 UTC by Rowan Rodrik van der Molen
Modified: 2008-09-26 10:40 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
This patch makes links more consistent, resulting in overal cooler URLs (3.80 KB, patch)
2008-03-13 21:11 UTC, Rowan Rodrik van der Molen
Details

Description Rowan Rodrik van der Molen 2008-03-13 21:11:46 UTC
Created attachment 4711 [details]
This patch makes links more consistent, resulting in overal cooler URLs

I've been using the $wgArticlePath and the $wgActionPaths settings on my wikis for some time. However, I've been annoyed that many links with a query string included don't use these settings. This results in links such as /index.php?title=Special:Recentchanges&feed=atom instead of /Special:Recentchanges?feed=atom

To enable the latter form, this patch changes Title->getLocalURL() in a way that is best explained by the following diff excerpt:

-        * @param string $query an optional query string; if not specified,
-        *      $wgArticlePath will be used.
+        * @param string $query an optional query string

This patch also removes a hidden input from the diff form on history pages. Apparently, the input has often been changed in incompatible ways, but I simply cannot figure out why it would have to be there in the first place... :-/  Keeping it there means that you get the title in the $_GET params twice! Anyway, please correct me if I'm wrong.

Please reply accordingly if there's no chance of this patch being accepted. In that case, I'll try to roll it into an extension so that I don't have to keep patching for ever and ever and ever.
Comment 1 Daniel Friesen 2008-03-14 06:02:13 UTC
There is no guarantee that the server configuration method which is being used which will support the /wiki/Pagename?query format.

This would be a case of path to query rewrites.
If someone was using a path to query rewrite. Then the following url:
http://example.com/wiki/Foo?bar=baz
Would map to:
http://example.com/index.php?title=Foo?bar=baz
And you would suddenly go from the article [[Foo]] to the article [[Foo?bar=baz]], not where you were supposed to be directed.

So, if MediaWiki was setup to use that format of url, suddenly any wiki which uses path to query rewrite rules would have every single long url inside their wiki (Including edit links, feed links, login links, etc...) become broken and unusable.

I suggest WONTFIX.
Comment 2 Brion Vibber 2008-03-14 17:15:47 UTC
(In reply to comment #1)
> There is no guarantee that the server configuration method which is being used
> which will support the /wiki/Pagename?query format.

They're already required to support that or the search form doesn't work.

Non-broken mod_rewrite configurations are to use the QSA option to append query string information.
Comment 3 Rowan Rodrik van der Molen 2008-07-02 22:57:36 UTC
Is there any change that this patch will get implemented?

I would really like to use this on all my MW installations, but right now that would feel like forking. Is there any reason this patch wasn't accepted the months ago when I submitted it? Or is it just a case of not enough time?
Comment 4 Brion Vibber 2008-07-04 23:20:18 UTC
We keep non-regular-views distinct deliberately, for a couple of basic reasons:

* They can be mass-blocked by robots.txt to keep spiders from hitting them
* For some things like the raw action, allowing arbitrary "file extensions" on the article/action path is unsafe (can trigger type detection in MSIE, leading to HTML/JS injection / XSS attacks).

As such I'd recommend against accepting this patch.


As a general style note for patches; the patch seems to change a lot of the indentation from tabs to spaces, making it harder to see what's changed and making it harder to read and maintain the code.

There's also a change to PageHistory.php here which will break diff submission on configurations with "ugly URLs" (where $wgArticlePath puts the title in the query string). A query string on the form action URL will be overwritten when submitting forms via GET.
Comment 5 Rowan Rodrik van der Molen 2008-07-05 08:31:59 UTC
Ok Brion. Thanks for your feedback. That's what I needed to know. Stupid me for changing the indentation BTW. :-*
Comment 6 Marco von Frieling 2008-09-25 13:35:27 UTC
I haven't looked at the patch for details, but I had the same problem with this and were just looking for similar bug reports before creating a new one. My problem is with a wiki family for multilanguage support. Here is my configuration (on Debian server, names are NOT real):

$wgScriptPath = '/wiki_install_folder/';
$wgUsePathInfo = true;
$wgArticlePath = '/de/$1' # and '/en/$1' etc. in the other language wikis

Apache is configured to alias /de /en etc. to /var/www/wiki_install_folder/index.php. wiki.mydomain.com/ redirects permanently to wiki.mydomain.com/de/

Here the problem is that all the links not using wgArticlePath (Login, ...) will loose the language information and everything operates on the German wiki, I'm not able to let it operate on the English one or whichever.


I've modified the getLocalUrl() function by replacing the line (near the end of the function)

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

with these ones:

  // here we have only 'raw' as action or action is not set
  // if action is 'raw' don't change behavior because of
  // security reasons (see documentation)
  if ($action == 'raw'){
    $url = "{$wgScript}?title={$dbkey}&{$query}";
  } else{					
    $url = "{$wgArticlePath}?{$query}";
    // assuming that $wgArticlePath contains the $1 placeholder for the sitename
    $url = str_replace('$1', $dbkey, $url);
  }

Sorry for not providing a patch file, but I only have the installed 1.13.1 package for debian and no SVN sources of mediawiki.
Comment 7 Daniel Friesen 2008-09-26 03:33:32 UTC
That's not a bug, that's a misconfiguration on your part.

You can't use different article paths for different wiki, then use the same script path for all of them. That basically means that any use of the api will also be broken.

You should be aliasing a separate script path for the different wiki if you want to do it that way.
Comment 8 Marco von Frieling 2008-09-26 10:19:49 UTC
Hello Daniel,

I can't follow you. I've exactly done what's described here, then I got the problem:

http://www.mediawiki.org/wiki/Manual:Wiki_family#Scenario_3:_Quick_set-up
http://www.mediawiki.org/wiki/Manual:Short_URL#Recommended_how-to_guide_.28setup_used_on_Wikipedia.29

So if it should not be done, why then is it documented in the mediawiki manual - AND - done on wikipedia.org itself??
Comment 9 Matt Johnston 2008-09-26 10:40:00 UTC
Wikipedia itself does not do that - you must have misread the docs. You need a seperate visible script directory (e.g. it has to be on a different URL, although the files can be the same location on disk e.g. symlinks). In short, each wiki needs a unique script path and article path.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links