| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
Bug: T353458
Change-Id: Ibe1810f1c71316a9124e1dc6ae405097dafd5267
|
|
|
|
| |
Change-Id: Ib23a1afe2bc0b90fcf9291935b6ed019669494e8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is moderately messy.
Process was principally:
* xargs rg --files-with-matches '^use Title;' | grep 'php$' | \
xargs -P 1 -n 1 sed -i -z 's/use Title;/use MediaWiki\\Title\\Title;/1'
* rg --files-without-match 'MediaWiki\\Title\\Title;' . | grep 'php$' | \
xargs rg --files-with-matches 'Title\b' | \
xargs -P 1 -n 1 sed -i -z 's/\nuse /\nuse MediaWiki\\Title\\Title;\nuse /1'
* composer fix
Then manual fix-ups for a few files that don't have any use statements.
Bug: T166010
Follows-Up: Ia5d8cb759dc3bc9e9bbe217d0fb109e2f8c4101a
Change-Id: If8fc9d0d95fc1a114021e282a706fc3e7da3524b
|
|
|
|
|
|
| |
Related to I29399e7.
Change-Id: Iafa1fcac95f9b7a6cbc3a8ae9d4aff825acb302d
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
Change-Id: Ia2c4819848f5d23d5ceb74aae9c6c5920b8851ba
|
|
|
|
|
| |
Bug: T274329
Change-Id: I3dadb20f076494f7b46f0647ea3a8bfbbdaa59da
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
Not sure but the previous wording didn't make much sense or is it
correct that way?
Change-Id: Ia5bea91fb426bb2fe742e656e5a826b8c07d88ee
|
|
|
|
| |
Change-Id: I3eaaf23612fe1aed65e49c06a9e5e565399af9ce
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
This was unintentionally removed in I8df2fd98.
Bug: T218110
Change-Id: Ie8678b4207032d6eb877d596eb8f115798c80a1e
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The documentation already claimed it returned array,
this is now actually true. Follows-up 037c06e886c63.
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
|
|/
|
|
| |
Change-Id: I7d5b4e05ee6c010b4f9438bc4871a3369b1871a6
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|\ |
|
| |
| |
| |
| |
| |
| | |
Also remove not necessary surrounding parentheses.
Change-Id: I0eb5c9c1bdfb09a800258379cdcefb5fd4d3d21c
|
|/
|
|
|
|
| |
Auto fix MediaWiki.Commenting.FunctionComment.DefaultNullTypeParam sniff
Change-Id: I865323fd0295aabd06f3e3c75e0e5043fb31069e
|
|
|
|
| |
Change-Id: I936c3f5fca1a0061f215e80469f5d882cb32ee29
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |
| |
| |
| | |
Change-Id: I25912f38bb483cd4636bff4ce219dc878a1046f3
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
|/
|
|
|
|
| |
This constants has been recently introduced and it's good to use them
Change-Id: I8ce56dc95de3e49610dca71c00965ca1ac74bcf0
|
|
|
|
|
| |
Bug: T184791
Change-Id: If64ba8b845b122a87f20646dddf72ef257b793cb
|
|
|
|
|
|
| |
It's a helper function for when you need just one log entry.
Change-Id: Ic5e9db0def857d9dcecbd06bf081c8c83712c1ea
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
Bug: T182273
Change-Id: I9e1b628fe5949ca54258424c2e45b2fb6d491d0f
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|/
|
|
|
|
| |
The method was deprecated and made unnecessary in Ib308190c.
Change-Id: I1729ac0b3a88270a4c2f064187a2472112aaeb1e
|
|
|
|
|
|
|
| |
A subsequent patch will remove the old columns.
Bug: T166732
Change-Id: Ic3a434c061ed6e443ea072bc62dda09acbeeed7f
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
Change-Id: If7e8a8ff574661fd827de8bcec11d2c39a687300
|
|
|
|
| |
Change-Id: I557b92f25f15f57123af329c79ef1752025aedf3
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
Per wikitech-l consensus:
https://lists.wikimedia.org/pipermail/wikitech-l/2016-February/084821.html
Notes:
* Disabled CallTimePassByReference due to false positives (T127163)
Change-Id: I2c8ce713ce6600a0bb7bf67537c87044c7a45c4b
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 0160b410bd514681b1637ccab2b7c79158fbfb29 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
|