When originally introduced, a skin's templateDirectory was relative
to core, rather than the skin itself. Most skins needed to set
something like "skins/Example/templates", hardcoding the default value
of $wgStyleDirectory.
skin.json will now assume that the value of templateDirectory is
relative to the skin itself. If that directory doesn't exist, we'll
fallback and assume it's using the previous behavior of being relative
to core. In practice this should not be a breaking change since no skin
is expected to have a directory like "skins/Example/templates" inside
the skin itself.
Finally, ExtensionProcessor will set a default templateDirectory if
one isn't already set, so in most cases this setting should be able
to just be removed entirely.
Bug: T262067
Change-Id: I434b8a4319f3c8b65bcaab3465224058f31e7ae8
- Mark the file as loaded only if loading actually succeeded;
- Enforce the expectations of this class around mFile not being null
with an exception. This should eventually be replaced with
something better.
More details at T250767#6892136.
Bug: T250767
Change-Id: If01ae00a76597dcb3cbbede56c20ef0edefb57b1
This makes it easier to run, but more importantly, makes it obvious
that the file in /data/jsmin is still conceptually in use.
Change-Id: Iaf10c9bd2f6643bcb0bae95eaf22ec92de15950d
Most of the time this is due to garbage user input, and MediaWiki's
normal handling of user input strings is to normalize them, not to
throw.
There are some hypothetical cases where a developer might want to see an
exception, rather than passing garbage to the client and letting the
client fail, but normalization is a defensible policy and works within
the existing interfaces.
Bug: T289597
Change-Id: Ida5ee72c10d1c3499b5b17594c5675db7cd38335
Methods are promoted upwards from SkinMustache to SkinTemplate
in preparation for them being shared between SkinMustache and
BaseTemplate.
This is mostly a move of existing functions in SkinMustache but
also introduces SkinTemplate::getTemplateData and updates SkinMustache
to call the parent function.
Bug: T263213
Change-Id: I028364eb91e907c2f51529aac495df1eaca7b466
Use ContentTransformer::preSaveTransform instead.
Extensions defining a content model should override ContentHandler::preSaveTransform.
Bug: T287156
Change-Id: I2a8c60470366fd95d056e0dfa8144f209bb7117e
For 99% of JS classes, there is no constructor description and instead
the class/constructor are defined together followed by both `@class`
and `@constructor` in the same block. These are interpreted as the
description belonging to the class and prominently displayed in the
documentation.
For the very rare cases where a constructor has its own description,
this must follow the tag rather than preceed it. This makes sense
when thinking about it in terms of how classes are usually defined
(above the constructor, and thus the space above `@constructor`
already belongs to `@class`).
This has the unfortunate side-effect, however, that when a constructor
is documented on its own, that any text above `@constructor` is
ignored, as happened with mw.Api.
But, as so often with strict documentation warnings, it helped uncover
a mistake. The text here is quite useful and not really specific to
the constructor and more broadly useful for the module as a whole,
as such I moved it to the class block.
Also:
* Clean up the code by bringing the class and constructor definition
back together.
* Fix warning about invalid internal reference:
> Warning: /resources/src/mediawiki.api/index.js:3: {@link https://…}
The `@see` tag is only valid when referring to another index entity.
There were three other uses of `@see` with a URL in core, but only in
`@ignore`-ed code, which this commit fixes at the same time.
Follows-up a28b76abe9.
* Use local `var` declarion for `promises`, since "one-var" style
is no longer current.
Change-Id: I2d4f8b99c2896d4e1af50956c9faa8b36344884e
