These don't add any knowledge but make the code harder to read
and maintain, and are an additional source of errors.
Change-Id: Ied57741a3f985e355adfddb4e75378d5c497faa9
* Mismatching capitalization.
* Unused pieces of code.
* Properties that can be constants.
* Use $this->getConfig() in special pages.
Change-Id: Ia7e2c438c5ddd3c770070701e4cbdfc79fccf009
Otherwise, the global context is used (RequestContext::getMain()),
which is undesirable when you're building a rubegoldbergian
contraption and we're already inside an internal action API request
with a fake context.
Change-Id: I66e79e641eda185f7af2561d3655c92cba762135
Applying the changes from the MediaWiki core patch for T120883
(Ife272a0eb1f3322bc8eb30ca803bd21801acba3e) to our duplicated
code implementing the same functionality.
Bug: T270453
Change-Id: I1b2de322aa0c69eb6d3b3ffadaed3fbaa3a58bca
Remove using of User::isIP since this method will be hard-deprecated. Now it is soft-deprecated
Bug: T275602
Change-Id: Ia625be523706d1e24649f7aa15679491f9598b7f
A couple of things make this quite a simple change:
* Most messages are generated from a single message key
* $title->getEditNotices() already returns an array
keyed in the same way, we just currently flatten it.
* The VE client already flattens the array immediately
in ArticleTarget#parseMetadata, so no change required.
* PHP preserves the order in which keys are added, not
that notice order is particularly important.
This partially undoes c824dc383a,
which changed the format from a mixed array to an indexed array.
Bug: T272188
Change-Id: I646667fe2513e371e0c8270761553253d1abe2b6
isRegistered is part of the slick UserIdentity interface, i.e.
it's the more "canonical" form. This change makes it a bit
easier to move away from using the huge (4000+ LOC) User class
everywhere, in favor of the UserIdentity interface, where
possible.
This patch is meant as a small step towards this goal. I tried
to replace some usages of User type hints already, but prefer
to go in small, incremental steps.
Change-Id: I827b83a5304b1975437d5fd5083f2877dba6f6d8
The hook should work now.
I tested it manually and preloading with extensions works fine.
Preloading the default text for system messages is fixed as well.
Bug: T266404
Change-Id: Icf40112bd5fabf24452f9b807b388399c7c920f0
getDefaultMessageText() returns false when the message doesn't exist.
It was incorrectly treated as a string by this code.
Follow-up to 3ec5e04a37.
Change-Id: Ib94a30697bd20133e46cbd31c14caf5f0c4169dd
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
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
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
Replace Title::userCan with PermissionManager::userCan.
Replace Title::getUserPermissionsErrors with
PermissionManager::getPermissionErrors.
Change-Id: I1afec4ba62185c3cd555a10ae35cef01b7194221
* 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
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
Unnecessary suppression causes build failures. Probably fixed by the
EditPage.php changes in e2e543f7c2a98f40c9b43ba3989d0f6689f4cb67.
Change-Id: I2ac7e95886ce6bef2ba08e1614728caae7d26442
There are various circumstances where the wgIsProbablyEditable check
gives incorrect results (hence the 'probably'):
* User is blocked (T111217)
* Page is protected from creation (T173763)
* Page is transcluded on a cascade-protected page (T217217)
Bug: T111217
Bug: T173763
Bug: T217217
Change-Id: I7df8909c31f29d2e7521bef8612c27cb61146a4d
Use an API 'parse' call with a sectionid to trigger
a full document expansion using replaceSectionAtRev.
Then send this off the RESTBase to convert to HTML
and statsh.
Ensure the etag is passed back to the API response.
Bug: T117716
Bug: T223023
Change-Id: I1b35b28e428a1f86d2e34d90ddbe73361ce14818
This is necessary to allow the unmitigated removal of
ApiQueryUserInfo::getBlockInfo to be fixed. See discussion on
I84ed21641c44b2f65.
Change-Id: I9f40666a31bd4af50762c197c2ce5bf089a5e68c
The method ApiQueryUserInfo::getBlockInfo() was removed in unannounced
breaking change in MW core: I84ed21641c44b2f65ebe1980b0893d1846db3b34.
Apparently we're supposed to use the method from ApiBlockInfoTrait now.
Bug: T209599
Change-Id: I7ab5492310980b1527c7329faf65655330b8bef0
RESTBase is changing the way it is storing HTML/data-parsoid renders. In
order to still support VE (and other editors) with quick access to HTML
and matching data-parsoid (needed later for transforming the modified
HTML to wikitext), VE now needs to let RESTBase know it intends to
perform a transformation call later on. In that case, RESTBase will make
sure to keep the matching data-aprsoid around for long enough.
Bug: T222639
Change-Id: I02672e29bd0f331794fd77d9e56f9cc6822d9b9e
Mobile builds its own block message from the block information,
rather than using parseAsBlock.
Bug: T209599
Change-Id: I8b200f258b50f7048aded22ec7ab81a49937c5a9
This is a clean up after collecting the necessary data related to
blocks and how often users see the block notices
See: https://phabricator.wikimedia.org/T189724
Bug: T214214
Change-Id: I532a0cd95009109ba25caa8dd31badd5c1900da7
When this code was written in 2013 (1a5bdd5bd2),
the langlinks API did not have a way to return the language names (autonyms).
This has been added in 2014 (4ba3a9aea96ee21c035c69999be23580e23f4e0a).
Change-Id: I70edb846d94b1108b079caf5915532234190da8f
Generating the templatesUsed list is relative slow, and is only
used in an obscure part of the editor, so only generate it when
needed.
Bug: T209078
Change-Id: I1cecdad65b80c4c9b1746e752ea4b41bc0fc0037
Red-link metadata was added to Parsoid 18 months ago.
On long pages evaluating this information is very slow
(hundreds of milliseconds) and completely redundant.
Bug: T64803
Bug: T209078
Change-Id: I5b6c6da588301ed59fb21e1ce930f5b72db48e67
Show log extract if the user is sitewide blocked or is partially
blocked and not allowed to edit their user page or user talk page.
The check on the block type is being added to keep it in sync with
what it is currently being done on core.
Bug: T203171
Change-Id: I00ebb5cbcb1ec14e778c2936187cbcebc0829163
* Also make sure block notices have type 'block'.
* Remove old flag for tracking since we'll be using one
from core
Change-Id: I4b66e73c8a4c4dd7bffd7c0239b1d5ec06eed12f
Depends-On: I6bd1c95548616677e1f72ba6bcfc6f2b551c1ca6
Tracking is behind $VisualEditorTrackBlockNotices config flag
which is set to false by default. Additional data will be logged
into a different bucket on the client and both metrics will be
considered with their known limitations.
The reason behind this is to get an idea on how frequently blocked
users attempt to edit a page. Similar tracking is being added to
MobileFrontend and mediawiki/core.
Bug: T201718
Change-Id: I51576276b97be0716c2c22348eaa756ffb04fe50
Our behavior is now closer to the core wikitext editor.
This results in two minor changes:
* `<li>` elements are now correctly wrapped in an `<ul>`.
* "View full log" link is now only shown if there are more entries.
Change-Id: I3f30446fca5cab83155ce26ee4e5ab213fc5847a
