fixing bug 32621 is a todo. The first attempt failed
and some tweaks
are needed to use the PathRouter to fix that bug.
PathRouter allows for the use of custom paths to expand.
NamespacePaths is an example of one thing you can do (say giving
Help: pages a /help/ path) but you could also apply that to special
pages, etc... whatever. It's also the precursor to MW being able to
handle 404s natively. The plan is in the future you'll just be able
to throw everything that's not a file right at index.php and pretty
urls, 404 pages, 404 thumbnail handlers, etc... will all just work
natively without any special configuration.
And by 404, I don't mean standard 404 pages like this:
http://wiki.commonjs.org/404
I mean nice in-site 404 pages that actually help visitors find what
they were looking for:
http://www.dragonballencyclopedia.com/404
Not sure how PATH_INFO being unmangled fixes anything. There are
other servers where PATH_INFO won't easily be outputted. REQUEST_URI
handling works better in every case. And ?title=$1 in rewrite rules
are evil. Determining what urls run what code has always been the
job
of the application in every good language, not the webserver. And we
can do it using REQUEST_URI much more reliably than some webservers.
Anyways, I wish I could just get rid of the PATH_INFO code. I have
yet to hear of someone actually using it now that practically every
webserver there is outputs REQUEST_URI meaning the PATH_INFO code is
never reached.
Thanks for answering!
But wasn't all that possible with just using something like
$wgActionPaths?
Unmangled PATH_INFO allows for a single rewrite rule like (.*) ->
index.php/$1 to and you won't need to strip base from URIs (yet of
course it's not hard)
And you say PATH_INFO is unavailable on some configurations - can you
please clarify what are these configurations?