All code that used to live in ParsoidHelper has been moved to
VisualEditorParsoidClientFactory and VRSParsoidClient.
ParsoidHelper is no longer needed.
Change-Id: I21c4a8cd86f8d085e75a601ed6d2509dedd75d42
This makes the "direct" client and the VRS based client
implement the same interface, so the caller doesn't have to know
which one it is using.
It looks like ParsoidHelper will not be needed if we use this approach.
Change-Id: Ib1c1d7355951fc0765227dd01a9edfc554fc448d
In order to make this interface cleaner and not promote the
use of optional parameters when not needed, make the factory
required so that callers should worry about it and not overwork
the helper.
In this case, DiscussionTools extension is already using this
interface and has the factory injected appropriately.
Depends-On: If682af406c0fc7a9eca106eb3ebd95e6c14baddd
Change-Id: I836c0ad73687d8b99d1e067a5c3a3e512b4bd37a
Getting the correct client is now done via the VisualEditorParsoidClientFactory
so this is no longer needed. Follow-up of: I787c0afb227308aab56770d.
Depends-On: I4b9e7362a1bf1b4f224c8c652d40851a18c19824
Change-Id: I175aef2326a0d784fb8211542a3fe90cbf6c6d08
This patch introduces a factory service for creating VE Parsoid
clients.
NOTE: This patch also injects a GlobalIdGenerator to the client
and avoids usage of deprecated UIDGenerator class.
Change-Id: I787c0afb227308aab56770d14d62e08eb0084a6c
Follow-up to 951348dbbf. When creating a
new page on a RESTBase wiki, ETag is actually expected, but it will be
in a different format; the code comment was wrong.
Bug: T316969
Change-Id: Ia36488616ced70b900d2e67ce8e28993cc2c7514
While a missing etag on a RESTBase wiki still indicates a problem,
we worked around these problems long ago in T233320 and we don't
really care about the logs any more, and the logging is now dominated
by requests on private wikis where etags are not expected.
Bug: T316234
Change-Id: I4cc29847524863af2c5642cb60371893533a9df8
For error responses, the response body should be JSON containing a
'detail' key with a human-readable error message.
Remove old debug logging for T233320, it's no longer needed and it
stopped working on WMF wikis anyway (again, previously it was broken
due to T234564).
Change-Id: I64d0b934c90c7e9582e5433ae7a1b9ed2bc0c9a2
Introduced in FlaggedRevs with Idbdab9a7396 (6bfd276e64), and I've
migrated consumers away from the singleton in I192b962147 (5ee96e5ca7)
and I04fdbd497b8 (bbdfc4c024).
The one thing that remains global by default is the context, but
VE already avoids that with setContext, and (correctly) restores this
afterward since the FlaggablePageView object is re-used by title.
That's exactly as terrible as it sounds, but at least it's a bit more
visible after my refactor.
Bug: T314008
Change-Id: I0008818ec821c35c570d9db9c82f737783e6729b
We can simplify the code in Hooks.php to use revision.rev_actor
unconditionally, reverting 391c30da67
(the migration is done: T275246).
Bug: T312472
Change-Id: Iaab268409ec4ad0a8d3a835057321aa3c01a2cc7
ApiParsoidTrait depends on some ApiBase methods, which is inconvenient
when one wishes to access Parsoid HTML outside of the action API. Move
the bulk of the code into a new class ParsoidHelper, which doesn't.
Replace the uses of methods:
* dieWithError: throw a different kind of exception where it makes
sense, or change the method to return a StatusValue instead of
throwing where it doesn't
* getPageLanguage: use Title::getPageLanguage() or pass as parameter
* getConfig: pass to constructor
* getLogger: pass to constructor
* getRequest: pass the only required part to constructor,
leave some other API-specific code using it in ApiParsoidTrait
Bug: T314565
Change-Id: I90656cc74bb1cb1f2f3c82ad51cfb164cb8a4a4b
This is send as an associative array. Instead of adding elements that
are null we can just not add them.
Bug: T291729
Change-Id: I28d847941eec865cb255779534eca14ec88f588f
Before, permission editnotices didn't have access to the page titles, so
magic words like {{PAGENAME}} would give a subpage of Special:Badtitle. This
formats the message in the appropriate context.
Bug: T313372
Change-Id: I93894a4fc129de9da4b120c084b1d343b4021cdd
visualeditor-dialog-media-thumbdimensions
Added in 2014 via I7b4d019, but never used, as far as I can tell.
visualeditor-dialog-media-searchselect
Unused since I65aed34 from 2015.
visualeditor-dialog-meta-settings-displaytitle-enable
The feature was removed in 2017 via I46db6b1.
This patch also marks some other messages as being used via comments.
Change-Id: Ia10b6a5c0ea83dd670e2cfdbaa768c41fc0cf392
Remove WikiFilePage instance check, isLocal exists also on WikiPage and
newFromTitle never returns null
Bug: T297688
Change-Id: I925771a84afe4402fdb0f201c0b562c7028c44b2
Web team plans to deprecate the SkinTemplateNavigation
and SkinTemplateNavigation::SpecialPage hook. The
Universal hook can cater for both cases.
Bug: T255319
Change-Id: Ifad4918cf5d3d6b3f4d7abeb48d27fc5a46764b3
I suggest this as the first, most minimal step. This allows us to
slowly remove all the code that uses this flag without breaking
anything on wikis where the feature flag is not enabled. In other
words: this patch turns all code that expects this flag to be false
into dead code. We can then slowly remove said dead code.
Bug: T289049
Change-Id: I523978f7ca72dfc1cc7b64741e2f4f20ed3adfb7
Following the MediaWiki changes from T301203, we should use
the messages 'skin-view-edit' and 'skin-view-create' instead
of 'edit' and 'create'.
(Also remove redundant definitions in extension.json, we load
all messages listed in 'VisualEditorTabMessages'.)
Bug: T310529
Change-Id: If055fa2a4dc009be869425e6c2262c9b62056179
Extensions using Phan need to be updated simultaneously with core due
to T308443.
Bug: T308718
Depends-On: Id08a220e1d6085e2b33f3f6c9d0e3935a4204659
Change-Id: I9a20c25b9cea26e1fbe0f0434a0800632e9e0fc7
Visual Editor currently requests MediaWiki DOM version 2.0.0
when talking to Parsoid. Since Parsoid treats that as a request
for 2.4.0, its current version, and Parsoid doesn't have a
2.4.0->2.0.0 downgrade path, passing the latest Parsoid version
(2.4.0) should make no difference in practice -- but would better
match current reality.
Change-Id: Ia2bc0c1981db6f573a69fb1910cef4304c80ae00
Now that Parsoid's ServiceWorkers have been merged to core, this adds
support for "zero configuration Visual Editor" to the master branch.
Like earlier zero-conf work, this does not use RESTBase for stashing
or for reliable selective serialization. Future integration work
with ParserCache will reintroduce this functionality. Nevertheless,
this implementation should have feature parity with the "loopback interface"
zero conf VE we've been shipping since 1.35.
Bug: T305108
Change-Id: I7b5b4a6d16b07914f947cbaf498ad1d3cf2447a5
This ensures proper redacting, and consistent discovery and formatting
for Logstash queries.
Bug: T233342
Change-Id: I9a2a96793a5b7669648d222a0d472c15c09b84d3
This is needed because the $params array is then passed on to
ApiEditPage, so if the hook implementer wants to alter the data used
with the edit, it needs to be able to modify the $params.
See I494d72a42d9103c28c4d44077cfe0f1269fc7b00 for an example where
GrowthExperiments would like to modify the 'tags' parameter for an
edit.
Depends-On: Idd052281898f99e4f13f241d5633294b59b29329
Bug: T304747
Change-Id: Ia4842a1593028f5fa145de167ccf9b72efa81351
This also matches the current code in OutputPage::setPageTitle()
Depends-On: Ic864c01471c292f11799c4fbdac4d7d30b8bc50f
Change-Id: I018b34bb5f6e113056da9b04cc72d4318422adce
The button in the top-right corner says "Publish changes",
not "Publish page" (if you save an existing page).
Saving an existing page is more common then creating
a new one.
Change-Id: Ia9516932672820baa0344c77683836cc391cefc7
Depends on core changes I242e042317 and I6e9356a6cc to set the context
page for messages generated in Title::getEditNotices() and
LogEventsList::showLogExtract() too.
Set the context page for other messages whose overrides on Wikimedia
wikis commonly depend on it, which I checked using Global Search, e.g.
https://global-search.toolforge.org/?q=PAGENAME®ex=1&namespaces=8&title=Editingold
Depends-On: I242e042317a1e16c8d51edbf7800c8b7d70d468e
Depends-On: I6e9356a6cc3b9df9b508c3d37a0b9b75d6825efd
Bug: T300184
Change-Id: I0746618b1f6da3e5fd213d8adad9b1f4ec2fe23b
This allows nonexistent translated pages to fall back to the
corresponding page in a suitable language.
Bug: T299544
Change-Id: I43f461e9f595c364ecdaf2faccbd580fc0df6799
Passing the useskin parameter ensures that output hooks are run
on the new page HTML. This already happens because we request
the 'subtitle' and 'categorieshtml' props which also trigger
skin mode (along with the 'headhtml' which we don't request).
However it is better for us to be explicit that we want the rendering
for a specific skin, rather than relying on these props to trigger
the correct mode.
Also pass through mobileformat param, which is added by a hook
in MobileFrontend.
Change-Id: I1cd2c5c5c13ae0b90cc32e441b453532343a434a
We already had a query string hack '?visualdiff' to enable
the feature, but I think the pre-dated the diffmode param.
Now we have the diffmode param, we can just enable the feature
whenever diffmode=visual. This makes posting test links much
simpler.
Keepd the 'visualdiff' param for backwards compatibility.
Change-Id: If777d7f2e6a3b1a1725f174d149cf9eab4535d85
Parsing it in the RL module caused the module cache key to depend
on the parse, which is slow and makes ResourceLoader sad. The usual
approach for solving this (I206bb05d28) can't be used, because of
how EditPage generates this message.
Bonus #1:
Generate the message for the correct page title. MediaWiki allows
customizing it per-namespace or even per-title, which we haven't
supported before.
Bonus #2:
Pass the context for message localisation (depends on I5f7c77970d).
EditPage::getCopyrightWarning() was parsing messages without the
interface flag, causing some needless processing elsewhere.
Depends-On: I5f7c77970d0525c0ff394f8bd72c69dcb5d00623
Bug: T298822
Change-Id: Iaa626f0e6379a5a370f9c465cea8528bb5bde7f7
The global function wfReadOnly() has been deprecated in favor of the
new ReadOnlyMode service. Its usages should be replaced.
Bug: T283978
Change-Id: I26a878f19be5c90dab04e28ce395cb8f6dddebef
Other wikis with this setting only worked correctly, because the
wikitext editor was the default one anyway.
Bug: T296269
Change-Id: I58057320231471bc55d1e1b2fdfd0af55777c536
Remove using of User:getOption since this method will be hard-deprecated. Now it is soft-deprecated
Bug: T296083
Change-Id: Ic177a170fd3c72ebbb80da60dc8597285ab5e023
Replace User::isBlockedFrom with PermissionManager::isBlockedFrom since this method will be hard-deprecated.
Bug: T294823
Change-Id: Iea308ce73e4e91b21f55b60e0b3251d93ba18d7e
After filtering the PHP array to only include the ids
of namespaces with subpages enabled, add an array_values()
call so that the ids are again indexed numerically beginning
from 0, which is needed for the array to be passed to the
JavaScript as an array rather than an object.
Bug: T293310
Follow-up: Ia0ecac71721eceed52cc90f39ecc560bdf1b7f9b
Change-Id: I45bb281314caf5da0b7836829eb44f858836566f
Instead of using an object mapping namespace ids to if they have
subpages enabled or not, pass an array of the namespaces where
subpages are enabled, reducing the size of the configuration that
gets loaded on all requests. Only requires a minor update to the
JavaScript that uses the value (check for array index instead of
object value).
Bug: T291729
Change-Id: Ia0ecac71721eceed52cc90f39ecc560bdf1b7f9b
For readability. The current implementation is a sequence of
7 (!) array_…() function calls. It is also not free from bugs.
If one of the two inputs (ExtensionRegistry and Config) specifies
namespaces by e.g. canonical name, but the other by number,
the two are not properly merged. It should be possible to use
configuration to disable a namespace that would otherwise be
enabled. This currently works only if both use the same array
keys.
Bug: T291727
Change-Id: I2671f391cdc510da21eda8a1dc5ed4d2513a378a
$wgNamespacesWithSubpages can include namespaces that
don't exist, no need to add them to the JavaScript configuration.
Bug: T291727
Change-Id: I1f4f3d2c2accb3d84f83262480616d05115f406c
The code that uses it is commented out
Bug: T291729
Follow-up: I7af2bc91524e832555b66f090a671672cd14f294
Change-Id: I4cceb9ca83a2274fa93783af3608b9486b773522
This was removed in I44ee0014ac50c9c5dc66543dcd045dd5a81ce37c.
This basically partly reapplies I844db115f2563cb9ee1629c30d5f49d1ce58f5bd.
Bug: T289730
Change-Id: I14435b9f84b9a24445befbb8dc7fefce44bba078
Specifying it as such creates a 0 based index for what is a single value
property. This wasn't noticed before because I6b81ea318f52e accessed the
request object directly instead of using $params. See also
I3baa1ebb66559 for how this bug manifested in GrowthExperiments.
Bug: T289652
Change-Id: Ife8350d1cea79fc1dd6f3cb040a7801b9fe6db91
What:
Add a hook that runs before a save attempt is made in
ApiVisualEditorEdit. The hook receives the same data available in
ApiVisualEditorEdit, and implementations of the hook can modify the API
response.
Why:
VE plugins may send additional data when saving an edit, and extensions
might want to prevent the save from taking place based on that
additional data.
See for example the AddLink plugin in Ic8225933c9, where the save is
blocked if link suggestions don't exist in the database at save time.
Bug: T283109
Change-Id: I6b81ea318f52ec47661086d85b5cc242a3fcd0e4
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
This allows using the config variable independendly from the cirrus search extension.
This way it can be used for all subtickets of T271802.
Bug: T277028
Change-Id: I1b3bdda5fa6fbfe5c531c3b51c2c8e2a28ed1faf
What:
Add hook that runs after a save attempt is made in ApiVisualEditorEdit.
The hook receives the same data available in ApiVisualEditorEdit, and
implementations of the hook can modify the API response.
Also introduce templated
parameters (https://www.mediawiki.org/wiki/API:Templated_parameters) in
the API parameters; this allows plugins to pass arbitrary data along
with their request using e.g. plugins=linkrecommendation&data-linkrecommendation=foo
Add ServiceWiring files, a PHP namespace, and a HookRunner class to
support the above changes.
Why:
VE plugins may wish to send additional data when saving an edit and take
action based on that data on the server-side. See for example the
AddLink plugin in I7a052f8e which sends annotation data, and then uses
the new hook to perform a database operation.
Change-Id: I392691475fbdcec766acbd832600e82efcb5bfe8
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
User::setOption() is deprecated and should be replaced with UserOptionsManager::setOption()
Bug: T277818
Change-Id: I7395a8620064dcbe019b92feba17d9c9996ffbb7
Remove using of User::isIP since this method will be hard-deprecated. Now it is soft-deprecated
Bug: T275602
Change-Id: Ia625be523706d1e24649f7aa15679491f9598b7f
The failure was:
includes/VisualEditorDataModule.php:37 PhanTypeMismatchArgument Argument 2 ($pretty) is ResourceLoader::inDebugMode() of type int but \FormatJson::encode() takes bool|false|string defined at ../../includes/json/FormatJson.php:115
includes/VisualEditorDataModule.php:41 PhanTypeMismatchArgument Argument 2 ($pretty) is ResourceLoader::inDebugMode() of type int but \FormatJson::encode() takes bool|false|string defined at ../../includes/json/FormatJson.php:115
Probably triggered by changes to MediaWiki in commit
Ieaf04e0c289646dd5d5b027b4f1f8278167b2d57.
Change-Id: Iab139c4dd69c9a16c9f4f9e2fd47ec76a9003152
If someone has edited before the switch (2016-ish), never edited since
then, and try to edit again now, it's probably no longer helpful to
show them a popup dialog about a change that happened 5 years ago.
The immediate motivation for this, though, is T273189. We discovered a
bug with the preferences that, among other issues, caused this dialog
to not be shown in some cases where it should have been, and fixing
the bug now would cause it to be shown the on the next edit attempt.
If someone has edited before the switch (2016-ish), *and* edited since
then, and try to edit again now, it's definitely not helpful at all to
show them a popup dialog about a change that happened 5 years ago.
Bug: T273189
Change-Id: I4b5a3d8dbdf1c853eb39fcfc85a9fe87a4db0f21
We have two preferences used for enabling/disabling VE:
'visualeditor-enable' and 'visualeditor-betatempdisable'.
(And 'visualeditor-autodisable', which sometimes overrides
them both, but it's not relevant here.)
The user can only set 'visualeditor-enable' when VE is Beta Feature,
and they can only set 'visualeditor-betatempdisable' when it is not.
However, when deciding if VE should be loaded, we always checked both
of the preferences. This gives incorrect results when the preference
that is not supposed to be settable actually exists, due to being set
in GlobalPreferences on another wiki where it's settable.
A similar issue could occur if VE configuration is changed from Beta
Feature to a normal preference (or the other way around), and the
preference values for the previous configuration still persist.
Bug: T271434
Change-Id: I7399b3c516f762429050a662ac85d1d392392323
Depending on the config, we would sometimes define both the
'visualeditor-enable' and the 'visualeditor-betatempdisable'
preferences, even though they contradict each other.
Bug: T273188
Change-Id: I6ac7e4580bf232a5198ad8842f814bc381131e00
* VisualEditorNewAccountEnableProportion
* VisualEditorAutoAccountEnable
Seemingly never used on Wikimedia wikis, and untested since 2016.
Bug: T273177
Change-Id: Ic132ef2091399fd223626ae307830f278e72ec01
This name is consistent with T91820.
Bug: T91820
Bug: T259685
Depends-On: I0c4ec63bb26641b237c92dbd3bc5367811ca0675
Followup-to: 3561167493
Change-Id: I4c4c5f83ad56a198d08095d629a6ba86ce9dc1a4
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
