All code that used to live in ParsoidHelper has been moved to
VisualEditorParsoidClientFactory and VRSParsoidClient.
ParsoidHelper is no longer needed.
Change-Id: I21c4a8cd86f8d085e75a601ed6d2509dedd75d42
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
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
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
Replace User::isBlockedFrom with PermissionManager::isBlockedFrom since this method will be hard-deprecated.
Bug: T294823
Change-Id: Iea308ce73e4e91b21f55b60e0b3251d93ba18d7e
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
This was removed in I44ee0014ac50c9c5dc66543dcd045dd5a81ce37c.
This basically partly reapplies I844db115f2563cb9ee1629c30d5f49d1ce58f5bd.
Bug: T289730
Change-Id: I14435b9f84b9a24445befbb8dc7fefce44bba078
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
