This is a quick find & replace of calls to the deprecated method
ParserOptions::newCanonical() when the context is the string literal
'canonical'. This can be safely replaced by called newFromAnon().
Change-Id: If7bb68459b11e0c5f5de188f10fdae85ad1a78bf
* Allow EditPage to create a user on page save. This has to be enabled
in config and then activated by the UI/API caller.
* Add an autocreate source for temporary users.
* Allow editing by anonymous users via automatic account creation when
$wgGroupPermisions['*']['edit'] = false. On an edit GET request, use
an unsaved placeholder user to stand in for post-create permissions.
* On preview or aborted save, the username to be created is stashed in a
session and restored on subsequent requests.
* On a (likely) successful page save, create the account.
* Put regular non-temporary users in a "named" group so that they can be
given additional permissions.
* Use a different "~~~" signature for temporary users
* Show account creation warnings on edit and preview.
Change-Id: I67b23abf73cc371280bfb2b6c43b3ce0e077bfe5
This ensures that assertions work in a uniform way,
and provides meaningful messages in cause of failure.
Change-Id: Ic01715b9a55444d3df6b5d4097e78cb8ac082b3e
Follows-up I361fde0de7f4406bce6ed075ed397effa5be3359.
Per T253461, not mass-changing source code, but the use of the native
error silencing operator (@) is especially useful in tests because:
1. It requires any/all statements to be explicitly marked. The
suppressWarnings/restoreWarnings sections encourage developers to
be "lazy" and thus encapsulate more than needed if there are multiple
ones near each other, which would ignore potentially important
warnings in a test case, which is generally exactly the time when
it is really useful to get warnings etc.
2. It avoids leaking state, for example in LBFactoryTest the
assertFalse call would throw a PHPUnit assertion error (not meant
to be caught by the local catch), and thus won't reach
AtEase::restoreWarnings. This then causes later code to end up
in a mismatching state and creates a confusing error_reporting
state.
See .phpcs.xml, where the at operator is allowed for all test code.
Change-Id: I68d1725d685e0a7586468bc9de6dc29ceea31b8a
PreparedUpdate represents an in-progress edit. It can be used to access
information about the edit from hooks that do to have access to the
PageUpdater. Ideally, the PreparedUpdate or PageUpdater would be passed
to the hook as a parameter. Handlers of legacy hooks may use
WikiPage::prepareUpdate() to access it.
Bug: T242249
Needed-By: I23324a31e06e7e6f28077085c0ade05db63e9a35
Change-Id: Id5ba40a21cc4547205adf2f3a1f725c3a69c24d8
Sometimes we apply tag to a revision even if we
suppress the RecentChange, for example when leaving
redirects after page moves.
Bug: T291967
Change-Id: I7330d3b56cd2280dd23ec0ccb4e1c4807c534739
Some methods in the PageUpdater's class implements the fluent interface
design pattern. Use the fluent interface where need be.
Change-Id: If76a4b8c5070c20ed40038a4ee78e2d677de5180
This ensures that a DerivedPageDataUpdater is initialized earlier during
the edit process, so it can be used by hooks to access the state of the
ongoing edit.
This patch also cleans up PageUpdater a bit to make the internal information
flow more consistent with the idea that PageUpdater is acting as a
builder for a new revision.
Change-Id: I99abb7bdffb2b5ff5979ba5b1e56d39dba4cd3dc
WikiPage is not the right spot to compute all the revert
related stuff - we already figure out manual reverts when
building the EditResult, lets figure out rollbacks and undos
in there as well.
Change-Id: I9fdc5f24c1db1eb0452b90bf4af1ef5ffbce6cb8
The following methods no longer support Revision parameters:
- CategoryMembershipChange::__construct
- ContentHandler::getUndoContent
- DerivedPageDataUpdater::prepareUpdate
- DifferenceEngine::getRevisionHeader
The following methods were removed entirely:
- Title::countAuthorsBetween
The following methods return arrays that formerly include
a 'revision' key that would emit deprecation warnings when
accessed and return a Revision object. The Revision object
has been removed from the arrays, and the 'revision-record'
key should be used to get the relevant RevisionRecord instead:
- PageUpdater::doModify
- PageUpdater::doCreate
- Parser::statelessFetchTemplate
The ParserOptions `templateCallback` option is a callback
that is called in Parser::fetchTemplateAndTitle() and should
return an array - the 'revision' key to that array used to
be a Revision object and was used if no 'revision-record'
was returned - it is now ignored.
Bug: T247143
Change-Id: I163ada88d649c75697aff4fa31a3a3c0bdef78b7
- EditPage::$mBaseRevision
- EditPage::getBaseRevision()
- Title::getFirstRevision()
- LinksUpdate::setRevision()
- LinksUpdate::getRevision()
- Article::$mRevision
- Article::getRevisionFetched()
- WikiPage::getOldestRevision()
- WikiPage::getRevision()
- ContribsPager::tryToCreateValidRevision()
To make things easier, instead of rewritting
the Revision tests that were using WikiPage::getRevision,
just delete them, its not worth the effort to rewrite
them since the class is going away. For the WikiPage
tests, replace uses of getRevision with getRevisionRecord,
manually converting to a Revision object where needed
Bug: T247143
Change-Id: I52bc1f49649f8bd25797e3f7a090bec9c63ac2d1
Code performing edits should not need a full User object, a UserIdentity
should be sufficient.
This is an important step to enabling cross-wiki edits.
Bug: T275509
Change-Id: I357772799e82ea88b1b85b605f76ebefc19ebf21
As we convert the RevisionRecord to using Authority,
we no longer need Title instances, so we can convert
that to PageIdentity.
Ideally, we'd part away from using Title at all, but:
1. For foreign wikis PageIdentity has stronger validation,
so calling PageIdentity getId() on Title will break things.
There's still a lot of code depending on lax Title guarantees,
so we keep it.
2. A lot of code still depends on Title, so we try to pass it
through even if we don't nesessarily need to, to save cost
on recreating it later on.
Bug: T271458
Depends-On: I287400b967b467ea18bebbb579e881a785a19158
Change-Id: I63d9807264d7e2295afef51fc9d982447f92fcbd
This aims to persist the EditResult object associated with reverts
in the ct_params field of change_tag table for revert tags. This can
be later used for analytics or when performing a delayed
RevertedTagUpdateJob (see T259103).
The code doing that has to be in the RecentChange class, as only it
knows the relevant rc_id and rev_id.
Bug: T259733
Change-Id: I365cf44484aa5bf907128a075fcff890649504c4
Previously null edits were not properly marked in EditResult objects
provided by the PageUpdater. This change should fix it, by ensuring
the original revision ID is always set on the EditResultBuilder if
the edit is a null edit.
I've also added some code to test this, so we hopefully don't
encounter an issue like this in the future. :)
Bug: T257766
Change-Id: I04bb058c64483967617958d86aa40a67c31071cb
The name change happened some time ago, and I think its
about time to start using the name name!
(Done with a find and replace)
My personal motivation for doing this is that I have started
trying out vscode as an IDE for mediawiki development, and
right now it doesn't appear to handle php aliases very well
or at all.
Change-Id: I412235d91ae26e4c1c6a62e0dbb7e7cf3c5ed4a6
EditResult is an immutable object created during a page update by
the PageUpdater using a builder object, the EditResultBuilder.
EditResult is a container for information on how the edit
interacted with the page and previous revisions. It also aims to
provide a standardized way of describing reverts and reverted
edits. It is as simple as possible, with no dependencies on the DB
or global variables. Most of the logic is encapsulated in the
builder.
PageUpdater::getEditResult() replaces the following methods:
* getOriginalRevisionId()
* getUndidRevisionId()
They are both available in the EditResult object.
PageUpdater::markAsRevert() replaces
PageUpdater::setUndidRevisionId()
Bug: T254074
Change-Id: Ie04c38043d9c295552e488109436ec1df20bb2ca
Sometimes, an edit is done with a Title object that has gone
out of sync with the database after a page move. In this case,
we should re-load the current page ID from the database,
instead of failing the update hard.
Bug: T246720
Bug: T204793
Bug: T221763
Bug: T225366
Change-Id: If7701205ec2bf4d4495349d3e67cf53d32ee8357
Old hook PageContentSave only received the main slot of the article.
In order for extensions to intercept changes in all slots, they should
receive a RevisionSlots object with new content.
PageContentSave hook is still preserved for backward compatibility.
Note: parameters $iswatch and $section (from PageContentSave) are
not added into the new hook, because they are obsolete in the old hook.
Note: new hook also doesn't unnecessarily pass-by-reference (T193950),
which was an issue with the old hook.
Bug: T205982
Change-Id: I55455639c5ff6ccbf3917d85c1ab0dac847ec853
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
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 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
Trying to avoid resetting services introduces a lot of complexity and
several bugs. We were doing a reset for 70% of @group Database tests
anyway.
Instead:
* Reset services at the start of MediaWikiTestCase::run().
* Capture the actual original service container instead of making a
special shared service container.
* The test-isolated local service container can now only be initialised
non-statically. Revert the recent conversion of overrideMwServices()
to static.
* Store a reference to the local service container in the test case
object. In MediaWikiTestCase, always use the original or local service
container directly, to avoid confusion about which one is active at
the time.
* Remove a lot of unnecessary teardown
* Always call ServiceContainer::destroy() before forceGlobalInstance()
since the memory is not otherwise freed.
Change-Id: I4a17c1c7ec92c14e3bc471f0216473ebe19477b9
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
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
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
