These are almost only doc changes, with two exceptions:
1-In LinkHolderArray, int-alike array keys are now cast to int, to be uniform with what we do in other code paths
2-In ExtensionRegistration, changed a line to throw an Exception
immediately, instead of an ExtensionDependencyError. This is because the
latter takes an array with msg and type, but we were passing it a plain
string (and in fact the code was bugged).
Bug: T231636
Change-Id: I8b0ef50d279c2a87490dde6a467a4e22c0710afd
This patch fixes the documentation of newFromText and makeTitleSafe to
no longer state incorrectly that any Title they return is guaranteed to
be valid. That has never been true.
It also makes canExist() checks a lot stricter, to match the assumptions
of current callers, namely that the title can exist as a wiki page.
Finally, it replaces several existing calls to isValid() with calls to
canExist().
Bug: T229705
Change-Id: I2a483136ec6acca49afb5eb32cb94616672b8fb2
*I2341e6f inverted the permission check, such that now the link is only shown to unprivileged users
Bug: T234017
Change-Id: I0977f1ab1a72840303aeca2367a30546d83117d4
The method LogPager::getFilterParams combines data aggregation and query
modification which is problematic: it starts with "get" and is public
but has a side-effect. Instead, make a dedicated private method for
building the query and remove the side-effect.
The new private method is now dedicated to building the query, and so
it can also make sure whether selection by log id is requested. If it's
the case, it won't filter the log types out (fix for T220834).
Also remove redundant comment: it's irrelevant to require callers to
call a private method.
Bug: T220834
Change-Id: I0fb6e6ee30ac626192cdf4ef920a731c03b2732f
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
*LogPage::timestamp was introduced with r4919 back in 2004, and is unused
since then.
*ApiMain::mCommit was introduced in r33133, then removed in r33381 but that
line was forgotten.
*SpecialRecentChangesLinked::mResultEmpty was introduced in r36682, then
removed at some point with this leftover.
*SpecialStatistics::hook, introduced in r54511 and unused since then.
*MergeMessageFileList::hasError introduced in Id4b16083435ef7f4fce31861c72889e664d07236
and removed in I3d9cf1d614dacaa91fb2092019ccf1d14d61ccab with a leftover
Change-Id: Ie15c148a3217ee8da62874840f3ef7739893f69e
$tags can be `null` as seen in most cases and this causes failures,
so, the safer path is to make sure if $tags is a null, do nothing.
Change-Id: I5b7e39adba5d08fdcd42c437a72a391be98c8695
This makes LogFormatter more robust against bad user names coming from
broken log records.
Bug: T224368
Change-Id: Ifce9e86bddba274182253cd25338766e8093d6ad
ofield and nfield may be missing from old log entries. Take that into
account when processing.
Bug: T224815
Change-Id: I06dda3106bab9980f6fa7d515542e94a91c17f64
We'll hope MariaDB doesn't trigger T221458 in that situation.
Bug: T222324
Signed-off-by: Scott Bassett <sbassett@deploy1001.eqiad.wmnet>
Signed-off-by: James D. Forrester <jforrester@wikimedia.org>
Change-Id: I06364e9d0bce45bd97b2ec837d1f479feff76699
For some unknown reason, when the `actor` table has few enough rows (or
few enough compared to `logging`) MariaDB 10.1.37 decides it makes more
sense to fetch everything from `actor` + `logging` and filesort rather than
fetching the limited number of rows from `logging`.
We can work around it by telling it to not reorder the query.
Bug: T220999
Bug: T221458
Change-Id: I9da981c09f18ba72efeeb8279aad99eb21af699a
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
It is possible for the log_params column of the logging
table to contain serialized data that cannot be deserialized
anymore because the types it references are missing.
It is currently the case with old Flow log entries on enwiki.
The extension is uninstalled and the UUID class is not found.
This patch proposes to simply skip the params and log a
warning in that case.
Bug: T212742
Change-Id: I3226b8fb338dd2b81e087af5d798d8f35368282d
You can see them when you view a previously deleted page
and some of those events have been tagged.
Bug: T212613
Change-Id: I88e637a0ee688dd23c0ec90790e8189ecf1a8789
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
