This is the default for many years now. Returning true is not different
from returning nothing.
I'm not touching functions that can either return true or false.
Change-Id: I6c70b8ef44f17271201a69a85301a631b32763c0
With I91a9c5cca55e540a6c95b750579c1c369a760b15 we replaced some globals
with Config and, in doing this, we added "$config->has()" to check if a
variable was null. However, "has" will always return true even if the
value is null (it only checks if it exists), and thus we end up showing
a global abusefilter pager even if no central DB is set.
Bug: T195022
Change-Id: I751fdefd29b6af1361021d4343ba67f16c99a037
AbuseFilter's SQLite schema is currently broken.
On SQLite version 3.8.2 it produces multiple errors, such as:
- Error: near line 3: near "binary": syntax error
- Error: near line 30: AUTOINCREMENT is only allowed on an INTEGER PRIMARY KEY
This change fixes the SQLite schema.
Change-Id: Iba80ee0e2de204b1cdb63490e34ae42f3d8de94c
Use TextContent::normalizeLineEndings instead of manually replacing
carriage returns, plus avoid the if with a simple string cast. This also
fixes some cases where a null edit isn't counted as such due to a "\n"
in new_wikitext which isn't trimmed.
Bug: T168736
Change-Id: Idfafab3fcf7912bf0aec22700d2c0137bdd6c3c8
With the introduction of custom block durations in Ib072433d19dabae48d8514e08be9893135b5d63c, the method which generates action display was enlarged in order to provide a more readable and complete message. However, for throttling we currently have an unreadable message like "Throttle: xx, yy, zzz". This is wrong for two reasons: first, those numbers need to be deciphered; second, the first number is the filter ID which is totally unuseful here.
Change-Id: I0ec6a27ff5f37aae864dfd91161bf44f0a217ef1
They were defaulted to false with
I93ad51ffe7bee597d2d127f4c5d6b2929ffc8f7e, which broke use cases where
the page field is NOT required, nor has a 'required' => false explicitly
declared.
Bug: T194425
Change-Id: I5ab768c02a30b6d053104e590729ef22bb4e0808
Pretty self-explanatory and straightforward, since recentchanges has a
dedicated column for bot edits.
Bug: T193994
Change-Id: I76d41e082aed262640e9fff856eeb97df49633d5
With If16975dd394cfdb3c57ff263366c2fc865de362a I broke flags checkboxes,
i.e. the one for enabling/deleting/etc. a filter. In fact, I
misunderstood the way cbReadOnlyAttribute was used (a dirty way,
actually) and this caused such checkboxes not to be disabled if the user
didn't have rights to edit the filter.
Change-Id: Ibf80b54e0f620734ad7767e4769a93bbf1feccff
Like we do for built-in values. If a blacklisted variable is overridden,
it still works, but there's no reason to allow it.
Bug: T191715
Change-Id: Ia4d42ec56dc4805454b96c52c2eace1924f6536c
