I believe the more recent syntax is quite a bit more readable. The
most obvious benefit is that it allows for much less duplication.
Note this patch is intentionally only touching tests, so it can't
have any effect on production code.
Change-Id: Ibdde9e37edf80f0d3bb3cb9056bee5f7df8010ee
* Its not very clean to import Wikimedia\Stats in parsoid
* Mediawiki depends on parsoid
* As a workaround we can extract the 2 methods we need in SiteConfig
Bug: T354908
Change-Id: I696131cfba6ccc26ae1f705f216e221a7c3db175
The `supportsContentModel` method is really querying Parsoid for the
set of content models it supports, so it makes sense to put it in the
Parsoid-specific SiteConfig service.
This is part of the work to deprecate and remove ParsoidOutputAccess.
Change-Id: I81eb2df8cef93ede95361a4e03185b3d58e5b84b
I don't think these do anything with the documentation generators
we currently use. Especially not in tests. How are tests part of a
"package" when the code is not?
Note how most of these are simply identical to the namespace. They
are most probably auto-generated by some IDEs but don't actually
mean anything.
Change-Id: I771b5f2041a8e3b077865c79cbebddbe028543d1
There are a couple of user options related classes already,
and the T321527 work on dynamic defaults is going to add
even more. Let's move them into a separate namespace
to make core a bit more organized.
Old name is kept as an alias for compatibility purposes.
Bug: T321527
Bug: T352284
Change-Id: I9822eb1553870b876d0b8a927e4e86c27d83bd52
Remove parser creation from service creation
In ParsoidSiteConfig inject the ParserFactory and call getMainInstance
later, ParsoidSiteConfig is created often without calls to the parser.
For ParsoidDataAccess store the factory and call it when needed.
Bug: T343070
Change-Id: Ib3acadaf190383e4a8b3d266a9fd75c9b20c6649
Unit tests should not access the ExtensionRegistry singleton. This is
similar to how MediaWikiServices is disabled, but needs to be done
separately because ExtensionRegistry is not a service.
Make ExtensionRegistryTest use a mocked SettingsBuilder to avoid
triggering the exception when SettingsBuilder tries to access the global
instance of ExtensionRegistry.
Inject data from ExtensionRegistry into Parsoid's SiteConfig to keep
SiteConfigTest a working unit test.
Change-Id: I0a04c82250582fed7a66c1e10868d9b4f3823a28
wfParseUrl falls back to the global service locator as of I706ef8a5.
This will soon be disallowed in unit tests (see I5117eab9), and all the
classes updated in this patch are covered by a unit test that would then
fail.
SiteConfig already has a UrlUtils object available, so just use that.
In the other classes, there is no need to inject a UrlUtils service and
we can instead adopt parse_url, because these didn't depend on our
site-configurable or custom parsing logic. For precedent see also
change I6492f5142861513e4a7, I1e76d2f5aef, and lots of other examples
in Codesearch for parse_url().
The warnings about parse_url() in UrlUtils.php have been obsolete
since about PHP 5.4, when it started to support protocol-relative
URLs, non-slash protocols like "mailto", and deal with spaces/newlines
correctly (https://3v4l.org/YWUkl).
This patch was partly copied from PS 20 of I5117eab9.
Co-Authored-by: Timo Tijhof <krinkle@fastmail.com>
Change-Id: I98ea4670e842d11598664f058d8c90a900477be4
* SiteConfig::variants() was replaced by ::variantsFor()
* SiteConfig::langConverterEnabled() was replaced by ::langConverterEnabledBcp47()
Change-Id: I2dc510fcf0f03304f01c14cff92d5dd50736f062
This is now enabled in production (Ic5a4a9950d51f63b17f4c5e70516bec87b981aa5)
and not something we want to remain configurable.
It is removed from Parsoid in I52ddfd21ff2e72a34cb5eb68742e3dfb85c6ccf6
Change-Id: I6a4d7d33fb42270fc5da3a922aa0a959180fb33f
Just methods where adding "static" to the declaration was enough, I
didn't do anything with providers that used $this.
Initially by search and replace. There were many mistakes which I
found mostly by running the PHPStorm inspection which searches for
$this usage in a static method. Later I used the PHPStorm "make static"
action which avoids the more obvious mistakes.
Bug: T332865
Change-Id: I47ed6692945607dfa5c139d42edbd934fa4f3a36
It is very easy for developers and maintainers to mix up "internal
MediaWiki language codes" and "BCP-47 language codes"; the latter are
standards-compliant and used in web protocols like HTTP, HTML, and
SVG; but much of WMF production is very dependent on historical codes
used by MediaWiki which in some cases predate the IANA standardized
name for the language in question.
Phan and other static checking tools aren't much help distinguishing
BCP-47 from internal codes when both are represented with the PHP
string type, so the wikimedia/bcp-47-code package introduced a very
lightweight wrapper type in order to uniquely identify BCP-47 codes.
Language implements Bcp47Code, and LanguageFactory::getLanguage() is
an easy way to convert (or downcast) between Bcp47Code and Language
objects.
This patch updates the Parsoid integration code and the associated
REST handlers to use Bcp47Code in APIs so that the standalone Parsoid
library does not need to know anything about MediaWiki-internal codes.
The principle has been, first, to try to convert a string to a
Bcp47Code as soon as possible and as close to the original input as
possible, so it is easy to see *why* a given string is a BCP-47 code
(usually, because it is coming from HTTP/HTML/etc) and we're not stuck
deep inside some method trying to figure out where a string we're
given is coming from and therefore what sort of string code it might
be. Second, we've added explicit compatibility code to accept
MediaWiki internal codes and convert them to Bcp47Code for backward
compatibility with existing clients, using the @internal
LanguageCode::normalizeNonstandardCodeAndWarn() method. The intention
is to gradually remove these backward compatibility thunks and replace
them with HTTP 400 errors or wfDeprecated messages in order to
identify and repair callers who are incorrectly using
non-standard-compliant language codes in web standards
(HTTP/HTML/SVG/etc).
Finally, maintaining a code as a Bcp47Code and not immediately
converting to Language helps us delay or even avoid full loading of a
Language object in some cases, which is another reason to occasionally
push Bcp47Code (instead of Language) down the call stack.
Bug: T327379
Depends-On: I830867d58f8962d6a57be16ce3735e8384f9ac1c
Change-Id: I982e0df706a633b05dcc02b5220b737c19adc401
Fix documentation related to ExtraInterlanguageLinkPrefixes
configuration: it should be a list, not a map, and described usage
better.
In ApiQuerySiteInfo, third-party clients (like Parsoid) need to know
whether a given language link core corresponds to a deprecated
language code or a "real" one; the API was also missing information
regarding which language code an "extra language link" prefix
corresponds to (given by InterlanguageLinkCodeMap in the
configuration).
Finally, add the corresponding bcp47 codes for these interlanguage
links, so third-party clients don't need to know details of mediawiki
internal and deprecated language codes.
Change-Id: I82465261bc66f0b0cd30d361c299f08066494762
Previously, prior changes to the global UrlUtils instance could interfere
with testInterWikiMap() and trigger a BadMethodCallException exception in
UrlUtils::expand().
Bug: T297078
Change-Id: If75a91e33c5881244de388d203d0fc4879000f46
When creating ServiceOptions objects or fake HashConfigs use the
constant to refer the config name
Change-Id: I59a29f25b76e896c07e82156c6cc4494f98e64cc
createMock() does the same, but is much easier to read.
A small difference is that some of the replacements made in this
patch didn't use disableOriginalConstructor() before. In case this
was relevant we should see the respective test fail. If not we can
save some CPU cycles and skip these constructors.
Change-Id: Ib98fb06e0fe753b7a53cb087a47e1159515a8ad5
* Export nofollow and target settings in siteinfo API so that Parsoid's
developer mode of ApiSiteConfig works.
* Implement SiteConfig::getNoFollowConfig and
SiteConfig::getExternalLinkTarget, which are defined as abstract
in the parent class in Parsoid.
Bug: T186241
Change-Id: I6a1f12335be19509d4c5a17e2cae96ecdb677103
This reverts commit 5a9f0300e4573ce2a5f1b7869c9bdff2dc5d4708 on Parsoid
- that code has been moved to Core in the meantime.
Bug: T303029
Depends-On: 9b9ab2cdd6fd2dbb00e38f652b2856ca5860bffb
Change-Id: I34243250542785804ddf6c8210d22715ba9e91fc
* This is the first step of migrating Parsoid integration code into
core and transitioning Parsoid from an extension to a pure library.
* Parsoid already has conditional code to skip loading Parsoid's
copy of its classes, but it relies on the existence of ParsoidServices.
Technically ParsoidServices isn't needed once Parsoid is migrated to
core -- users can just use MediaWikiServices instead -- but we need
to temporarily add ParsoidServices as a marker class during the
transition.
This version of Parsoid's ServiceWiring comes from Parsoid commit
898c813fd832b3f2d7b5a37f60bd65e8368ce18f.
Bug: T302118
Change-Id: I0b388d93143a782c2c3b72e46407572e5c586e4a
