* Refactored the IE script entry point security check into WebRequest::isPathInfoBad(). Use the standard CGI variable PATH_INFO to do this check instead of the various potential non-standard solutions. Made the check fairly permissive to avoid a repeat of bug 13049 due to broken CGI setups especially with cgi.fix_pathinfo=0. This should theoretically be very portable and secure, but I have not tested it widely.
* Removed Chris Wrinn from the credits since his patch was wrong and has been removed.
* Made the error message more informative.
* put a @ in front of get_headers() should hopefully avoid errors where allow_url_fopen=0
* combined $wgPhpCliPath into the similar used $wgPhpCli var
* minor js & example file mwEmbed fixes
Raw page access was failing in some server configurations with CGI (or
in my case, FastCGI). This gives a nicer and more correct error
message. Possibly better solutions:
1) Figure out how to do this without PHP_SELF.
2) Give a warning or error on installation, or even on every page view,
since this will break all raw page viewing.
I ran into this when doing a file copy of my wiki install to another
site, FWIW. Even with the new error message, I'd have had to look at
the CSS files to figure out what the problem was (the user-visible
symptom was that custom styles didn't work).
* Add a clearFileCache() function in the place of various unlink() calls. This also clears the raw page cache.
* Fix useFileCache() for loop
* Add mType field to file cache objects
* Moved SkinTemplate::addStyle() and related stuff to OutputPage so that it can be used non-SkinTemplate skins and avoid duplication with the actual OutputPage::addStyle() (the two functions have the same format).
* Non-SkinTemplate skins now also load their CSS with <link> tags instead of @import.
* Moved SkinTemplate::setupUserCss() to Skin.
* Merged action=raw&gen=(js|css) for SkinTemplate and non-SkinTemplate skins, renamed functions to Skin::generateUserJs() and Skin::generateUserStyleSheet() and dropped a lot of cascading call which is a bit incomprehensible.
Doxygen documentation update:
* Changed alls @addtogroup to @ingroup. @addtogroup adds the comment to the group description, but doesn't add the file, class, function, ... to the group like @ingroup does. See for example http://svn.wikimedia.org/doc/group__SpecialPage.html where it's impossible to see related files, classes, ... that should belong to that group.
* Added @file to file description, it seems that it should be explicitely decalred for file descriptions, otherwise doxygen will think that the comment document the first class, variabled, function, ... that is in that file.
* Removed some empty comments
* Removed some ?>
Added following groups:
* ExternalStorage
* JobQueue
* MaintenanceLanguage
One more thing: there are still a lot of warnings when generating the doc.
While only MSIE is known to let the URL's "extension" override the allowed mime types, other browsers will still happily download a file with the name from the URL. That seems unwise as the content may be arbitrary (and perhaps executable).
PHP's fuzzy type comparisons strike again! A check for $this->mSection != '', probably intended to protect against an unset value, matched for integer values of 0 as well. (The fun part is that 0=='' and 0=='0' but '0'!='' :) Since the parameter is validated through getIntOrNull(), only the null check is necessary here.
This doesn't actually do the job; browsers aren't this picky about their JavaScript, and many aren't picky about CSS either. Further, this actually breaks internal JS such as the gen=js mode.
* Seems like an opportune time to introduce "@addtogroup Media" documentation tags.
* Merge "@addtogroup Metadata" (used by Exif.php) into "@addtogroup Media".
* Few more moving comment blocks to above classes.
while avoiding clobbering of different users' cached data
Added a "Vary: Accept-Encoding, Cookie" a few weeks ago on generated CSS/JS
files to prevent different users' styles from clobbering each other in
caches. Unfortunately browsers don't seem to handle Vary well, and this
caused a lot of extra hits due to poor caching.
This is now removed, replaced with an explicit "Cache-Control: private"
or "Cache-Control: public" depending on the presence of an open session
cookie or logged-in state. This should restore the friendly caching
behavior while ensuring that no users' generated data will clobber
anyone else's.
To additionally ensure that public cached CSS doesn't clobber the
private bits, smaxage=0 is set on the URL used for logged-in views,
as already done for JS.
preferences don't get stuck in proxy caches for other people
Man this one's embarassing, we should have fixed it ages ago.
This should I think fix the longtime problem where people sometimes
see things like underlining of links change spontaneously.
* remove require_once() throughout whole code, yet left in few places
* move global functions in HttpUtils, ProxyTools, Credits to class methods
* php5 only: __autoload() now used, combined with class->file map and require()
* move initialization of $wgValidSkinNames to Skin::getSkinNames()
* few more changes that will surely break stuff.
