This allows Special:ApiSandbox to display multi-line text boxes for
them, which makes testing the API easier.
Change-Id: I10541a8e9033d81740033da80d842f58d1d3e0de
Calling the linter is very slow as the result is not
cached. Extensions needing this (DiscussionTools) should
just call the Linter extension API directly.
Bug: T253799
Change-Id: I994b52ca70c29a32900741a36087f10144396720
The current default for Message::__toString() is to parse, so this
keeps that behaviour unchanged.
Change-Id: I528a60c1d9c0f8c1596a15e06a764200a2b2565f
This allows it to respect the proposed limit on HTTP request timeout.
Bug: T245170
Depends-On: I8252f6c854b98059f4916d5460ea71cf4b580149
Change-Id: I1c3d96720709253ad15bb8528cdd132571de2e4e
Goals:
* Allow other extensions to reuse these methods (maybe upstream them
to MediaWiki core later)
* Allow ApiVisualEditorEdit to extend ApiEditPage. We'll be able to
reuse its definitions for API parameters instead of duplicating
them, and we won't have to pass around unrecognized parameters.
Bug: T252573
Change-Id: If5c8d95560cbb078ae4980f4a912cbaeafe53d3e
We go through all this trouble to pass the config to the API modules,
and then we don't use it at all (we removed the uses recently in
ce094c72d and d85d30f9b).
If we end up needing the config there again, we can just get it by using
MediaWikiServices::getInstance()->getConfigFactory()->makeConfig( 'visualeditor' )
anywhere we want, like we do all over the place in VisualEditorHooks.
Change-Id: I9d254a9946f0d24783baf68c409b10291a8fd1b3
While we pretend that the ConfirmEdit CAPTCHA support is added by
ve.init.mw.CaptchaSaveErrorHandler in the ConfirmEdit extension,
we still have a bunch of code here required for it to work.
This commit removes some of it, no longer needed after
I6605017fd31a4f96c529dd0beb69e9f4433cebc1.
Depends-On: I6605017fd31a4f96c529dd0beb69e9f4433cebc1
Change-Id: I41e032fd754927b7ea6cfb767eb9f21b522ccacd
The client-side code sends the empty string as the value of this
parameter when the edit should be marked as minor, and doesn't set it
at all when it shouldn't (this is the normal convention for boolean
parameters). However, the API code here was incorrectly handling the
empty string, and not marking the edit as minor as a result.
This was revealed by 50883dd7fe. Prior
to that change the original 'minor' parameter was forwarded to the
action=edit call if it was provided, overriding the 'notminor'
parameter, which was effectively added unconditionally.
Bug: T248257
Change-Id: I37fd73851d94906d79943692fb9136da03ea95fa
Our client-side code doesn't use them, and they should not be needed.
ApiVisualEditor still returns those, and they are needed there; this
method used to be shared by both classes until 25afae342a.
ApiVisualEditorEdit still has 'basetimestamp' and 'starttimestamp'
input parameters.
Change-Id: I7108468df2ff20f05bd141cb617e4e0f90c027ce
This can lead to problems if the names in the VE API are
still used inthe Edit API, as previously happened with
`watch`/`watchlist`.
Explicitly list the parameters from VE API that were
previously getting passed to the Edit API automatically.
Change-Id: I8fe705b178af82d8285067909168d32cfb9a0421
The code for setting 'watchlist' in the EditAPI request
was completely broken as it always evaluated to 'unwatch'.
Instead pass through 'watchlist' directly from the client
where it must be set to 'watch' or 'unwatch'.
Bug: T245579
Change-Id: Ia5a2bb76ef35a685b39bcc0c4727796acd0f510d
It turns out anonymous users can't apply change tags, so change
I2c1d0f8d69bc03e5c1877c790247e165f160e966 broke editing for them.
Bug: T242184
Change-Id: I7c27e4d9995428e213a980819810f235fdfe9435
In the core MediaWiki editor, the detailed messages about page
protection are only shown when the user is allowed to edit the page;
otherwise, a generic permission error is shown. Do the same here.
Change-Id: Ia0ca52b9bf556354218b2aa91f141b429b0c5880
This opens up the API so that other tools can use it without being
forced to tag those edits as being from VE.
Also, document that tags is a working parameter that can be passed
through to the edit API.
Bug: T242184
Change-Id: I2c1d0f8d69bc03e5c1877c790247e165f160e966
Replace Title::userCan with PermissionManager::userCan.
Replace Title::getUserPermissionsErrors with
PermissionManager::getPermissionErrors.
Change-Id: I1afec4ba62185c3cd555a10ae35cef01b7194221
In many places we check whether VE is available before doing things
(init.isVisualAvailable). This variable includes checks for whether
the page is wikitext, etc. Now it will also include checking whether
VE is enabled in user preferences.
In almost all places where init.isVisualAvailable is used, we were
already also checking if VE is enabled, so this doesn't affect the
behavior. But notably, we didn't do it when showing the option to
switch to VE in the welcome dialog and in the toolbar, causing T243723.
Changing init.isVisualAvailable this way makes it consistent with
init.isWikitextAvailable, which has always included a checking whether
NWE is enabled in user preferences.
Bug: T243723
Change-Id: Ie174bc3f16bceb29cb155b9223e0acef70167fd6
* Query permission errors for 'edit' and 'create' in the same way,
and consistently with how MediaWiki core EditPage does it.
* Prefer using Title::getUserPermissionsErrors() instead of custom
code for user blocks. The result is the same, except for an extra
line like "You do not have permission to edit this page, for the
following reason:".
Note that this loses the 'type' => 'block' property on each notice,
which was previously used to track when a block notice was shown.
This was however removed in 96de1353d3,
and could probably be re-implemented by using the root 'blockinfo'
property anyway.
* When Title::getUserPermissionsErrors() returns multiple messages
(for example, you're blocked *and* the page is protected),
display them all in a list instead of only the first one, using
OutputPage::formatPermissionsErrorMessage().
That method returns wikitext, which we have to parse ourselves. This
is a bit silly, but I found this approach in SpecialChangeContentModel
in MediaWiki core, so it should be fine.
Change-Id: Ifaf95d8aab836e45665b1fbdf98dd1980a867d8c
The message ends with "The latest log entry is provided below for
reference:", but we were not providing it. Use the same code as
'protectedpagewarning' and 'semiprotectedpagewarning', which behave
the same.
Change-Id: Ibe5463aa3d93cd1d6d6e3c0b9da82bfa2c813f86
The following sniffs are failing and were disabled:
* MediaWiki.Commenting.FunctionComment.MissingDocumentationPrivate
* MediaWiki.Commenting.FunctionComment.MissingParamName
* MediaWiki.Commenting.FunctionComment.MissingParamTag
Change-Id: If59d450236a7d1afa3c6a05536abea819535f984
I'm not sure if this qualifies as an actual fix. I don't really know
what this code is supposed to do. Maybe the bad array access is a hint
for a completely different error somewhere else. All this patch really
does is silencing the bad array access.
This line of code was introduced with I1b35b28 in May already. Why does
it start failing now?
Bug: T240961
Change-Id: I5ec2dc453e5d8db5d2f9e49058eda001ed021d3d
I'm trying to track down possible values of 'result' for client-side
error handling and this was confusing.
Change-Id: I325249f7c57936c9c11a1d3dc9166b1ca3737c39
Follow-up to 57ad605dc4.
Pass parameters like when switching from wikitext editor:
* bodyOnly=false
* stash=true
Bug: T233320
Change-Id: Ied2d9a48e884e033ef9d41b2da9cfa3599784ae0
Previously we were not returning it, so when saving the edit, wikitext
syntax would not be preserved. This was probably not a big problem,
but I noticed it coming up in the logs for T233320.
Now making an edit starting with preloaded content behaves like
switching from wikitext to visual mode, rather than like starting the
edit in visual mode.
Similar to 679e777cfa.
Bug: T233320
Change-Id: Id1ee6877b103fa4274deec11b1b3cacbdcdae606
The configuration of Wikimedia wikis should be fixed.
This reverts commit 04407e9eb1
and also makes similar changes to new logging code added in
5d1a67757a.
Bug: T234564
Change-Id: Ic999b050e68b71f5a1737366e16f133e5a557307
Something is causing the 'ETag' headers produced by the "public"
RESTBase (queried directly from the client) to be mangled or lost.
My theory is that some proxy or browser extension is doing that.
When we detect a bad etag when fetching the page contents, discard
the result and try querying the "private" RESTBase via the MediaWiki
API (similar to what we do on private wikis, except there we talk
directly to Parsoid instead of RESTBase). After I463a84de63, that
returns the etag as part of the payload rather than HTTP headers,
and should pass unharmed through whatever is mangling the data.
Also compare and log the two etags.
Bug: T233320
Change-Id: I2ef0ca872597566f74b650aea71bf3f15747a6d7
For consistency, I guess. Also I need this in I2ef0ca8725.
Previously, when querying the HTML content of an existing page, we did
not return the 'etag', on the assumption that anyone who needs it will
instead query RESTBase directly.
Bug: T233320
Change-Id: I463a84de631598243893946ad1d060a9aa0b180e
The 'eye' icon is in the 'accessibility' pack, not 'alerts'.
Compare to the dependencies of 'ext.visualEditor.diffPage.init'.
Change-Id: Ie14ab6be756fd9e0bef59475466674a41273046f
No longer needed after Id36aa6bdb8f873fe7deb8123a7fc774103721c01,
which teaches SpamBlacklist to return its own error messages.
Depends-On: Id36aa6bdb8f873fe7deb8123a7fc774103721c01
Bug: T211443
Change-Id: I462c2002f9b596cbdfd7ce3673d4e362e5bd1aaf
Unnecessary suppression causes build failures. Probably fixed by the
EditPage.php changes in e2e543f7c2a98f40c9b43ba3989d0f6689f4cb67.
Change-Id: I2ac7e95886ce6bef2ba08e1614728caae7d26442
Context items can be created for specific template titles. Titles
are mapped to context items using an on-wiki message.
Bug: T211243
Change-Id: Icfc39e350452da238d0e0c17cb2305c60d9ca16a
New changes:
1a7460058 Remove ve.newMobileContext feature flag
Local changes:
* Remove ve.newMobileContext feature flag
Change-Id: Ia8def997b7cba4623866080752b06068d2118cc3
