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?


_______________________________________________
Wikitech-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Reply via email to