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
Before I81a70ca03fd219d2e96b17714645d9cc4f99b3b9
the archivedRevisionCount argument of the ArticleDeleteComplete
hook used to be an integer, now it's an string. This is backwards
incompatible and needs to be changed back.
Bug: T210013
Change-Id: I297594803fe05cc00cdf209696933b2450d020b6
Use these in place of various wfWikiID() calls.
Also cleanup UserRightsProxy wiki ID variable names and removed unused
and poorly named getDBname() method.
Change-Id: Ib28889663989382d845511f8d34712b08317f60e
The rd_fragment field is 255 bytes wide, but there is no limit on how
long title fragments can be. We don't want to let the database silently
truncate the fragment for us, because that can result in invalid UTF-8.
Instead, truncate it before insertion in a UTF-8-aware way.
Bug: T207876
Change-Id: I12745f3f4c174eaced56d80f3661a71d0e5637e6
If a user creates a redirect to a Media namespace title, a fatal
error is thrown on viewing such rediect because we protect against
redirecting to virtual namespaces. This fix catches this kind of
redirect and modifies the namespace to be File before the Title object
is created.
Follow-up from 613e2699.
Bug: T203942
Change-Id: Ib211d98498f635862fea6bf3e7395f4f8718b3d8
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
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
Pages with many revisions experience transaction size exceptions,
due to archiving revisions. Use the job queue to split the work
into batches and avoid exceptions.
Bug: T198176
Change-Id: Ie800fb5a46be837ac91b24b9402ee90b0355d6cd
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
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
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
This means that now:
* Entries actually get deleted when expired
* The transclusion cache is shared across wikis
* Large blobs that do not fit in cache no longer cause DB errors
* DB writes are not triggered on GET requests
* Keys are hashed and no longer need to be so restrictive
Also, add a "check key" based purge system and process cache the
text/html values similar to how regular revision text is cached.
Bug: T189702
Change-Id: I8ac12b53c02bb26857175dd5a4af29d49e03dc33
In some functions MediaWikiServices::getInstance() was called twices or
in loops. Extract the variable to reduce calls.
Change-Id: I2705db11d7a9ea73efb9b5a5c40747ab0b3ea36f
If the page has no differences in any slot, the method is incorrectly
returning "true" to claim there are differences in some non-main slot.
Follows up Ifdf9bc9d884844f9ffeb8019d9b13d5737862063.
Bug: T194412
Change-Id: I013bcd9c39d05d9af47c1a29026b14d27af2db15
Having a different ParserOptions for each content model isn't feasible
in an MCR world. And the only thing using this was Wikibase, which has
been fixed to do what it needs in a different way.
Bug: T194263
Change-Id: I01373b29ee25fa9346c6b0317155be4ccdc8c515
Without this fix, the Content would be parsed twice during an edit,
if extensions that hook into EditFilter and similar
pre-parse hooks call WikiPage::prepareContentForEdit.
With this fix, ParserOutput created by prepareContentForEdit is
re-used by doEditContent.
This is a stop-gap solution. The Real Fix (tm) is to stop using
doEditContent, and use a PageUpdater instead.
Bug: T198483
Change-Id: I42123e48de2b087ef98d8a4855ee3aebd7f1de57
NOTE: this changes the numeric values of the MIGRATION_XXX constants!
Order is preserved.
Bug: T197619
Change-Id: I16db7dd5799ab98c1cb12e7cd1e0b2da83b366fc
It causes them to be tagged with the "mw-undo" tag, in addition to the
"mw-rollback" tag they already have.
Bug: T190374
Change-Id: Ia447a107f0844cfef4a51a72fdec7aeea0480c70
This method returns the value used as cl_type for category links that
are "from" pages within the namespace, and is added to avoid duplication
of code across a few classes.
Change-Id: I4e55932a5a27858cfedb12009b455fcd02f9b5df
This reverts a recent change that caused the table array and the
join array to have mismatching keys, so that the select was a
cartesian product of page and revision_comment_temp (ie. any
page deletion locked the whole revision_comment_temp table).
Bug: T198350
Change-Id: Ifb6f0409d4f210d3ecb1da03f59aaba7e229e89e
The $baseRevId in WikiPage::doEditContent is used only to indicate what
revision an edit reverted to. It is not used to indicate the actual base
revision of an edit in any sense. Specifically, EditPage never sets it.
So, this change renames the parameter to $originalRevId to match $undidRevId.
It also renames PageUpdater::setBaseRevisionId to setOriginalRevisionId.
Further, this introduces a paramter to PageUpdater::hasEditConflict():
Before this change, PageUpdater::hasEditConflict() was based on the
revision set via PageUpdater::setBaseRevisionId(), assuming the semantics
of "base revision" used by EditPage. However, this is NOT how the $baseRevId
parameter in WikiPage works.
Bug: T197685
Change-Id: Ib78257d4d6ee7c4ec093d5706904c599b02c73e0
Enable inserts to the new MCR db schema in single slot mode only.
TODO:
- RELEASE NOTES
Notes:
- When in MIGRATION_WRITE_NEW or greater, deleting and then
restoring a page will result in different data in the revision table.
For example, if you delete a page that has text_ids present in the
revision table and restore it, the text_ids will be blank after.
- When in MIGRATION_WRITE_BOTH or greater the archive table will
start to ar_content_model entries where previously it would have been
given NULL. This is due to the old content schema having NULL in the db
when the default content model is used, but the new schema will always
have a value, taken from the content_models table
Note: If259b1e1c49ce was squashed into this change.
Bug: T183488
Bug: T174024
Change-Id: Ic2221da30c8f6ac2ba42720fcd568f2d0ed70534
This introduces PageUpdater to replace WikiPage::doEditContent,
and DerivedPageDataUpdater, to replace WikiPage::doEditUpdates
and WikiPage::prepareContentForEdit.
See docs/pageupdater.txt for a description of their
functionality.
MCR migration notes:
* The interface of PageUpdater is expected to
remain mostly stable after this patch. Code that has been using
WikiPage::doEditContent can be confidently migrated to using the
new mechanism for revision creation.
* This patch keeps the code inside PageUpdater largely aligned
with the old code in WikiPage, to make review easier to to avoid
mistakes. It is intended to be refactored further, moving
application logic into stateless services.
* DerivedPageDataUpdate is intended as a stepping stone for further
refactoring. Its behavior is designed to be compatible with
callback code that currently relies on
WikiPage::prepareContentForEdit. Much of the code that currently
lives in DerivedPageDataUpdate should be factored out into
services, all behavior relevant to calling code should be exposed
via narrow interfaces.
Bug: T174038
Bug: T196653
Change-Id: If610c68f4912e89af616cdcac1d35a1be3946afa
Find: /isset\(\s*([^()]+?)\s*\)\s*\?\s*\1\s*:\s*/
Replace with: '\1 ?? '
(Everywhere except includes/PHPVersionCheck.php)
(Then, manually fix some line length and indentation issues)
Then manually reviewed the replacements for cases where confusing
operator precedence would result in incorrect results
(fixing those in I478db046a1cc162c6767003ce45c9b56270f3372).
Change-Id: I33b421c8cb11cdd4ce896488c9ff5313f03a38cf
