| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Why:
- CategoryMembershipChangeJob is currently enqueued in
DerivedPageDataUpdater.
- This job is responsible for creating RC entries for category
membership changes that resulted from an edit, so it is semantically a
better fit for ChangeTrackingEventIngress instead.
- Idf6625d3e737e4a225648b0fd81cc929b095d315 unintentionally changed the
logic to enqueue this job for both direct content changes and
reconciliation requests, rather than only direct content changes.
Since the job creates RC entries, it should only be enqueued
as a result of direct content changes.
What:
- Move the logic of enqueueing CategoryMembershipChangeJobs into
ChangeTrackingEventIngress.
- Only enqueue CategoryMembershipChangeJobs for direct content changes
and update tests accordingly.
- Resolve the old TODO of making this logic MCR-aware by checking
whether any changed content slot supports categories as a precondition
of enqueueing the job, rather than only checking the main slot.
Bug: T390636
Change-Id: Icfe33ccc6cfa391e65ecae21d8c1d575dc247ee3
|
|
|
|
|
| |
Bug: T390735
Change-Id: I0ebec537bb15925e8507ee6934cd4a17973c536a
|
|
|
|
| |
Change-Id: I0d8d2237500ed6f18439410c902d47c42e4119bc
|
|\ |
|
| |
| |
| |
| |
| | |
Bug: T353458
Change-Id: I3e829e35c93bcaae75e401b1801bddf93c0b416c
|
|\| |
|
| |
| |
| |
| |
| | |
Bug: T353458
Change-Id: I3cf44dfe5425f2efb8409c83571c427447b053af
|
|\ \
| |/
|/|
| | |
entries in Recent Changes and Watchlist in non-grouping mode"
|
| |
| |
| |
| |
| |
| |
| | |
in Recent Changes and Watchlist in non-grouping mode
Bug: T148533
Change-Id: I33d3f186c1b59c2fa1a0ed7c588ed14e63a49559
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is the second step to refactor EmailNotification
notifyOnPageChange() method to use single RecentChange object
instead multiple arguments.
Previously we had to feed $editor, $title and some attributes.
Instead we can just pass the entire RecentChange and let
EmailNotification decide which properties to use.
In the future, this will allow EmailNotification to listen to
RecentChange domain events to trigger Notifications.
Bug: T388665
Change-Id: I5882531e91cd84c4683522f06d829149fdfc534e
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
To evolve Watchlist notifications and provide a unified approach
system has to pass the RecentChange object to EmailNotification.
Which later will pass to the RecentChange notification.
This is required to fulfill Echo needs that requires more information
from RecentChange. At current state, Echo requires properties like
`rc_logid` which is not available in MediaWiki ENotif job.
Furthermore this change will simplify the system, as
* instead of passing multiple params (and adding more of them with
time) we can just pass one RecentChange object that contains all
required information. When passing RecentChange via Job we can
use the `rc_id` to recreate the RecentChange when job gets processed.
* later Notifications system will be able to listen on RecentChange
domain event and trigger notifications via listener pattern which
will simplify the system even more.
Bug: T388665
Change-Id: I2d17bd3743e590e06298efaac387fc6d64e3609d
|
| |
| |
| |
| |
| | |
Bug: T353458
Change-Id: I95690a312e356c45dbeed607d32fb0e4626690cf
|
| |
| |
| |
| |
| | |
Bug: T353458
Change-Id: I2ae4577de79832b082adca282ff73cfabc8f9392
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Why:
- Now that we only support a single invocation mode, we don't need
suffixes on the name of the listener method anymore. This allows us to
start supporting listener interfaces.
What:
- Add PageStateListener and PageRevisionUpdatedListener
- Add PageMovedListener and PageDeletedListener
Bug: T387012
Change-Id: I0ce795136ea0f19689d8d8e9adcc0dde28e67b0f
|
|\ \ \
| |/ /
|/| | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Revert tag updates belong to change tracking, so move them out of the
content component.
Note: The behavior of updateRevertTagAfterPageUpdated() is covered by
the existing RevertedTagUpdateIntegrationTest.
Bug: T388573
Change-Id: I38cb5622238bc674ad97d6f47ecd4b8d09f45349
|
|/ /
| |
| |
| |
| | |
Bug: T353458
Change-Id: Ibe1810f1c71316a9124e1dc6ae405097dafd5267
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Why:
- "ingress" better describes the purpose of objects that use this base
class. "subscriber" is merely a mechanism for registering listeners.
What:
- Rename EventSubscriberBase to EventIngressBase (leaving an alias in
place)
- Improve documentation of the base class
- Clean up some unused code in the base class
Bug: T389033
Change-Id: Ib557aea12cc89b7365cabe22a6848c2a38c725ca
|
| | |
| | |
| | |
| | |
| | | |
Bug: T353458
Change-Id: I7a9c74f2106655d41ae029742090253f541bd4a6
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Why:
- Use consistent naming scheme based on "before" and "after" to
represent the change.
What:
- rename getOldRevision to getLatestRevisionBefore
- rename getNewRevision to getLatestRevisionAfter
Bug: T388588
Change-Id: I30078f606f457981987d95def5b2aaae181f0690
|
|/
|
|
|
|
|
|
|
|
|
|
| |
Why:
- clarify naming after modeling discussions
What:
- Rename PageEvent to PageStateEvent
- Rename PageUpdatedEvent to PageRevisionUpdatedEvent.
Bug: T388588
Change-Id: I987c93a443d364782e692e2cf71b878ccbc5a2fa
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Why:
- Listeners that want to skip processing if the page content didn't
change should generally not skip reconciliation requests.
PageUpdatedEvent should offer getters that make this straightforward.
What:
- Add isNominalContentChange that will return false for dummy revisions
but true for null edits. This is the preferred way for listeners to
determine whether they can skip redundant processing of page content.
- Rename isContentChange to isEffectiveContentChange, to distinguish
it from isNominalContentChange.
- Rename isRevisionChange to isRevisionHistoryChange, to make it clear
that the change affects the sequences of revisions.
- Add test cases to PageUpdaterTest asserting the expected update
propagation for null edits and dummy revisions.
- Change ingress objects so that:
- the message cache is updated for null edits
- module caches are not cleared for dummy revisions
Bug: T383552
Change-Id: Idf6625d3e737e4a225648b0fd81cc929b095d315
|
|\ |
|
| |
| |
| |
| |
| |
| | |
Use a protected class property similiar to LinkRenderer
Change-Id: I897710eb7e85708ad7b0dc1ed15a179cb764c5cd
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Why:
- Improve consistency, naming, documentation and definition of flags.
What:
- remove direct access to flags, provide a separate getter for each flag
instead.
- Deprecate EDIT_SUPPRESS_RC in favor of EDIT_SILENT
- Introduce EDIT_IMPLICIT to replace "automated" mode
- Introduce FLAG_RECONCILIATION_REQUEST into PageEvent.
- Introduce isReconciliationRequest into DomainEvent.
Bug: T383552
Change-Id: I2bffbb5810376829f871e1840ca799a8d8232dda
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Why:
- Rendering user links via UserLinkRenderer::userLink() and its
predecessor Linker::userLink() can be fairly expensive, so
RecentChanges has been caching them since
I91588aebae7e49e3d3cb77702cf28677b4a14c8d.
- We would like to start rendering a custom tooltip for user links
associated with temporary accounts, which requires returning a unique
ID for each tooltip so that it can be associated with the
corresponding link via an aria-describedby attribute for
accessibility.
- This won't work with the existing caching logic because it doesn't
treat links differently.
- Now that the UserLinkRenderer service exists, we can move the caching
logic there instead and allow every page, not just RecentChanges, to
automatically enjoy its benefits while transparently handling special
cases like expired temporary account links.
What:
- Implement process caching for user links in UserLinkRenderer.
- Replace Linker::userLink() with UserLinkRenderer in
RCCacheEntryFactory, and remove the now-redundant local process cache.
Bug: T358469
Change-Id: I0259e860c19f356ab66f45955f2997d307daa6e1
|
|
|
|
|
|
|
|
| |
Use modern php syntax to call a callable.
Reduce the stack trace to improve performance
and better IDE and static analyzer support
Change-Id: I9ef131032a662a3b8db69aa7079dbd51f88f575a
|
|
|
|
|
|
|
|
|
|
|
|
| |
This moves the following update logic out of
DerivedPageDataUpdater::doUpdates into listeners for the PageUpdated event:
- ResourceLoader: WikiModule::invalidateModuleCache to
ResourceLoaderEventIngress.
- TalkPageNotifications: TalkPageNotificationManager::setUserHasNewMessages
to UserNotificationEventIngress.
Bug: T378936
Change-Id: I5f2083b09d90cbd20abe2e8143a000dfc4d02aae
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This introduces the concept of a "cause" and "performer" into
PageUpdatedEvent. Causes are e.g. "edit" or "import" or "move".
The performer is the same as the author for edits, but not
necessarily for undeletions, moves, etc.
Note that cause and performer were already being tracked in
DerivedPageDataUpdater for logging purposes.
PageUpdatedEvent was modeling the cause using flags.
This change formalizes the concept of "cause" and "performer"
and ensures it is handled consistently.
As an aside, this simplifies some test cases in
DerivedPageDataUpdaterTest to avoid confused state.
Bug: T383031
Bug: T383095
Change-Id: I79bde5604790636c91848f265fffd81d6348a8b4
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Why:
- It's useful to be able to listen to sets of compatible event types.
What:
- Make DomainEvents aware of a list of types they are compatible with.
- Make EventDispatchEngine dispatch to all compatible listeners,
registered for any of the supported types.
- Move all page events to their own namespace
Bug: T384330
Change-Id: I96bde2cfaf198e409a6ef3a24101ee7d02d57959
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Same as Ia294bf4 did for 1-line comments. This patch removes slightly
more complex 2-line PHPDoc comments that don't add any new information
to the code, but literally repeat what the code already says.
They say "don't document the code, code the documentation", and we
are doing this more and more. We just tend to forget to remove the
obsolete comments.
Note I'm also removing a line of text in a few cases when it's very
short and literally says the same as the method name. Again, such
comments add zero new information.
Change-Id: I01535404bab458c6c47e48e5456403b7a64198ed
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I assume these are all either auto-generated by an IDE or the
language-level type declarations have been added later. In any case
the comments don't add any new information to what the code already
says. This is just extra clutter that makes the code harder to read,
I would argue.
There are many, many more comments like this. In this patch I
intentionally focus on the most trivial 1-line comments.
Change-Id: Ia294bf4ce0d8a77036842fe25884bc175c2b0e7d
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Why:
* A hook is needed by the CheckUser extension that allows it to
add a CSS class to any log line displayed in
Special:RecentChanges or other HTML RC feed, where the class
is added only if specific conditions about the log are met
(e.g. performer is a temporary account).
* No other hook exists which is both specific to log entries in
RC feeds and also allows modifying the CSS classes that
wrap the specific log entry (as opposed to a group of log
entries).
* Therefore, a new hook is needed that allows this modification.
What:
* Call the new ChangesListInsertLogEntry hook in ChangesList
::insertLogEntry which is used to generate the
HTML for a log entry in an RC feed.
* Add the ChangesListInsertLogEntryHook interface, and implement
it in HookRunner.php
* Add tests for ChangesListTest to cover the code that was
previously untested and also modified in this commit. This also
checks that the hook works as expected.
Bug: T370083
Change-Id: I7d907823d9f15d518c55494f28950441a98f6f86
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Suppress remaining issues
Depends-On: I633ec05fe9ab6a815225911d942ecb79f21c428f
Depends-On: I186e799256fbaf5ee77558bd146f9418dd5eaacc
Depends-On: Ib84b7d71e8308a36409f30ecfd16e9de149e97b3
Depends-On: I26aa4adf31b4142248abe3e0f9aa8314512602a6
Depends-On: Icf24e208a487bafe3d1983536870aac19cfc4b5e
Depends-On: I99915b893f14cfbb2b54d9a6264b4f294200c4f2
Depends-On: Ia53b71dff3299837856ae3c004cd0227bd45e05b
Change-Id: I825dce05d4a6ca87acf25063e3664cb2d16f5db0
|
|\ \ |
|
| |/
| |
| |
| |
| |
| |
| |
| |
| | |
isset() should only be used to suppress errors, not for null check.
When the property is always defined, there is no need to use isset.
Found by a new phan plugin (2efea9f989)
https://www.mediawiki.org/wiki/Manual:Coding_conventions/PHP#isset
Change-Id: Ib84b7d71e8308a36409f30ecfd16e9de149e97b3
|
|/
|
|
|
|
|
|
|
| |
isset() should only be used to suppress errors, not for null check.
When the property is always defined, there is no need to use isset.
Found by a new phan plugin (2efea9f989)
https://www.mediawiki.org/wiki/Manual:Coding_conventions/PHP#isset
Change-Id: Ia53b71dff3299837856ae3c004cd0227bd45e05b
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In Ice76519 we lost the mechanism for triggering updates for the search
index and message cache on import and undeletion. This change restores
the trigger for these updates.
To achieve this, the logic for instantiating PageUpdatedEvents is moved
into DerivedPageDataUpdater. Perhaps the firing of the event can be
moved into that class eventually.
To improve consistency, the flags field in PageUpdatedEvent is changed
from a bitmap corresponding to the flags field in PageUpdater to an
array corresponding to the options array in DerivedPageDataUpdater.
For regression testing, this change defines new test traits, one for
each ingress. These traits define the expected behavior of each ingress
in each relevant situation (edit, move, import, and undeletion).
Bug: T381225
Bug: T381299
Change-Id: Ib0d1dd143160fb64d42cacfbc75fbb55f5614c1c
|
|
|
|
| |
Change-Id: I32ee63b83a7b895bef46fab728abc16172410299
|
|
|
|
|
|
|
|
| |
Follows-up Ic3e0aebdb6 (34dc4e6d26), which factored code out from
getLine() to a new getNotifyUrl() and included an unused global
wgLocalInterwikis.
Change-Id: I2d2665c0ba53a528e4f38514b0654e9e15afb0f4
|
|
|
|
| |
Change-Id: Ia7b046a355197307846e8f377c031b909d46d66d
|
|
|
|
|
|
|
|
| |
Use subscriber objects in extension.json instead of registering
listeners directly.
Bug: T378931
Change-Id: I38ef080c17842790c609c022b31acfa0ebd3c103
|
|
|
|
|
|
|
|
|
|
| |
Subscriber objects define multiple related listener methods and can
register with them with a DomainEventSource. The concept of
subscriber objects can be found in frameworks like Laravel
and Symfony.
Bug: T379774
Change-Id: I1ab097687bef1749e9bd8d7c48dacbb553540fdd
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Why:
- The `revision` and `forImport` constructor parameters of
CategoryMembershipChange are marked as optional, but the only non-test
usage of this constructor provides them both.[1]
What:
- Make both parameters required and remove tests related to
instantiating a CategoryMembershipChange without a RevisionRecord.
[1] https://codesearch.wmcloud.org/search/?q=CategoryMembershipChange%5C%28&files=&excludeFiles=&repos=
Bug: T373318
Change-Id: Ic240edea0bb9a27cdfa2d810284644c1eef51895
|
|\ \ |
|