Added/removed spaces around logical/arithmetic operator
Reduced multiple empty lines to one empty line
Removed wrong tabs before comments at end of line
Removed too many spaces in assigments
Change-Id: I2bba4e72f9b5f88c53324d7b70e6042f1aad8f6b
Sometimes sysops put template calls in block messages and they will be
expanded in the <blockedtext> interface. However in corresponding
autoblocks, template calls get expanded to long strings and truncated.
Change-Id: I3150192ec8c95d2e4807f058a855856e467145de
Since SVN r106354 (85ee2d2d), when passing null or an invalid block target
to Block::newFromTarget(), it was never returning any block, even if the
vague target would have matched one.
This broke two features of core MediaWiki:
- Excluding user and user talk pages of blocked users from being indexed,
the feature that actually caused bug 33101 and the revision mentionned above
- Blocking of account creation when both the user and its IP address are blocked,
but of only the IP address blocks prevents account creation (bug 13611)
And maybe some others in extensions, I didn't check that.
This changes reverts part of r106354 to make Block::newFromTarget() work again
in that case and changed Article::getRobotPolicy() to pass the user to be checked
as vague target only when it's an IP address and as specific target otherwise.
Change-Id: Ie7e16e0bae8c4326d16cca237877693f7b474a01
Previously, whenever we blocked a user, its IP address would be
autoblocked whenever he tries to edit a page. Thus when later unblocking
the username, he would be automatically blocked again if we forgot to
clean up is IP.
This patch introduces a the ipb_parent_block_id column in ipblocks table
to track which block triggered the autoblock command. Thus, when deleting
the original block we can easily remove all subsequentautoblocks.
Schema updaters for MySQL, SQLite and postgres have been added to the
patch but not for the other database types such as ibm_db2, mssql and
Oracle.
Change-Id: I4aa820ae9bbd962a12d0b48b6c638a1b6ff4efc9
* Block::parseTarget() first called trim() on its parameter which was converting objects into string, thus making the checks for object and null useless; now trim() is called after these checks.
* User::getBlockedStatus() was passing $this->getName() to Block::newFromTargert() which in turn was passed to Block::parseTarget() where a new User object was created.
Instead of this, the User object is directly passed to Block::newFromTargert(), which avoids creating a new object for the same user.
Change-Id: Iffea21d4f53e8692072749264f7486c22b6be5fd
Change 1:
* Delete any pre-existing block for the tests
* Renamed test function and fixed comment typo
Change-Id: I4804ccae81dd0455e9d3ddf48960c4b5cd6e4f5f
* Added $wgAutoblockHandlers variable for alternative autoblock handling functions
* Gave CheckUser a potential $wgAutoblockHandlers function (bug 29330)
This bug was showing up in test results like this:
BlockTest::testInitializerFunctionsReturnCorrectBlock
Trying to get property of non-object
/home/ci/cruisecontrol-bin-2.8.3/projects/mw/source/includes/Block.php:340
/home/ci/cruisecontrol-bin-2.8.3/projects/mw/source/includes/Block.php:365
/home/ci/cruisecontrol-bin-2.8.3/projects/mw/source/includes/Block.php:118
/home/ci/cruisecontrol-bin-2.8.3/projects/mw/source/tests/phpunit/includes/BlockTest.php:60
/home/ci/cruisecontrol-bin-2.8.3/projects/mw/source/tests/phpunit/MediaWikiTestCase.php:60
/home/ci/cruisecontrol-bin-2.8.3/projects/mw/source/tests/phpunit/MediaWikiPHPUnitCommand.php:20
/home/ci/cruisecontrol-bin-2.8.3/projects/mw/source/tests/phpunit/phpunit.php:60
However, that only triggers because the actual test is failing -- it's expecting to get a return back. This can only be reproduce when using the suite.xml configuration file, and not when running the BlockTest standalone.
