Follows similar commits to the objectcache, rdbms, filerepo,
jobqueue components and other areas [1].
* Remove duplicate descriptions from file blocks in favour of class
doc blocks. This reduces needless duplication and was often
incorrect or outdated, and helps (ironically) to make the file header
more consistently visually ignorable.
* Remove `ingroup` from file blocks in class files as otherwise
the file is indexed twice (e.g. in Doxygen) which makes navigation
more messy.
* Fix non-standard `@unstable for implementation` annotations
in favour of `@stable to type` as per T257789 and
<https://www.mediawiki.org/wiki/Stable_interface_policy>.
While at it, fix the only other outstanding uses of `@stable for`
in core as well in a handful of context/, logging/ and search/
files.
[1] https://gerrit.wikimedia.org/r/q/message:ingroup+owner:Krinkle
Bug: T257789
Change-Id: Ided3c5ab69e1b587b1b76a3c97a7cdb88f21e130
Per the Stable Interface Policy, PHP interfaces should not be
directly implemented by extensions, unless they are marked to be safe
for that purpose.
Bug: T247862
Change-Id: Idd5783b70fc00c03d57f5b1a887f0e47c4d7b146
PhanTypeInvalidRightOperand was triggering on
ApiQueryBase::showHiddenUsersAddBlockInfo() on the line
`$actorQuery['tables'] + $commentQuery['tables']` (and the next one).
For whatever reason, phan was unable to automatically understand that
the right side was an array (though it was able to understand
$actorQuery, which has nearly identical code...), so I added more
specific hinting to CommentStore::getJoin() using phan's union types,
which resolved the issue.
And incorrect documentation on LogEntry::getDeleted() was triggering
PhanTypeMismatchBitwiseBinaryOperands since you can't do bitwise
operations on a string and an integer.
Change-Id: I13b791e4b754ffbc340b55cfb752e2d9226f1949
Looks like some parts of the code try to publish log event when
$newId is 0 or null. This cause ChangeTags::addTags to throw
an exception as at least one of rc_id, rev_id, or log_id must be
specified.
When ChangeTags::addTags() fails (because both $rev_id and $log_id
are not present), just ignore the exception and continue with
the execution.
Also, if one of those is set to 0, we need to pass null instead
(do not insert 0's in to DB as both log_id and rev_id are foreign
keys).
Additionally log all places where ManualLogEntry::publish() is
called with incorrect arguments so later we can fix all occurencie
and remove that try{}catch around ChangeTags::addTags() call.
Bug: T218940
Change-Id: I495f79f2b7a7ef1503d229a689babdc12deb353c
This hook is required by extensions like MobileFrontend to tag
log entries when actions are performed on the mobile web.
There is a possibility to tag log entries by using
'RecentChange_save' hook, but that works only when the log entry
is published to 'rc' or 'rcandudp'. This means, that tagged log
will appear also on the Special:RecentChanges page which is something
what extensions like 'Thanks' wants to avoid.
In the future we should avoid using 'RecentChange_save' as an
indirect way to tag log entries, and use the
'ManualLogEntryBeforePublish' hook instead.
To cover ourselves in the future, instead of passing &$tags only,
we pass the $this (the log entry object) so extensions can perform
additional checks before using setTags().
Bug: T215675
Change-Id: I747eded4bc5406cd5d4676fc93b0bb55c99f9a4d
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
The documentation already claimed it returned array,
this is now actually true. Follows-up 037c06e886.
There are two ways it could be null:
* The setTags() method was never called, and the class member
was implicitly null by default.
* The setTags() method was called with $tags = null.
This happens WikiPage::doUpdateRestrictions() among other places.
That could probably be fixed, but is out of scope for this change.
The getTags() method of this clss appears to have no outside
callers in MediaWiki core, nor in any other project indexed
by Codesearch.
Change-Id: Ib89c79ef90870506187c3c3b61464c2aa788c594
This is a first, very small migration step. This is entirely
non-breaking, as all objects passed to these two functions already
matched the interfaces that are now required.
For the setTarget() method it's most obvious it really just needs a
LinkTarget value object, but not the entirety of the Title class
with all it's helper methods. Same for the performer. A ManualLogEntry
does not need to interact with the performer, just needs to know him.
This small change allows to slowly migrate away from code depending on
the User and Title classes.
Note this code currently does not have any test coverage, and I do not
plan to change this within this patch. I just don't have the time.
https://doc.wikimedia.org/cover/mediawiki-core/includes/logging/LogEntry.php.html
Change-Id: Id551f066ab02d5ca14346a39a55af4e7b6e4e042
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
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
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
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
Having such comments is worse than not having them. They add zero
information. But you must read the text to understand there is
nothing you don't already know from the class and the method name.
Change-Id: I994d11e05f202b880390723e148d79c72cca29f0
The return value from the method is only suitable for passing to
$db->insert(). To get the inserted ID, you need to call $db->insertId()
even if $db->nextSequenceValue() returned non-null.
Bug: T164900
Change-Id: I6beb6243ccb9425372623307ef23ae6571ce8c0d
Currently, extensions that add tags within the recentchanges_save
hook directly call ChangeTags::addTags. This often results in
consecutive writes to the changetags table.
This provides a addTags method to RecentChange so extensions
can simply use it when they want a tag added. And all the actual
tagging is done once at the end.
Change-Id: I8df2fd983c12632337e8d2922fa357808482338c
This defers the publish function of ManualLogEntry, which includes
saving the recent change to the db, notification of feeds, auto-patrol
and addition of change tags. This way, end users no longer have to wait
for those actions to conclude for the request to complete.
Bug: T127852
Change-Id: Ida86b7a7383d12695be28338c69b93e8e86d82c9
This adds new methods to ManualLogEntry that allow to specify that
a log entry is patrollable. RecentChange::newLogEntry then checks
this in order to allow or not unpatrolled status instead of checking
if there is an associated rev id. This allows to associate a revision
to a log entry without possibly making the recent change unpatrolled,
and extensions can implement patrol of actions not dependent on an
associated revision id.
Bug: T127848
Change-Id: I98298047142819b69639e6ca9d77c5ba982a380c
- Add 'tags' parameters to appropriate API modules
- Add tag-adding logic to appropriate functions that carry out
relevant functions
- ManualLogEntry::{set,get}Tags to handle adding tags to log
entries in a cleaner fashion
- Use ManualLogEntry::setTags in LocalFile::recordUpload2
Bug: T97720
Change-Id: I98c52da7985623bfdafda2dc2dae937b39b72419
UploadBase::performUpload() now takes a $tags parameter and passes it
to LocalFile::upload() and LocalFile::recordUpload2(), which
eventually adds the requested tags to the log_id, rev_id and rc_id
that are created for the file upload.
Previously you'd have to query the database for the latest rev_id and
log_id for the page title under which the title is being uploaded, as
performUpload() is unable to return them to you because it's all
deferred in funny ways.
Bug: T121874
Change-Id: I99a8fd67c84219d2715d3d88cc21500614431179
The implementation from 0160b410bd only
stored the associated rev id in the `recentchanges` table, which was
sufficient for its purpose of allowing patrol of these log entries and
provided some change tagging improvements, but ephemeral.
Now we also store it in `logging` and `log_search` tables, which makes
it possible to find a revision for the log entry and vice versa.
* For `log_search` we just add a row with 'associated_rev_id' as key,
it was designed for exactly this purpose.
* For `logging` we store it in log_params field in ManualLogEntry, and
transparently remove it from there when building a DatabaseLogEntry.
Bug: T122089
Change-Id: I559587ff77b3c94b31a6c5951287b6f9c1e167ce
