Make private the methods only needed
in the class (and tests), no need for deprecation
because they are not used in any extension per
codesearch. Remove EditPage::setPreloadedContent
entirely, since it is unused.
Bug: T252907
Change-Id: Id47421e01da51d57842390682ace2c33eec3b467
Add
- ContentModelChangeConstraint
- EditRightConstraint
- ImageRedirectConstraint
- ReadOnlyConstraint
- UserBlockConstraint
- UserRateLimitConstraint
Additionally:
- Split EditPageTest into a separate file for
all of the constraints being tested
- Add a helper EditConstraintTestTrait
- Add debug logging for EditConstraintRunner for
the result of each constraint
- Changed the order of some of the checks, which
may result in a different failure code if multiple
checks were going to fail, but shouldn't change the
overall result of whether an edit fails or not.
Bug: T157658
Change-Id: Ib8f8b62b9928544e5559c96d82bf850dd8cf9b05
Factory is a service in ServiceWiring, given the number
of dependencies that will eventually be needed, but is
internal and has no corresponding method in MediaWikiServices
Bug: T157658
Change-Id: I801a09f5133bed14da10c64a42ca0658024357d3
Rather than reading from $GLOBALS for
individual tests, set the user to a test user
Keep writing to $wgUser via setMwGlobals
for now.
Bug: T243708
Change-Id: I8935c18f4a0bda704eaf752683ab7f510f1ed3cb
When watching via action=watch, there's no need to
save if nothing has changed. This is already how
EditPage does it (by calling WatchAction::doWatchOrUnwatch())
so this change emulates that and also calls
doWatchOrUnwatch() when saving the watch item.
The format that's used in the expiry dropdown (in action=edit
and action=watch) is also changed to ISO8601 so that it
includes a timezone specifier and removes any ambiguity about
what timezone it is in.
The minor change to $changingWatchStatus is just to keep it as
a boolean and not turn it into an int.
Bug: T260009
Change-Id: If94ea7394588646abdac9a5025b0c8903366b521
Production error reported in T161199 was caused because of some bug on
how section edit support is checked in EditPage.
When we attemt to edit a section of any page; isSectionEditSupported()
method is called to check whether the content model allows that. If it
doesn't, an ErrorPageError is thrown and that's the end. However, the
method flaw is that it only checks the content model of the page's title
which is equivalent to the model of the latest revision.
But ealier page revisions now may contain different content models from
the latest revision.
If a page's current CM ALLOWS section edit and one of its older revisions
has a CM that does NOT ALLOW section edit, attempting to edit any section
of that old revision will lead to a call to the isSectionEditSupported(),
which will now return incorrect truthy result based on the current page's
content model that allows section edit.
This will lead to a call to getOriginalContent() which returns content of
the revision. Attempting to extract content of a section from that will
return null and the null is retained as the return value of getContentObject().
Since the old revision and current revision have different CMs edit will
not be llowed, to explain this, a call will be made to displayViewSourcePage()
method which is typehinted to require Content as the as its first argument.
So because of the bug null will be given to displayViewSourcePage() instead of
Content and that will lead to the TypeError that was reported in T161199.
The initial and simple solution to this bug is to just fix the method to ensure that
it checks both content models of the title and the relevant fetched revision
which will ensure correct result for section edit support is returned.
But later it was pointed out by Anomie that editing section of oldrevision
is not something that was intentinally designed to be so. In fact it was
disallowed from the UI because of its consequence, but it was not enforced
technically. Task T251680 was created to explain this in more depth.
This patch;
* Section edit support is changed to require, in addition to the content
model allowing so, that the revision to be edited be current revision.
* Section editing on non-current revision is already superficially
disallowed as there's UI button to reach that patch. Even the initial
reported bug couldn't have happened or be reproduced any UI means except
by directly playing with the URL
* This will automatically resolve the original bug that led to the error and
enforce what has been already disallowed.
Bug: T251680
Bug: T161199
Change-Id: I05ca6ac90509deec51bf38ec98e9aef169d87459
This adds new functionality to allow non-checkbox widgets to be
used in the checkboxes row of the edit form, and adds a dropdown
widget for the watchlist-expiry field.
Bug: T248494
Change-Id: Ice5113a97b1ef97253bfa6874ea71d910a5cd8fd
This adds a baserevid parameter for detecting edit conflicts, as an
alternative to the less precise basetimestamp parameter. This is
introduced for parity with and use by the new REST api.
Bug: T230843
Bug: T34037
Change-Id: Id7565018f66860b5c2ba688777508db1b88700ae
assertSame() is guaranteed to not do any type conversion. This can be
critical when acciden tially comparing, for example, 0 to 0.0.
Change-Id: Iffcc9bda69573623ba14af655dcd697d0fcce525
T208768 introduced the PermissionManager service that can now be used
for page specific permission checks. This change replaces calls to
Title::userCan() with the new service in the EditPage class.
Bug: T220191
Change-Id: I835d68d6c47785cf35386bca0431907fee87f0c1
This avoids error-prone code written separately in every test. In
addition to no existing tests resetting the TitleFormatter (more
services probably need to be reset as well), they mostly reset only the
namespace cache on $wgContLang, which wouldn't help for any other
language.
The parser test runner still doesn't do this, but maybe it should.
Change-Id: I44b7a1aec48f14b0950907fa14bd0df80f674296
This changes behavior in some tests by making them set $wgLanguageCode
as well as $wgContLang, but that seems like a good thing.
Bug: T200246
Change-Id: I936888f46ff9fefe2707efba837e2ce3a7ca5e3f
MWNamespace has three internal caches, only one of which can be cleared
(and that somewhat oddly by passing a boolean to
MWNamespace::getCanonicalNamespaces()).
This change introduces a MWNamespace::clearCaches() method to clear all
three caches. It also adds some resetting in tests that seemed to be
missing it.
Change-Id: I1dcfcd8713888b3ff8fc75e95329ba72bd95d0c9
Get rid of the hack that turns unicode into hexadecimal codes for
browsers that don't support unicode, and prevent their edits entirely.
And instead of relying on $wgBrowserBlacklist, use a hidden HTML form
field - if the contents are mangled and don't match the original, then
reject the edit.
Bug: T67297
Change-Id: I20c2e396d7dfd6a3b23b94b218f94a847522576b
It's unreasonable to expect newbies to know that "bug 12345" means "Task T14345"
except where it doesn't, so let's just standardise on the real numbers.
Change-Id: I46261416f7603558dceb76ebe695a5cac274e417
* Also make ErrorPageError exceptions display themselves
in PRESEND mode. Before they were always suppressed.
* Make DataUpdate::runUpdates() simply wrap
DeferredUpdates::execute().
* Remove unused installDBListener() method, which was
basically moved to Maintenance.
* Enable DBO_TRX for DeferredUpdates::execute() in CLI mode
* Also perform sub-DeferrableUpdate jobs right after their
parent for better transaction locality.
* Made rollbackMasterChangesAndLog() clear all master
transactions/rounds, even if there are no changes yet.
This keeps the state cleaner for continuing.
* For sanity, avoid calling acquirePageLock() in link updates
unless the transaction ticket is set. These locks are
already redundant and weaker in range than the locks the
Job classes that run them get. This helps guard against
DBTransactionError.
* Renamed $type to $stage to be more clear about the order.
Change-Id: I1e90b56cc80041d70fb9158ac4f027285ad0f2c9
A few semantic changes result from this:
* If multiple pages are edited in a request, the updates happen
in the same order relative to each other, but all in one second
step instead of after each page edit.
* If the same page is edited twice in a request, the WikiPage hook
argument will reflect the last request edit, not always the edit
that fired the hook.
Bug: T120718
Change-Id: I9429f29e5a90f24e4d7af5797a80e63a9cc34146
This method actually marks the test it is called
from as skipped if Diff3 is not confugured.
The new name "markTestSkippedIfNoDiff3" better
reflects that.
Change-Id: I1dffeba0aceb312b3a82216f0b55227e24bc2e34
A few semantic changes result from this:
* If multiple pages are created in a request, the updates happen
in the same order relative to each other, but all in one second
step instead of after each page edit.
* If an extension set some extra Status info or errors via the
PageContentInsertComplete hook, they will not be seen by the
caller (unless it was a CLI script possibly). Few callers use
$status at all, and I did not see any that mutated it. Since
the page is already committed when this hooks run (as has always
been) they cannot veto edits and callers do not care or know what
to do with random hook-set status errors; there was never much use
in changing the Status anyway.
Bug: T120718
Change-Id: Ieba35056be31b2f648c57f59d19d3cbbe58f1b05
This adds supportsDirectApiEditing and
supportsDirectEditing methods to ContentHandler. Both
return false by default for the ContentHandler base
class, and true for TextContentHandler and it's
derivatives. (everything in core)
Extension content types that directly extend
AbstractContent / ContentHandler, often / generally don't
support direct editing. EntityContent in Wikibase
and Flow boards are the two such content types currently
in gerrit-hosted extensions.
The use and direct settings of the allowNonTextContent
member variable is replaced by enableApiEditOverride and
a setter for that. The only place allowNonTextContent is
used in all of Wikimedia-hosted git repos is core itself
(EditPage and ApiEditPage), so should be safe to make
this change.
With this change, Wikibase can remove its ApiCheckCanExecute
hook handler that disallows editing there, and MobileFrontend
could check if direct editing is allowed before enabling it's
editing features, instead of Wikibase having to add
MobileFrontend hook handlers to disable the features.
Bug: T96382
Change-Id: I276cd6ecedf38108f1f2be16b38e699e8c5d2d0c
Follows-up b36d883.
By far most data providers are static (and PHPUnit expects them
to be static and calls them that way).
Most of these classes already had their data providers static
but additional commits sloppily introduced non-static ones.
* ResourceLoaderWikiModuleTest, 8968d8787f.
* TitleTest, 545f1d3a73.
Odd unused method 'dataTestIsValidMoveOperation' was introduced
in 550b878e63.
* GlobalVarConfigTest, a3e18c3670.
Change-Id: I5da99f7cd3da68c550ae507ffe1f725d31e7666f
This change enables the direct creation of empty pages without needing
to use a work-around (such as "{{subst:ns:0}}"). A warning is added as
the message "blankarticle" to request confirmation that the empty page
was meant to be blank. A automatic edit summary has been added when
creating a blank page. The message is: "autosumm-newblank."
The API has been updated to permit the creation of empty pages, when
"text" is null, but not non-existant.
Unit tests have also been added to test these features.
Bug: 57238
Bug: 65206
Change-Id: I3457c36a909d1dbfaeed04a1f0568c69e0ef3386
