Since I5403f6e1d7f8f07273cd5da8068b928fdddcdfc9 on reblock the block
will be updated and not deleted/inserted and that update did not trigger
a delete of existing autoblocks.
Bug: 62748
Change-Id: I50384a41d819689944907e653e2495391253831b
One use found in core or Gerrit extensions which was replaced.
* Block::clear() (deprecated in 1.18)
* Block::decodeExpiry() (deprecated in 1.18)
* Block::encodeExpiry() (deprecated in 1.18)
* Block::forUpdate() (deprecated in 1.18)
* Block::infinity() (deprecated in 1.18)
* Block::load() (deprecated in 1.18)
* Block::newFromDB() (deprecated in 1.18)
* Block::normaliseRange() (deprecated in 1.18)
* Block::parseExpiryInput() (deprecated in 1.18)
Change-Id: Ia8ea6b5248111326f929062346f3868a0550421b
Change SpecialBlock so that when a block already exists, it just updates
the existing block rather than deleting and inserting a new row. Also,
Block::update() was changed to update existing autoblocks with the new
block parameters.
Bug: 48813
Change-Id: I5403f6e1d7f8f07273cd5da8068b928fdddcdfc9
The Line continuation Coding conventions prefers the closing parenthesis
on the same line than the beginning curly braces. This is done for ifs
and functions.
Also move some boolean operator from the end of a line to the beginning
and changed some indentation to make the condition hopefully better
readable.
Change-Id: Id0437b06bde86eb5a75bc59eefa19e7edb624426
Using the following command line, I have found doc comments mentioning
"1.21" when they should mention "1.22" instead, which I have fixed
manually:
git diff REL1_21 | grep --color=always -C 10 -iE \
'^\+.*(since|deprecated).*1\.21(\D|$)' | aha > oldver.html
I also moved the release notes for I1987190f ("Combine JavaScript and
JSON encoding logic") from RELEASE-NOTES-1.21 to RELEASE-NOTES-1.22
because I had reverted the commit on REL1_21 only (see Id3b88102 and
bug 47431 for the rationale).
Change-Id: I11b917a371e07267dfa98b8449776d0c1cb29b15
Follows-Up: I25cf5a94f6e47f85a9d0b80cc1c9c9f957288478
Follows-Up: I3d72e4105f6244b0695116940e62a2ddef66eb66
Follows-Up: I3faa9c3e8107c6e46cdf21f8c18adda1f42890d7
Follows-Up: I6aab19c8d68bf47beddad42632b0360a7b12f251
Follows-Up: I86368821fc2cd0729df5342b8572eb470c0f77a0
Follows-Up: Id3b88102e768318e3605a19e9952121091a40915
Follows-Up: Ie667088010e24eb6cb569f9e8e8e2553005223eb
This should allow the usernames of administrators such as "7"
to show correctly on permissions error pages.
I extracted the working code from UserBlockedError::__construct
into a separate method Block::getPermissionsError, called from
both places with context provided as an argument.
Additional changes to get the test suite to pass are included.
Bug: 46768
Change-Id: I49d973992a99e03b4e8de112b47b737037a85338
ERROR: Closing brace must be on a line by itself
Squiz.WhiteSpace.ScopeClosingBrace.ContentBefore
- For non-empty scopes it means the closing brace must be on a separate
line. This is already the case in most classes in some cases the "lazy
closing" is still used.
array(
'x' ); // Moved } to next line
function () { return 'x'; } // Moved } to next line
case 1:
stuff; break; // Moved break to next line
- For empty function it serves as a visual distinction between there not
being a scope block / function body and there being an empty function
body.
function foo(); // No body
function foo() {} // Empty body - violation
function bar() { // Empty body corrected
}
Change-Id: I0310ec379c6d41cc7d483671994d027a49f32164
Breaks unit testing (see bug 47031). The commit managed to land in
the branch because of a bug in Jenkins (bug 46723).
This reverts commit 8cc0b601aa
Change-Id: I4b3fadccaae9c35964a0c47d63b22c4f35148a24
This should allow the usernames of administrators such as "7"
to show correctly on permissions error pages.
I extracted the working code from UserBlockedError::__construct
into a separate method Block::getPermissionsError, called from
both places with context provided as an argument.
Bug: 46768
Change-Id: Ic3fa926a5a4c109faff35fffbccb60fb06ea4a18
Adds a new configuration variable ($wgApplyIpBlocksToXff), which when
enabled will scan the XFF header for IP addresses and check if any of
them have been blocked. $wgApplyIpBlocksToXff is disabled by default.
Bug: 23343
Change-Id: I3faa9c3e8107c6e46cdf21f8c18adda1f42890d7
Adds a new configuration variable ($wgApplyIpBlocksToXff), which when
enabled will scan the XFF header for IP addresses and check if any of
them have been blocked. $wgApplyIpBlocksToXff is disabled by default.
Bug: 23343
Change-Id: I3e38b94d10600a60d2d4857de54307f34c4662c4
* Ran spell-checker over code comments in /includes/
* A few spellchecking fixes for wfDebug() calls
Found one very strange (NOOP?) line in Linker.php - see "TODO: BUG?"
Change-Id: Ibb86b51073b980eda9ecce2cf0b8dd33f058adbf
Doxygen expects parameter types to come before the
parameter name in @param tags. Used a quick regex
to switch everything around where possible. This
only fixes cases where a primitve variable (or a
primitive followed by other types) is the variable
type. Other cases will need to be fixed manually.
Change-Id: Ic59fd20856eb0489d70f3469a56ebce0efb3db13
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
