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
Follows-up 39a6e3dc4d. Class-based feeds are always given their parameters
by RCFeed::factory. However because the old getEngine() method insists
on creating its own object, the constructor parameters were not given.
Add it as optional parameter and pass it through there.
This is backwards-compatible still because before the 39a6e3dc4d refactor,
an RCFeedEngine also was not given information about any formatter and it
was the callers responsibility to format the line before calling send().
CentralAuth still uses it this way and that works fine. The core-caller
that expected the construction parameters since 39a6e3dc4d is hereby fixed.
The test couldn't catch this because it constructed the class instance there,
since PHPUnit does not support a mock class that is instantiated by foreign
code, and the parameter is passed there.
Bug: T156996
Bug: T157106
Change-Id: I83433cf57b6e040cdb69f3ad8807a999c4f931a5
Previously:
* Engines had to be registered in $wgRCEngines.
* The RCFeedEngine classes took no constructor arguments and
were expected to send whatever text is previously formatted
without any information about it. This generic design was
flexible in allowing one to use any formatter with any engine
with minimal configuration and no need for additional classes.
* Each feed configured their destination by setting a 'uri'
option that encodes the name of the engine in PHP as the uri
scheme. Other uri components had to be used for any other
parameters to the engine (host, port, path). While fairly
limited, it was sufficient for the default engines in core.
Changes:
* Allow feed classes to be directly associated with a feed in $wgRCFeeds
via a new 'class' option - without the indirection of 'uri' and
$wgRCEngines. All options are passed to the given class constructor.
This matches the design used elsewhere in MediaWiki. (ObjectCache,
FileRepo, FileBackend, JobQueue, LBFactory, etc.)
This means we no longer enforce a 1:1 mapping of internet protocols
to a specific feed engine, and it allows settings to be passed
without being encoded as a URI neccecarily.
Main use case for this refactor is EventBus (see I7edc4d57fa),
Interestingly, this matches the (then incorrect) documentation
written for $wgRCFeeds in 2961884b43 (which mentions an 'engine'
property that would do the same thing).
* Move the default 'omit' filters and unrestricted 'formatter' handling
to a new FormattedRCFeed class, which remains the default.
* Deprecate RecentChange::getEngine() in favour of RCFeed::factory().
* Document wgRCEngines as "@since 1.22". Follows 2961884b43, ffc71cb6af.
Change-Id: I8be497c623c5d928762e3d3406a388f4d91add9a
Use of &$this doesn't work in PHP 7.1. For callbacks to methods like
array_map() it's completely unnecessary, while for hooks we still need
to pass a reference and so we need to copy $this into a local variable.
Bug: T153505
Change-Id: I8bbb26e248cd6f213fd0e7460d6d6935a3f9e468
Since T106119, moves that overwrite a redirect produce a deletion log
entry. It should be possibleto identify such deletions within other ones.
Note that this patch only applies for actions in the future because there
is no way to easily identify these cases for the software (until now).
Bug: T145991
Change-Id: I3c006bca57351d82031c4fdce0c53f65d630b0d9
This creates a hook triggered when updating change tags, so that
extensions can take actions when tags are updated.
When tagging accompanies the action, the recent change is passed
while when tagging is subsequent to the action, the user who
performs the tagging is passed.
Bug: T118698
Change-Id: Ifb0cdc43252c4185e4f216d23b8a21fb31595a37
Most planned callers of RecentChange::addTags() only want to add a
single tag, so forcing them to create an array seems unfriendly. Plus
this lets us avoid a array_merge call.
Change-Id: If001ba9ff01a33be158e7edd5c5e4de9825fa180
