Flow hooks into ContribsPager, causing formatRow() to be called with
FormatterRow objects instead of stdClass objects. formatRow() is
expected to silently decline to format such objects, leaving formatting
up to a subsequent hook.
Instead of calling newRevisionFromRow with all warnings suppressed and
all exceptions caught, provide isRevisionRow() which determines whether
the row is valid. Thus, unexpected exceptions will be visible and the
code does not depend on details of how newRevisionFromRow() validates
its arguments.
Bug: T288563
Change-Id: Id0316886d770cd905897d515b3eb658a5875bd80
Additionally it switches the query from DB_PRIMARY to DB_REPLICA.
I understand the idea with a quick revert, but I do not think
it can be that quick - to revert a newest revision of a page,
an editor or a bot needs to actually read it first, and reads
come from a replica. So we know at least some replicas already
had the latest revision showing to the user. Very likely by the
time revert is made, we'd have it in all replicas. If not - oh well,
we can't be perfect. But we shouldn't really do such a query on
primary - it's too heavy.
Change-Id: I2fae8dbe5f19635f4d99e26242e3b08ddad8f8af
Updates for the removal of the Revision class itself
and the various methods/hooks/variables removed in the
process, including:
- Update some documentation removing most references
to the Revision class and updating the MCR migration
notes to reflect the past tense for Revision methods.
- Change some capitalization from "Revision" to "revision"
to make it clear comments are about revisions in general,
not the Revision class in particular.
- Minor code tweaks including removing unused variables that
were around for the old hooks that were removed, and
removing the use of DeprecatablePropertyArray where no
longer needed for anything.
- Fix incorrect documentation for PageUpdater::getStatus(),
the status value changed a while ago to have revision-record
in addition to revision, and recently to only have the
revision-record, but ironically PageUpdater was never updated.
- Removed Parser::$mRevisionObject, used to be a Revision object
and was deprecated in 1.35, missed earlier because it was no
longer being set to Revision objects, always null.
- Add RevisionRecord typehints in DummyLinker to match those
in the corresponding Linker methods
This should be a no-op in terms of functionality.
Bug: T247143
Change-Id: I03bbb94fc29085855448780b1a5ad9063911ecc4
All hooks were previously hard deprecated
in 1.35. Affected hooks:
* ArticleRevisionUndeleted - use RevisionUndeleted
* ArticleRollbackComplete - use RollbackComplete
* DiffRevisionTools - use DiffTools
* DiffViewHeader - use DifferenceEngineViewHeader
* HistoryRevisionTools - use HistoryTools
* NewRevisionFromEditComplete - use RevisionFromEditComplete
* PageContentInsertComplete - use PageSaveComplete
* PageContentSaveComplete - use PageSaveComplete
* ParserFetchTemplate - use BeforeParserFetchTemplateRevisionRecord
* RevisionInsertComplete - use RevisionRecordInserted
* TitleMoveComplete - use PageMoveComplete
* TitleMoveCompleting - use PageMoveCompleting
* UndeleteShowRevision - no replacement
Includes a fix for setting the associated rev id
of page protections, which previously was only done
using $nullRevision which was a Revision object created
if any hooks needed it; those hooks were hard deprecated
and so for WMF prod the rev id was not being set.
Bug: T247143
Depends-On: Idfa345193ae99fb2f1c9a8f8d28d8d540a6e3d62
Change-Id: I519167f76a5a3c1f5410415b2721462a3dcc3ec8
When we find that a revision we loaded doesn't belong to the expected
title, log the error and continue, instead of failing hard.
This could happen if a caller to e.g. getRevisionById supplied a Title that is
plain wrong. In this case, we should ideally throw an IllegalArgumentException.
However, it is more likely that we encountered a race condition during a page
move (T268910, T279832) or database corruption (T263340). That situation
should not be ignored, but we can allow the request to continue in a reasonable
manner without breaking things for the user.
Note that this patch does not resolve the mentioend bugs. It only
reduces impact for users. We still need to find out when and why we are
gettign mismatching titles.
Bug: T259022
Bug: T268910
Bug: T263340
Bug: T279832
Change-Id: Ia64ad3b8a6e3c3348bc0a276d528ead127c6b0e0
Code that needs to store an actor ID in the database to
represent a UserIdentity, or needs to construct a UserIdentity based on
an actor ID loaded from the database, should use the ActorNormalization
service.
Note: The getActorId() method is removed from the UserIdentity interface,
but all concrete classes continue to support it for now.
UsererIdentityValue::getActorId() is hard deprecated and should
be removed in 1.37. It always returns 0.
User::getActorId() is not deprecated at this point.
Bug: T274179
Depends-On: Id2b3ddf6a2a7cdf90f8936a69148d2cce6fde237
Change-Id: I9925906d11e47efaec3c1f48d5cb3f9896a982c1
Providing a PageIdentity to getRevisionById removes the need
to look up page related data, and to construct a Title.
Bug: T275531
Bug: T273284
Depends-On: I8d0dc30ecd0c0c65c337170d271c2e2531914686
Change-Id: I683362ccd669acf2aadf56853afeb1ca6dee6f8c
The new getPage() handles cross-wiki access correctly. It's not a direct
replacement for getTitle(), since it is private.
getTitle() cannot work properly for RevisionStore instances connected to
a sister-wiki. It was already discouraged, and is nearly unused outside
of RevisionStore. Remainign usages should be replaced with
RevisionRecord::getPage().
Note that PageIdentityValue is not lazy loading, while Title is.
Code in newRevisionFromRowAndSlots() was adjusted to take advantage of
any fields from the page table that may already be present from a join,
to avoid an additional query to the page table.
Bug: T275531
Bug: T273284
Change-Id: If4525d76a578b92dbcfe1f5150028f7a28811119
ActorNormalization should only be used in contexts where a DB connection
is already being used, or at least easily available.
Bug: T276986
Change-Id: Ie8aadaffa4a30e63fcad0502d45b8ec364fc79ef
We are in the process of moving from getUserId() to getId() anyway. That
should resolve the issue in addWiki for now. It will however break again
in the future, when we requrie a matching wikiId in User::getId().
The real fix would be resolving T200471.
Bug: T275452
Change-Id: I9a7c383a6c31929e25899fd627131afc25584d5b
This is micro-optimization of closure code to avoid binding the closure
to $this where it is not needed.
Created by I25a17fb22b6b669e817317a0f45051ae9c608208
Change-Id: I0ffc6200f6c6693d78a3151cb8cea7dce7c21653
The following methods have beed converted:
::getRevisionByTitle
::getRevisionByTimestamp
::newRevisionFromArchiveRow
::newRevisionsFromBatch
::getKnownCurrentRevision
::getFirstRevision
Appropriate tests were adjusted to test both old interface (with
Title) and new interface (with PageIdentityValue)
Bug: T272886
Change-Id: Ica8da21d2413df885365475eaa498214edbcfd1d
In this patch I replaced RevisionStore::$dbDomain to
RevisionStore::$wikiId, RevisionRecord::$mWiki to
RevisionRecord::$wikiId and changed all hierarchies
and tests accordingly
Bug: T272901
Change-Id: I439515cfb6aa8a8697c2a5a0458ec8925522363a
When a revision row does not belong to the page we expected it to belogn
to, throw RevisionAccessException instead of IllegalArgumentException,
since this situation generally indicates data corruption rather than a
coding error.
Bug: T263340
Change-Id: Ib48f92e0cb2ef26b4f73e94d82f907cefdffcd94
Ideally typehinting $id would be more effective, but a lot of
callers are just passing RevisionRecord::getId() directly which
is documented to return int|null. Typehinting the param here would
require first fixing those callers to ensure they are passing the
required int.
For now this patch will prevent the useless query, in case the
RevisionRecord::getId() call do return null where it's used as an
argument for this method. A case for <= 0 is also checked, while
not strictly necessary, it will also lead to useless query if such
value ever reaches here for whatever reason.
Bug: T270149
Change-Id: I5c23955e29efed4bec4c2e9652af1c2c3bf79218
