Without this patch, the forcelinksupdate parameter of ApiPurge
was inoperational, caused by the fact that RefreshLinksJob got
the original revision's timestamp in the rootJobTimestamp parameter,
instead of the time at which the new ParserOutput was created.
See <https://phabricator.wikimedia.org/T210307#4771586> for details.
Bug: T210307
Change-Id: I281d6d0ed112b35e160775e528d363ce4770990a
These new classes provide a mechanism for defining the
behavior of slots, like the content models it supports.
This acts as an extension point for extensions that need
to define custom slots, like the MediaInfo extension
for the SDC project.
Bug: T194046
Change-Id: Ia20c98eee819293199e541be75b5521f6413bc2f
Note that we will still be re-parsing either the old or the new
revision. Keeping the rendered version of the old revision cached
for a bit would be nice, but ParserCache currently does not
support this.
Bug: T205369
Change-Id: I86d26e494924eec24e7b1fb32c424ac1284be478
The code in DerivedPageDataUpdater that used the stashed ParserOutput from
ApiStashEdit::checkCache was accidentally broken when RevisionRenderer
was introduced in I871978bf79f67c9e7954fb3fc8528d6e365f2cc1.
This is likely the cause for the degraded save timing noted in T205369.
Bug: T205369
Change-Id: I6d8fdda73dccae08d18bfb528b948706f56ad2e0
Checking the acting user against the revision's author in
DerivedPageDataUpdater::isReusableFor would lead to false
negatives.
Also removes a check of the current acting user against the
cached revision's author, for the same reason: for null edits,
the acting user and the revision author are unrelated.
Bug: T205369
Change-Id: I48f59dce6c25062b3d6ff4248e1171269766c507
Non-breaking change. Remaining uses are public interfaces (a constant, two
globals, a config sub-parameter, SQL queries, storage function names), one i18n
message key, and a whole lot of maintenance scripts with calls to the deprecated
function wfWaitForSlaves().
Change-Id: I6ee5ca92ccf6a80c08f53d9efe38ebb4b05064d7
LoadBalancer uses Database::getDomainId() for deciding which keys to use
in the foreign connection handle arrays. This method should reflect any
changes made to the DB selection.
If the query fails, then do not change domain field. This is the sort of
approach that LoadBalancer is expects in openForeignConnection(). Also,
throw an exception when selectDB() fails.
The db/schema/prefix fields of Database no longer exist in favor of just
using the newer currentDomain field.
Also:
* Add IDatabase::selectDomain() method and made selectDB() wrap it.
* Extract the DB name from sqlite files if not explicitly provided.
* Fix inconsistent open() return values from Database subclasses.
* Make a relationSchemaQualifier() method to handle the concern of
omitting schema names in queries. The means that getDomainId() can
still return the right value, rather than confusingly omitt the schema.
* Make RevisionStore::checkDatabaseWikiId() account for the domain schema.
Unlike d2a4d614fc, this does not incorrectly assume the storage is
always for the current wiki domain. Also, LBFactorySingle sets the local
domain so it is defined even in install.php.
* Make RevisionStoreDbTestBase actually set the LoadBalancer local domain.
* Make RevisionTest::testLoadFromTitle() account for the domain schema.
Bug: T193565
Change-Id: I6e51cd54c6da78830b38906b8c46789c79498ab5
During development a lot of classes were placed in MediaWiki\Storage\.
The precedent set would mean that every class relating to something
stored in a database table, plus all related value classes and such,
would go into that namespace.
Let's put them into MediaWiki\Revision\ instead. Then future classes
related to the 'page' table can go into MediaWiki\Page\, future classes
related to the 'user' table can go into MediaWiki\User\, and so on.
Note I didn't move DerivedPageDataUpdater, PageUpdateException,
PageUpdater, or RevisionSlotsUpdate in this patch. If these are kept
long-term, they probably belong in MediaWiki\Page\ or MediaWiki\Edit\
instead.
Bug: T204158
Change-Id: I16bea8927566a3c73c07e4f4afb3537e05aa04a5
This changes the user name to "User unknown" when constructing a RevisionRecord
from a database row that has an empty ar_user_text resp rev_user_text field.
This may cause "User unknown" to be written to the database, if the
RevisionRecord is used as the basis for a new revision that is being created,
particularly during undeletion. Since "Unknown user" is listed in
$wgReservedUsernames, this should never lead to conflicts with actual user
names.
It is assumed that empty ar_user_text and rev_user_text fields will be
fixed during migration to the new actor based database schema.
Bug: T195692
Change-Id: I506c513b019778d83741e47f0d11093f5ab67a54
Added spaces around .
Removed empty return statement which are not required
Removed return after phpunit markTestIncomplete,
which is throwing to exit the test, no need for a return
Change-Id: I2c80b965ee52ba09949e70ea9e7adfc58a1d89ce
This adds getSecondaryDataUpdates and getDeletionUpdates
to ContentHandler, and updates WikiPage and DerivedPageDataUpdates
to handle DataUpdates from all slots.
Bug: T194038
Bug: T194037
Change-Id: I75c96318f58a5cdda48484f7040ae41e6f42392a
RevisionRecord::isReadForInsertion provides a concise way to check
whether a revision is complete enough to be inserted into the database.
Change-Id: I0c79f55c0b935bce9943163ed4c2cc8b5f9c82d5
With the new schema, undeletion does not create now slot rows.
However, when in read-old mode, we may still have un-migrated
archive rows. When undeletion based on such a row, we do need
to insert a slot row.
This also changes the return value of SlotRecord for
SCHEMA_COMPAT_READ_OLD mode from null to the negative value of
rev_text_id, for consistency. Conceptually, the emulated slots
in SCHEMA_COMPAT_OLD now have a "virtual" content ID, hich is
however distinct from any real content ID that may exist in
the future. Such virtual content IDs are however not assigned
in SCHEMA_COMPAT_WRITE_BOTH mode. In that mode, unmigrated
rows can be detected by calling hasContentId() on the main
slot. Migrated rows will return true here and provide the
id of the associated content row, even in
SCHEMA_COMPAT_READ_OLD mode. This is particularly essential
for undeletion, which needs to maintain the association
between revision and slot rows even in SCHEMA_COMPAT_READ_OLD
mode.
Bug: T174024
Bug: T194015
Bug: T183488
Change-Id: I88ee9809b9752e1e72d635d62e82008315402901
This injects the new, unsaved RevisionRecord object into the Parser used
for Pre-Save Transform, and sets the user and timestamp on that revision,
to allow {{subst:REVISIONUSER}} and {{subst:REVISIONTIMESTAMP}} to function.
Bug: T203583
Change-Id: I31a97d0168ac22346b2dad6b88bf7f6f8a0dd9d0
Replaces Content::getSecondaryDataUpdates with
WikiPage::getSecondaryDataUpdates so that aggregation of
data updates from multiple page slots can be handled without
the caller having to care about it.
Also adds a WikiPage::updateParserCache method for convenience.
This is a temporary measure until DerivedPageDataUpdater
(or its replacement) can be exposed directly, at which point
the WikiPage methods will be deprecated.
Also fixes a parameter handling bug in DerivedPageDataUpdater.
Bug: T194043
Change-Id: Idbe7d582b49fcb7c90aea813773b7610ad44b1a8
With a separate service for each of the NameTableStore tables, it
wasn't possible to instantiate a NameTableStore for a foreign wiki,
leading to the inelegant situation of having RevisionStoreFactory
construct a new NameTableStoreFactory every time a RevisionStore for a
foreign wiki was requested. These NameTableStore objects were not
tracked in any structured way, so there was no way to reset them for
tests.
So, introduce NameTableStoreFactory, which tracks object instances for
both local and remote table access.
This also avoids having schema details in ServiceWiring.php.
Depends-On: I5c78cfb8bf90eca935a3264592366f63517c4fad
Bug: T202641
Change-Id: Ic0f2d1d94bad9dcc047ff19a1f92db89b7e014ce
This allows optimization for situations in which a caller
needs the meta-data of a ParserOutput, and the respective
ContentHandler can provide that meta-data without generating
HTML output.
Bug: T194048
Change-Id: I786d294d18a6a2e3cea61577313e21b578c44f1e
RevisionRenderer is the MCR replacement for Content::getParserOutput,
as outlined in <https://www.mediawiki.org/wiki/User:Daniel_Kinzler_(WMDE)/MCR-PageUpdater>.
Note: This change also introduces quite a bit of code for
merging ParserOutput objects.
Bug: T194048
Change-Id: I871978bf79f67c9e7954fb3fc8528d6e365f2cc1
When loading revision slots from the new MCR schema, slot role names
and content model names need to be resolved. Doing so programmatically
based on an in-memory cache avoids having to join against two additional
table every time we load slot meta-data.
This relies on NameTableStore, which was designed for exactly this use
case.
Bug: T198561
Change-Id: Ic005931b669f9d0173ef47ac17331d44fb1141ca
Resetting the content_model and slot_role tables between test runs
requires the corresponding NameTabelStore instances to be reset
as well. We may however have many of them, buried in various services.
There is no easy way to reset them consistently.
Letting information in these tables persist between tests seems
harmless. Tests that need these tables reset can simply add them
to the tablesUsed array.
This is needed for unit tests to work with the new MCR schema.
Bug: T198561
Change-Id: I63e61e1ab74e00c20930a83d3a3f5df53092a197
Since SDC doesn't actually require the edit form to handle multi-slot
editing, updating EditPage with its normal undo handling is being put
off for later. But in the mean time we still want some sort of "undo" to
work, hence this mcrundo that doesn't allow for editing.
Bug: T200216
Change-Id: I1f11d8ed141cb11576d2df883856d03e8f64bd38
Depends-On: Iedd9bf6c057e8b396a575bab700b15bd38b32cc9
MySQL until 8.0 and MariaDB until some version after 10.1.34 don't save
the auto-increment value to disk, so on server restart it might reuse
IDs from deleted revisions. We can fix that with an insert with an
explicit rev_id value, if necessary.
Bug: T202032
Change-Id: I14e5b6c8ec8b5f1aeb2305fae4b103665f8f6686
BlobStoreFactory::newBlobStore() takes a wiki ID as a parameter, so it
needs an LBFactory to fetch the correct LoadBalancer from.
Bug: T202483
Change-Id: I834cd95251d76cb862600362525faf60d4e170b9
The new MCR schema enables cross-wiki loading of page content,
but this mechanism doesn't work as long as the new code is reading from
the old schema. This is what caused T201194.
Bug: T201194
Change-Id: I58af7a9e02780c55cd8fab20f19be36a0fa804da
Using false to represent the local wiki is supported in many places in core,
but not in invalidateModuleCache
Bug: T199416
Change-Id: I5cb93c173295261bf5fcf6c77c197a80c4aac1a2
This makes explicit the fact that some classes can use the local wiki's default
WANObjectCache instance while still sharing cache entries between wikis.
Bug: T198704
Change-Id: Ic29f79e4b4bd6bdaa844049962a163e72a59c45a
MCR deprecated the Revision class in favor of the broadly similar
RevisionRecord, and more interestingly added the concept of multiple
content "slots" to revisions.
Thus, prop=revisions, prop=deletedrevisions, and so on gain a parameter
to specify which slots are wanted. When this new parameter is not
specified (and any content-related props are specified), a warning about
the legacy format will be issued.
The rest of the modules just needed to call methods or use constants on
RevisionRecord instead of Revision. ApiQueryDeletedrevs wasn't touched,
since it has been deprecated since 1.25 anyway.
This also updates a few non-query modules that don't depend on details
of editing, diffing, or viewing MCR revisions that haven't been figured
out yet.
Bug: T200568
Change-Id: I1327d1784f5cedb006cd74df834cf9a560a77a5d
