* Also updated classes in includes/revisiondelete that were using the $skin member of Special:RevisionDelete
* Handle action=revisiondelete (or rather action=historysubmit&revisiondelete=1) with an Action object that sets the RequestContext object of the SpecialPage object, and in this case get the target Title object through the context instead of $wgTitle
* Moved most of the bug 28235 code out to a separate library class, since I was running out of distinct function names.
* Merged the QUERY_STRING and PATH_INFO security checks, since they are dealing with the exact same problem. Removed WebRequest::isQueryStringBad().
* Deal with img_auth.php by having it specify what extension it expects to be streaming out. This extension can then be compared with the extension that IE might detect.
Per CR http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89406#c17545 :
'Here is a third one: Strict Standards: Only variables should be passed by reference in /www/sandwiki/includes/Wiki.php on line 177 '
Offending bit is this:
- SpecialPageFactory::executePath( $this->context->title, $this->context );
+ SpecialPageFactory::executePath( $this->getTitle(), $this->getContext() );
That function demands reference paramters for $title and $context, which is being violated here where we now pass function return values:
public static function executePath( Title &$title, RequestContext &$context, $including = false ) {
The $title does sometimes get replaced within the function body, but $context does not appear to ever be replaced (its *contents* are modified, which does not require passing by reference)
If replacing it is something it should be doing, then we need to be able to replace it upstream presumably, so $this->getTitle() probably isn't appropriate.
The $context probably should have the reference simply removed.
* One less entry point to worry about
* Completely obsolete by load.php and api.php
* Left $wgDebugRawPage in place, also affects load.php requests (docs already reflect)
* Affects dumpHTML (probably broken anyway, has anyone RL-ified this?), and two abandoned/obsolete extensions
* Set EnableHipHopSyntax=true to enable string and integer type hints. I gave the file a .hphp extension to avoid false alarms in syntax checking scripts.
* Made sure almost all the local variables in preprocessToObj() have a specific type, instead of being variants. This is useful for integers, but has the largest impact for objects, since dynamic method calls can be avoided.
* Stopped using extract() since it forces all local variables to be variants, and adds some hashtable initialisation overhead.
* Found a way to cast a variant to a specific object class, by abusing argument type hinting. The method does not require special syntax; it is harmless in Zend PHP.
* Wrapped various internal function calls with type casts. strspn() and substr() need to be wrapped with intval() and strval() respectively, since they return a variant to support special error return values. HipHop isn't smart enough to know whether the error case will be triggered.
* Replaced most instances of double-equals with triple-equals. Profiling indicates that this makes a very large difference when comparing strings, much more so than in Zend.
Also removed htmlHeader() and htmlFooter() since it has zero callers anywhere.
Not sure why useOutputPage() was checking isArticleRelated(), we should be able do use it with other stuff too
* Common use case is Conf::get( 'myVar' );
* Support for default install (new `config` table) added, should be trivial to add backends for CDB, Memcache, etc...
*
to stop mostly irrelevent classes from getting it.
Also remove a method that is an exact duplicate of a base class (not sure whats with that).
This also coincidently fixes the issue with when a foreign file repo uses PagedTiffHandler
and the local one does not, and the builtin Tiff handler tries to treat the metadata as if
it was its own form.
* Refactor with all the latest bells and whistles
* Allow wikis to enable resettting by entering an email address (bug 13015). This is currently an unindexed query, but it is disabled by default so no immediate problem.
* Allow resetting to be disabled entirely (bug 20473).
* Don't send registered users' IP addresses in the emails (bug 18347)
* Check that a user is not globally blocked before letting them send messages (bug 23669)
* Display a more useful error message when an account exists globally but not locally (bug 18996).
Also make a few changes to the functions available. SpecialPageFactory::resolveAlias() now takes an optional subpage and returns array(<name>,<subpage>). Similarly merge getPage() and getPageByAlias(). There were many examples of (extensions particularly) making dubious assumptions about the presence or absence of subpages or canonical-ness.
I didn't deprecate SpecialPage::getTitleFor() as it's got over six hundred calls. I'm rather undecided on the best position of getPage()/executePath(). Although the latter needs cleanup anyway.
* Move them all to includes/profiling/* - If you're using StartProfiler, you'll need to update that
* Make ProfileStub subclass the Profiler rather than duplicating function definitions conditionally
* Removed unused params to wfGetProfilingOutput(), only used in the stub, and they didn't do anything with them
* TODO: Kill $wgProfiling, make $wgProfiler a config array and move the various options to that. Also make into a singleton, rather than global (not much calls it outside of core)
Hope I did this in an ok fashion. svn merge --re-integrate was giving me issues
so I just essentially over-wrote my working copy with the version at img_metadata.
Per CR at the time: this creates a nearly irreversable action that is not nearly well documented enough (even if disabled by default).
We already have the $wgBlockDisablesLogin kludge in place for this. If we're going to do more work on this idea, it should be well thought out, not another hack.
* Actions come in two flavours: the show-a-form-then-do-something-with-the-result (delete, protect, edit, etc) and the just-do-something (watch, rollback, patrol, etc). Create abstract base classes Action and FormlessAction to support these two cases. HTMLForm is an integral part of the form-based structure.
* Look mum, no globals! :D Fully context-based.
* Implement watch/unwatch, credits and delete actions in the new system as proof-of-concept. This also gives the delete frontend a much-needed overhaul.
* Stub out the newly-deprecated functions from Article.php. This already reduces its linecount by about 15%, and there are plenty more actions still to do.
* Centralising actions like this is going to render a lot of hooks type-incompatible. There's simply nowhere you can put the ArticleConfirmDelete hook, for instance, where it can be passed an OutputPage as the second parameter. On the other hand, we can implement new hooks like ActionModifyFormFields and ActionBeforeFormDisplay, which can do much prettier stuff to the forms, like adding extra fields the 'right' way. Update LiquidThreads to use these new hooks where appropriate.
