Last modified: 2008-09-26 10:40:00 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.
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.
(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.
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?
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.
Ok Brion. Thanks for your feedback. That's what I needed to know. Stupid me for changing the indentation BTW. :-*
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.
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.
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??
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.
