Many of the Xml::… methods are deprecated. This code here is not
generating XML anyway, but HTML.
Bug: T341775
Change-Id: I69edf4606bc5cb429d48c8188c691b44575e2d93
Remove check for false from IDatabase::select as this is not possible
A DBQueryError is thrown (documented since efda8cd3 / I056b7148)
Change-Id: I465a9158aa6430e7ff8a5a83fe55c5944315aa40
UpdateQueryBuilder does not return a value,
removed the return value from the functions as well,
deprecated since 1.33
Change-Id: I3b934a5e6d5a53c07ec5233da00d9f53ba7bae92
Found usage of isset() on expression self::$diffParser that appears to
be always set. isset() should only be used to suppress errors. Check
whether the expression is null instead.
See https://www.mediawiki.org/wiki/Manual:Coding_conventions/PHP#isset
Change-Id: Iaaad420ad05b8352f8a7f162c746591749c8b3e9
This starts using conditional user defaults, which were
already deployed to WMF production config.
Bug: T353225
Change-Id: I93c6efc40d1ef6c46d8711fc5a4161e5d8f683e3
We are getting rid of the schema of implementing this interface and
calling self::READ_* constants, it's confusing, inconsistent, prone to
clashes and isn't really useful for non-ORM systems (which we are not)
Bug: T354194
Change-Id: Ic05e9fa663ddb97fcc8290f2629d3ad89b6791a5
This reverts commit f305c2d778.
Reason for revert: This is not the way of setting the default user
option, the 'default' param for HTMLForm should be filled with the
user's current option.
Similar mistakes happened many times, maybe we should deprecate setting
this param for any field types other than the 'info' type at the
preferences form level.
Bug: T350530
Change-Id: I1d0fce3db4a4228a6adcd9fe12dbc3da7ac0f710
This override is not actually overriding anything,
as we default to false for most email notifications,
including reverted. This just confused me for some time,
so removing the line to avoid that re-happening.
Bug: T353225
Change-Id: Iccd28d61c6fec860ceeb3527827089a65bf17ff8
Changes to the use statements done automatically via script
Addition of missing use statements done manually
Change-Id: Iad87245bf8082193be72f7e482f29e9f1bad11fc
User-options related classes are being moved to the MediaWiki\User\Options namespace in MediaWiki Core; reflect that change here.
Bug: T352284
Depends-On: I9822eb1553870b876d0b8a927e4e86c27d83bd52
Change-Id: Ic3e56c6e2ec606bbecbd630d8ad96d111cab24d3
User-options related classes are being moved to
the MediaWiki\User\Options namespace in MediaWiki Core;
reflect that change here.
Bug: T352284
Depends-On: I9822eb1553870b876d0b8a927e4e86c27d83bd52
Change-Id: Iddefd90b03a4751fce3f44e9fa0086082b21ae93
Fixes the rendering of an empty icon in Vector 2022
(empty string is a valid icon - blank icon)
Bug: T350195
Change-Id: I7b19d7e1e85eddd5a4bac29008cd53f14d640a08
empty() should only be used to suppress errors
When the type of the variable is array,
a falsy check is the same (checks for null, false and empty array)
Found by a new phan plugin (T234237)
Change-Id: Ia4e25651d753b7b4d3bcd780123c66c3d90cdf1b
Extensions should not a consumer of its own hooks,
just call the code before calling the hook.
In case of EchoGetBundleRules each extension should only handle it's
own event, so this is not a breaking change.
In case if EchoAbortEmailNotification the return false in the hook
handler already aborted further hooks, so this is not a breaking change.
Change-Id: I2715aa6499d01a1c1b3a27ff510b331eae0deca9
getCsrfToken() previously did the requests to every wiki with the same
'centralauthtoken'. Luckily this wasn't causing any bugs in practice,
because all users of ForeignWikiRequest that need CSRF tokens always
use it with a single wiki.
Change-Id: Ib1c0b9c13a34e38f85faed519c46cabd3b77e61e
Otherwise the parameters are copied from the local API request.
That mostly works fine, but browsing the errors logged for T342201
is a bit confusing when they're in different formats.
Change-Id: I5c361d6c0f7d635d3063290dec25f18bc6417e08
Completely remove the EchoMail and EchoInteraction instruments,
supporting code, and config variables. Note well that the
EchoEventLoggingSchemas config included an entry for the
already-decommissioned Echo instrument so remove that too.
Bug: T344167
Change-Id: Ic0c44737d2c4a78ec19e67b8b8cd4e6cfb8e14fa
In EventMapperTest, suppress notifications created by calling
getExistingTestPage. So far, this test only worked because the existing
test page is created in addCoreDBData (and not inside the test), but
this will no longer be the case after core change
I308617427309815062d54c14f3438cab31b08a73. Clear the PageSaveComplete
hook handlers to prevent that.
DiscussionParser has a static cache of revision data that can become
stale when data is deleted between tests (because revision IDs can be
reassigned to different pages, similar to T344124). This cache seems
needed, and converting the class to a service seems hard, so add the
page title to the cache key to try and avoid collisions. This can still
break if two tests are using the same page, which is hopefully quite
unlikely.
Change-Id: Ic4cbd8ff424e1260544ff9754e0c89dd4bb2f733
The use of "HookHandlers" attribute in extension.json makes it possible
to inject services into hook handler classes in a future patch.
Bug: T315938
Change-Id: I84027e2899b4a013b78fe4e95f191f1e4c89b5f8
Singletons are bad, amongst other reasons, because they're never reset
in tests. They can therefore occasionally cause test failures if the
cached data stored in one of these singletons becomes stale.
As noted on the task, ideally these two classes shouldn't exist at all,
and core should be responsible for caching the information it deems
expensive to compute.
As a temporary (TM) workaround, make both classes actual services, so
that the setUp/tearDown logic in MediaWikiIntegrationTestCase can
properly reset them between tests.
Dependencies are intentionally not being injected, precisely because
these classes should just be deleted, not improved.
Bug: T344124
Change-Id: I58b8d9610f9447468235b94d25732528ab6acce6
Always set the default value to HTML, and then potentially change it in
onUserGetDefaultOptions.
Bug: T341931
Change-Id: I19efaa2361cd936125b623f90d9a564caa51d4f1
Most notably, CatchableFatalErrorException and the code that throws it
are unused since Ic5712c4ce265b6faabce7a4028b4294fe3c73f18 (in 2016).
Bug: T328220
Change-Id: I5497347e41b21d2623b7e79bf7f977268a809c1d
Pass a relevant number of unread notifications to the messages
'echo-mark-all-as-read' and 'echo-mark-wiki-as-read' each time
they are used, in order to facilitate the use of PLURAL in
the messages. This allows translators to say e.g. "mark both as
read" when there are two unread notifications, for instance.
Bug: T321462
Change-Id: Ida65be2d7f2663d9802f71c7ea1eb588db8cd254
Creates a notification type to notify users when their
user page is edited.
Co-authored-by: Kunal Mehta <legoktm@debian.org>
Co-authored-by: Ed Sanders <esanders@wikimedia.org>
Bug: T3876
Change-Id: Ibe0092a96d96f6fa9d93991418b723f3e70e1b75
Error messages included a non-existent 'code' parameter; use the
curl error message instead. Also log the error status (which is
there somewhere in 'response' but logstash doesn't manipulate JSON
fields well).
Bug: T328128
Change-Id: If295d7a3b397b22301986a226a54df908c2ccf4d
In certain circumstances, it's possible for the user account to
have been deleted by the time the deferred update runs.
Bug: T318081
Change-Id: I3d1b5d1f034bf239e25d4af484b6329582b49bdc
It would be nice for editors to be able to see the particular edit
that was their 100th, 1000th, etc. This patch changes the link of the
edit count thanks notification to the diff of the edit, rather than the
page the edit was on.
Note that this link will only work for newly created notfications. Past
edit count notification database entries do not store what revision id
the edit was on in the 'echo_events' table, so there is no way to link
to them unless the table is updated.
Bug: T326998
Change-Id: If81fd71ce6f99ad3883a3bfbfbd798270f762d37
Instead of turning the array keys into an array of strings and
searching that we can access the original array by key.
Change-Id: Id4fddd242cff66ee70fa1cc07cdcb6938482696c
Switch the callers to the standard Maintenance::waitForReplication() method.
Avoid using LoadBalancer::waitFor(), which will made internal soon.
Bug: T326274
Change-Id: Idf0562eb33d90ff70eb3a7d5d7f54da944423d27
This changes the page linked notification to link to the diff of when
the page was changed and removes the "View changes" button.
Bug: T324849
Change-Id: I25a3de3ce5c02be3abbab1d2d2dd1aad8d287cbd
