As found via the test added with I3609cc71de48d3f5, which fails
without this change, and is enabled now in this patch.
Change-Id: Ie536644084b8a8b5386eb013cfd54621cfabc52d
* Skin constructor docs were unreadable on doc.wm.o and in other
places and IDEs that display docs due to lack of formatting (line
are just whitespace in Markdown, same as HTML).
* Make some of the method briefs (first line separated by new line)
more useful, especially where this brief was missing and thus
rendered unhelpful text like "Returns array of:" with no more.
* Misc grammar and typo fixes, consistent phrasing, and other minor
points from code conventions. Changed a few "fetch" to "get" in
trivial methods.
* Found a bug in SkinFactory::register() regarding skipskin handling,
will fix in follow-up.
* Found a bug in Skin::buildSidebar() regarding insufficient cache
fragmentation. Will fix in a follow-up.
Change-Id: I3609cc71de48d3f5c8404ea834d42c0cec5cba59
The existing method of hardcoding ApiOutput and Fallback is not
great, and there is a use case inside Vector as we split
Vector skin into two as well as inside ContentTranslation.
This adds to the existing wgSkipSkins configuration by allowing
skins to register themselves as skippable without a LocalSettings
change.
Bug: T291193
Change-Id: I9caa8deb5b58fa1ef1eb548db497ef095cbbd154
- Add Skin::getOptions and Skin::getPortletLinkOptions, which are used
to provide skin options to mw.util.
- Add SkinFactory::getSkinOptions, which is used by
Skin::getPortletLinkOptions.
Depends-On: Ib23360e3439abc828404c1de8e0906915ee7d8b6
Bug: T289163
Change-Id: I801e7d583cb0b0c7da51f4da503268be736bb60c
Since $wgSkipSkins is meant to only 'remove skin from preferences',
it should not affect parsing with them.
So these skins need to be allowed here.
To achive this, this patch adds getInstalledSkins() method to SkinFactory
to provide the complete. The method supersedes getSkinNames() which does
the same thing but with ambiguous name.
Description of getAllowedSkins() has been corrected as it was slightly incorrect.
Bug: T237856
Change-Id: I0889b823d27f1a2830cc0205f5a21ed4de744e08
In all these cases the property is unconditionally set in
the constructor. The extra initialisation is effectively
dead code and an extra source of errors and confusion.
Change-Id: Icae13390d5ca5c14e2754f3be4eb956dd7f54ac4
* Move the method to SkinFactory and replaces usages.
* Inject $wgSkipSkins into the SkinFactory
Bug: T257993
Change-Id: I9869cf34c5e87cbad963f48db0649b3b7a252a4a
The new SkinMustache class is based on the emerging class in Vector.
Having this in core, will allow Vector to make use of this class
immediately and provide a minimal generic mechanism going forward
for rendering skins using Mustache. For now, I've fleshed out the minimum
possible data in getTemplateData which are based on existing functions in
Vector.
The Skin class now takes a generic options parameter which allows
registration of a skin using the SkinMustache class with a templateDirectory
option pointing to the associated template. A `styles` option can be passed
to define stylesheets that should be associated with the skin.
The SkinApi and SkinFallback classes are reduced significantly.
There are no known uses of SkinApiTemplate and it is thus removed.
SkinFallbackTemplate is removed and its functions copied across to
SkinFallback
End user changes:
* The fallback skin no longer prints the confusing warning message if the default
skin is setup incorrectly. Previously viewing the fallback skin with useskin
indicated that wgDefaultSkin was not set correctly which was misleading and confusing.
* Factory functions now receive skin options as a second parameter and the service as a
first - this is due to how ObjectFactory handles the extraArgs key for 'factory' key
- placing it at the beginning.
Bug: T254048
Change-Id: Ibbabd1d0f26efebf8f8ff068966685dc2191c527
This data is the same as the 'credits' data that is already compiled,
cached and made available via ExtensionRegistry.
Similar to various other configuration variables previously, the
$wgExtensionCredits variable is now also required to only be used
for providing input to the system (e.g. from LocalSettings.php,
or from legacy extension PHP entry points). It is no longer
supported to use this variable to reliably read out a full view
of all extension credits (specifically those registered via
extension.json).
Doing so had the downside of adding processing cost to every
web request, as well as taking one the single largest portion
of the ExtensionRegistry APCu cache key, which in PHP7+ incurs
a linear cost for every string value, string key, of every
(sub)array in this huge structure; and does to on every request
just in case something reads from $wgExtensionCredits.
The new method to access this information reliably is owned
by SpecialVersion for now (could be moved elsewhere). This
also makes the merging logic more testable and incurs it on-demand
rather than upfront.
Details:
* Move 'type' internally from NOT_ATTRIBS to CREDIT_ATTRIBS.
These two arrays behave identically for most purposes (they are
both used to mean "don't export this as a global attribute").
By placing it in CREDIT_ATTRIBS it becomes complete and makes
it easy to refer to in docs. Previously, extractCredits()
read the 'type' key outside the loop for CREDIT_ATTRIBS.
* Remove redundant code in ApiBase.php, that is now more obviously
redundant. Looks like a left-over or merge conflict mistake
from when ExtensionRegistry was first introduced.
Bug: T187154
Change-Id: I6d66c58fbe57c530f9a43cae504b0d6aa4ffcd0d
The old way of providing a callable to SkinFactory::register is
still supported. Those callables expected the skin name as their
first argument. Coincidentally, so does the constructor of Skin.
Some skins might not define any constructor parameters at all,
which is acceptable to PHP, as it will just discard the argument.
The registration using $wgValidSkinNames has not been changed,
and skins that want to define services to be injected will still
need to manually register their skin to the skin factory.
CodeSearch did not indicate any extensions or skins manually
constructing a SkinFactory in tests, but for posterity, the old
way of creating a SkinFactory for testing can be replaced with
new SkinFactory( new ObjectFactory(
$this->createMock( ContainerInterface::class )
) );
Note that the constructor for SkinFactory for internal use only,
in accordance with the Stable interface policy.
You should use MediaWikiServices::getInstance()->getSkinFactory
instead.
Bug: T244466
Change-Id: I8ba9d869bddd9b6124e47697b789d752c0620b02
Due to T127238, files in various */skins/* directories are not checked
by PHPCS. Temporarily removed the exclude rule from phpcs.xml and ran:
composer fix includes/skins/* tests/phpunit/includes/skins/* tests/phpunit/skins/*
Change-Id: I9240c1cee825920b6634903282be6252cce55686
- Added space after reserved words: function, foreach, if
- Combined 'else if' into elseif
- Added braces to one-line statements
- Added spaces after comma, before parentheses
Change-Id: Ie5bbf680d6fbe0f0872dab2700c16b1394906a72
MediaWiki default is "@return type Description", so set a type after
return and start the description with a capital letter. Also use the
more common spelling of boolean.
See http://phpdoc.org/docs/latest/references/phpdoc/tags/return.html for
more about @return
Change-Id: I4e5198822fe92836f9cef9918a9fc1a1a1e0a043
It's true that right now the internal skin name doesn't have to be all-lowercase,
however not doing so leads to side effects such as the changing of case of i18n message keys,
if the documentation makes programmers aware that something other than all-lowercase can
be used, they should also be aware of the side effects of doing so.
Change-Id: Ib1ed192b1ba83ae864313c34b450a1151485750b
* Document parameters to register()
* Document what the "human-readable name" does
* Document the distinction between autodiscovery and $wgValidSkinNames
skins
Change-Id: Iee5bd18b3e68f3e48ccd28e386109e60fee31085
Modeled similar to ConfigFactory, this lets skins
register themselves via a callback, allowing for
proper dependency injection.
Loading via $wgValidSkinNames is still supported,
but considered "legacy", not deprecated though.
Skin::newFromKey is now deprecated (and had only
one caller in an extension, which I'll update
afterwards).
Change-Id: I1960483f87c2ef55c994545239b728fa376f17f4
