This is obviously incomplete, but it should allow unit-testing in some
situations. Both these classes are ancient and should be refactored, so
there's probably no point in pushing this further for now.
Change-Id: Ie5563490cdc84cfa50b5248c248f0fd282de6075
A new user right, `delete-redirect`, is added (not given to anyone
by default). At Special:MovePage, if attempting to move to a single
revision redirect that would otherwise be an invalid target (i.e.
doesn't point to the source page), the user is able to delete the
target.
Deletions are logged as `delete/delete_redir2`, and the move is
then logged normally as `move/move`, mirroring current delete and
move logging.
To allow for separate handling by Special:MovePage,
MovePage::isValidMove now returns a fatal status `redirectexists` if
the target isn't valid but passes Title::isSingleRevRedirect.
Otherwise, `articleexists` is returned (as previously). Other callers
that don't intend to treat single revision redirects differently
should treat `redirectexists` the same as `articleexists`.
Currently, this deletion (like normal delete and move) cannot be
done through the move api. Since the deletion is only valid when
moving a page, unlike for normal deletion, deleting redirects with
this right cannot be done via the delete api either.
Bug: T239277
Change-Id: I36c8df0a12d326ae07018046541bd00103936144
The tag is added to reverted edits as described in T254074.
Functionality:
* Adding the mw-reverted tag to reverted edits (duh)
* Limiting the maximum depth of the update through a config variable
(mitigation #2 from T259014).
* Only applying the reverted tag after the edit has been somehow
approved. Only the patrol subsystem currently implements this, but
there's a hook that extensions can use (mitigation #4 from T259014, more
explanation in T259103).
* When performing the delayed update, it is checked whether the reverted
edit was reverted itself. If so, the update is ignored. This is
probably the only way to make the feature work due to the lack of an
explicit "disapproval" mechanism other than reverting.
* The update is also ignored if the revert is marked as deleted.
Technical design:
* The update code is in RevertedTagUpdate.php, which is a deferrable
update, but is not used as such. It's separated to allow for better DI,
testing and better code reusability in the future.
* The update is queued / ran using the Job subsystem. The relevant job
is in RevertedTagUpdateJob.php
* PageUpdater determines whether the edit is approved or not and passes
that to the DerivedPageDataUpdater.
* The BeforeRevertedTagUpdate hook lets extensions decide whether the
update should be ran right away or await approval.
* DerivedPageDataUpdater checks whether the edit is a revert and if so
either enqueues the job (if it's auto-approved) or caches the EditResult
for later use (if it needs approval).
* RevertedTagUpdateManager allows for easy re-enqueueing of the update
for extensions. Thus, it has a very minimal interface.
Other notes:
* The unit testing setup for RevertedTagUpdate is a bit complicated,
but it was the only way I could make this class testable while using
the static ChangeTags class.
Bug: T254074
Depends-On: I86d0e660f0acd51a7351396c5c82a400d3963b94
Change-Id: I70d5b29fec6b6058613f7ac2fb49f9fad9dc8da4
This aims to persist the EditResult object associated with reverts
in the ct_params field of change_tag table for revert tags. This can
be later used for analytics or when performing a delayed
RevertedTagUpdateJob (see T259103).
The code doing that has to be in the RecentChange class, as only it
knows the relevant rc_id and rev_id.
Bug: T259733
Change-Id: I365cf44484aa5bf907128a075fcff890649504c4
If a changeslist item has an expiry date, add a grey clock icon
after the page title, with a tooltip indicating when the item
expires.
Bug: T250212
Change-Id: I38f8c85321cf257eeea8de5a3bd73bbc0b5ea393
Migrate all callers of Hooks::run() to use the new
HookContainer/HookRunner system.
General principles:
* Use DI if it is already used. We're not changing the way state is
managed in this patch.
* HookContainer is always injected, not HookRunner. HookContainer
is a service, it's a more generic interface, it is the only
thing that provides isRegistered() which is needed in some cases,
and a HookRunner can be efficiently constructed from it
(confirmed by benchmark). Because HookContainer is needed
for object construction, it is also needed by all factories.
* "Ask your friendly local base class". Big hierarchies like
SpecialPage and ApiBase have getHookContainer() and getHookRunner()
methods in the base class, and classes that extend that base class
are not expected to know or care where the base class gets its
HookContainer from.
* ProtectedHookAccessorTrait provides protected getHookContainer() and
getHookRunner() methods, getting them from the global service
container. The point of this is to ease migration to DI by ensuring
that call sites ask their local friendly base class rather than
getting a HookRunner from the service container directly.
* Private $this->hookRunner. In some smaller classes where accessor
methods did not seem warranted, there is a private HookRunner property
which is accessed directly. Very rarely (two cases), there is a
protected property, for consistency with code that conventionally
assumes protected=private, but in cases where the class might actually
be overridden, a protected accessor is preferred over a protected
property.
* The last resort: Hooks::runner(). Mostly for static, file-scope and
global code. In a few cases it was used for objects with broken
construction schemes, out of horror or laziness.
Constructors with new required arguments:
* AuthManager
* BadFileLookup
* BlockManager
* ClassicInterwikiLookup
* ContentHandlerFactory
* ContentSecurityPolicy
* DefaultOptionsManager
* DerivedPageDataUpdater
* FullSearchResultWidget
* HtmlCacheUpdater
* LanguageFactory
* LanguageNameUtils
* LinkRenderer
* LinkRendererFactory
* LocalisationCache
* MagicWordFactory
* MessageCache
* NamespaceInfo
* PageEditStash
* PageHandlerFactory
* PageUpdater
* ParserFactory
* PermissionManager
* RevisionStore
* RevisionStoreFactory
* SearchEngineConfig
* SearchEngineFactory
* SearchFormWidget
* SearchNearMatcher
* SessionBackend
* SpecialPageFactory
* UserNameUtils
* UserOptionsManager
* WatchedItemQueryService
* WatchedItemStore
Constructors with new optional arguments:
* DefaultPreferencesFactory
* Language
* LinkHolderArray
* MovePage
* Parser
* ParserCache
* PasswordReset
* Router
setHookContainer() now required after construction:
* AuthenticationProvider
* ResourceLoaderModule
* SearchEngine
Change-Id: Id442b0dbe43aba84bd5cf801d86dedc768b082c7
This is a collection of random bits from my local stashes. This patch
intentionally only touches comments, no code.
Notably:
* Use more specific string[] instead of array, if possible.
* Some comments mention "or null", but miss to list the type.
Change-Id: I712b28964f125c8e3dcb4e3fb993757a09f96644
It uses $wgUser, but rather than adding a user parameter, the whole
method can just be deprecated and removed. All existing calls have
already been updated.
Bug: T245195
Change-Id: Id7d67cd69d87283cb88455593a4a183c4a5c7721
These were all checked with codesearch to ensure nothing is overriding
these methods.
For the most part, I've updated the signature to use nullable types; for
two Pager's, I've just made all parameters non-optional, because you're
already forced to pass them with a required parameter at the end.
Bug: T231636
Change-Id: Ie047891f55fcd322039194cfa9a8549e4f1f6f14
This removes most of the pre-actor user and user_text columns, and the
$wgActorTableSchemaMigrationStage setting that used to determine
whether the columns were used.
rev_user and rev_user_text remain in the code, as on Wikimedia wikis the
revision table is too large to alter at this time. A future change will
combine that with the removal of rev_comment, rev_content_model, and
rev_content_format (and the addition of rev_comment_id and rev_actor).
ActorMigration's constructor continues to take a $stage parameter, and
continues to have the logic for handling it, for the benefit of
extensions that might need their own migration process. Code using
ActorMigration for accessing the core fields should be updated to use
the new actor fields directly. That will be done for in a followup.
Bug: T188327
Change-Id: Id35544b879af1cd708f3efd303fce8d9a1b9eb02
This will allow the OAuth extension to subscribe to this hook and add an
“OAuth CID: $consumerId” tag to patrols made via OAuth.
Bug: T219655
Change-Id: Ie5e6f820bbf399ec639e715afd908f78bf5c8e9a
The Taggable interface defines how to tag objects in MediaWiki.
For now there are only two Taggable objects:
- RecentChange
- ManualLogEntries
This interface should be used in places where we want to optionally
tag things, for example:
We want to tag all mobile web actions with 'web mobile edit'.
With that interface, we will be able to expect a Taggable object,
and call `addTags()` when we need to, without having a special check
to verify is it RecentChange, or is it ManualLogEntry. We will only
expect a Taggable object.
Additionally, added @deprecated note to ManualLogEntries::setTags()
as each call to this method will override all previous tags. This
action can be harmfull to parts of code that conditionally add tags.
If object was tagged in some way, we should preserve those tags.
If there are any special cases, where we want to override all tags,
we should provide `resetTags()` method.
Bug: T215675
Change-Id: Ia4c019db8ca6f37ce0f86bf7d134d6f1713daf56
When this was originally written, the plan was to read both the old and
new fields during the transition period, while stopping writes to them
midway through. It turns out that the WHERE conditions to do read-both
correctly are generally not handled well by the database and working
around that would require a lot of complicated code (see what's being
removed from ApiQueryUserContribs here, for example).
We can simplify things greatly by instead having it write both fields
during the transition period, reading from the old for the first part
and the new for the second part, as is being done for MCR.
Bug: T204669
Change-Id: I4764c1c7883dc1003cb12729455c8107319f70b1
Depends-On: I845f6ae462f2539ebd35cbb5f2ca8b5714e2c1fb
Depends-On: I88b31b977543fdbdf69f8c1158e77e448df94e11
This introduces PageUpdater to replace WikiPage::doEditContent,
and DerivedPageDataUpdater, to replace WikiPage::doEditUpdates
and WikiPage::prepareContentForEdit.
See docs/pageupdater.txt for a description of their
functionality.
MCR migration notes:
* The interface of PageUpdater is expected to
remain mostly stable after this patch. Code that has been using
WikiPage::doEditContent can be confidently migrated to using the
new mechanism for revision creation.
* This patch keeps the code inside PageUpdater largely aligned
with the old code in WikiPage, to make review easier to to avoid
mistakes. It is intended to be refactored further, moving
application logic into stateless services.
* DerivedPageDataUpdate is intended as a stepping stone for further
refactoring. Its behavior is designed to be compatible with
callback code that currently relies on
WikiPage::prepareContentForEdit. Much of the code that currently
lives in DerivedPageDataUpdate should be factored out into
services, all behavior relevant to calling code should be exposed
via narrow interfaces.
Bug: T174038
Bug: T196653
Change-Id: If610c68f4912e89af616cdcac1d35a1be3946afa
Find: /isset\(\s*([^()]+?)\s*\)\s*\?\s*\1\s*:\s*/
Replace with: '\1 ?? '
(Everywhere except includes/PHPVersionCheck.php)
(Then, manually fix some line length and indentation issues)
Then manually reviewed the replacements for cases where confusing
operator precedence would result in incorrect results
(fixing those in I478db046a1cc162c6767003ce45c9b56270f3372).
Change-Id: I33b421c8cb11cdd4ce896488c9ff5313f03a38cf
It is a boolean parameter that is confusing for three reasons:
* It's a boolean parameter, given parameters are unnamed in PHP,
these are always poor UX for call sites.
* It's negated ("noudp"). save(true) means no feeds events,
save(false) [default] means sending events to feeds.
* To overcome this problem, typical use was to pass a free-form
string that self-documents the intended behaviour,
e.g. `save('pleasenoudp')`, any string casts to true.
Fix this by moving the booleans to constants and use those
instead. For compatiblity, keep the negation internally,
although it's hidden from regular usage. Also document
the string hack, deprecate it, and update callers.
Change-Id: Ia57c86b38bf50cb4ec580f42a6b1ca798fcf781a
These actions mark edits as patrolled automatically, so the
correct rc_patrolled value to use is PRC_AUTOPATROLLED rather than
PRC_PATROLLED. The code for log entries checks the autopatrol right, and
the code for category entries has a comment that says "just like log
entries".
Bug: T190408
Bug: T184791
Change-Id: Id994af8cd3833a862a09389431256aba35c2e6d9
Per the RFC, it will now become the default and only behaviour
to not log autpatrol actions. The information is already
recorded via the rc_patrolled field.
Bug: T184485
Change-Id: I98ae895a2b4cde4bb945f1df23be4a070b0bf9c4
Storing the user name or IP in every row in large tables like revision
and logging takes up space and makes operations on these tables slower.
This patch begins the process of moving those into one "actor" table
which other tables can reference with a single integer field.
A subsequent patch will remove the old columns.
Bug: T167246
Depends-On: I9293fd6e0f958d87e52965de925046f1bb8f8a50
Change-Id: I8d825eb02c69cc66d90bd41325133fd3f99f0226
This allows CommentStore to be added to MediaWikiServices
without the need of an aditional Factory.
This change includes a compatability layer to allow the behaviour
from 1.30 to continue to be used while deprecated.
CommentStore::newKey has been deprecated.
Keys are now passed into the public methods of CommentStore
where needed.
The following CommentStore methods have had their signatures changed
to introduced a $key parameter, but when used in conjunction with
CommentStore::newKey behaviour will remain unchanged:
* CommentStore::getFields
* CommentStore::getJoin
* CommentStore::getComment
* CommentStore::getCommentLegacy
* CommentStore::insert
* CommentStore::insertWithTemplate
Change-Id: I3abb62a5cfb0dcd456da9f4eb35583476ae41cfb
Several classes have a "selectFields()" static method to tell callers
which fields to select from the database. With the recent comment table
change and the upcoming actor table change, this pattern has become too
simplistic as a SELECT will need to join several tables to be able to
retrieve all the needed fields.
Thus, we deprecate the selectFields() methods in favor of getQueryInfo()
methods that return tables and join conditions in addition to the
fields.
Change-Id: Idcfd15568489d9f03a7ba4460e96610d33bc4089
CategoryMembershipChange is great, but it doesn't have a
machine-readable way to see if the category has been added or removed
from the page. We could parse the comments, but that would rely on
reading the comments and matching the message against the translated
strings.
This patch adds a couple of parameters and notes whether the change
was an addition or removal in rc_params.
Also, puts the evaluation of the AbortEmailNotification hook before
the check of rc_type in the hopes that the extension CatWatch can send
out emails at the right time.
Bug: T175052
Change-Id: I3e2ac0cc148b9d618e2f8b7853b14bff827ee443
Since the caller doesn't (and shouldn't) know whether CommentStore is
using the old or the new schema, it should leave truncation of comments
to CommentStore.
Change-Id: I92954c922514271d774518d6a6c28a01f33c88c2
And auto-fix all errors.
The `<exclude-pattern>` stanzas are now included in the default ruleset
and don't need to be repeated.
Change-Id: I928af549dc88ac2c6cb82058f64c7c7f3111598a
