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
- Remove set of $wgDiff, not used in core and seems not needed
- Avoid array_keys on foreach
- Save settings directly by UserOptionsManager for the fresh user
- Combine calls to overrideConfigValue into one
- Referer core config via MainConfigNames
- Remove unneeded reset after overrideConfigValues, get reset there
- Reset specific service and not all
Change-Id: Ia00efae85e17dfac1768b12b35f44eb834f879ec
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
This code has been moved to Minerva and is no longer serving any
purpose. The handlers are replaced with an already standardized
mw.hook for Minerva to subscribe and respond to.
Bug: T342907
Depends-On: I55c18cf723a32f80b93a01dd0687e005162c4e93
Change-Id: I2f923e509d24524a2375ffbe6b3ef336487574bb
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