The format of $wgValidSkinNames has been changed. Previously it had been
`$wgValidSkinNames[key] = name;` but now it's `$wgValidSkinNames[key] =
ClassNamePostfix;`
In essence the code that creates a skin class has now been changed to
try to create a class named "Skin{$wgValidSkinNames[$key]}".
This change is because of a bug with skins that are autoloaded.
Previously when you defined a skin like `$wgValidSkinNames["bluebook"] =
"BlueBook";` MW would try to load SkinBluebook rather than SkinBlueBook.
This worked in core because we didn't autoload skins and instead did a
`require_once( "{$wgStyleDirectory}/{$wgValidSkinNames[$key]}.php" );`,
because php's class system is case-insensitive SkinMonoBook always
loaded fine, however this wasn't the case for extension based skins
which used our case-sensitive autoloader.
Keep this in mind when making autoloaded skins if you want pre-1.18
compatibility you may have to add two autoloader lines, one for
SkinBlueBook and another for SkinBluebook.
Legacy skins are depreciated. The old skin system inside 'Skin' that
powered the old skins CologneBlue, Nostalgia, and Standard/Classic has
been dropped and replaced by a deprecated SkinLegacy system based mostly
on SkinTemplate. New skins should all be SkinTemplate based, SkinLegacy
only exists to support the 3 core skins that were ported, it may be
eliminated from core in the near future along with the legacy skins.
Note that this means a lot of methods like Skin::editThisPage() that
were never meant to be used by SkinTemplate are no longer available, if
you used $sk-> methods check over your skin to make sure it's not
throwing errors because you were using outdated methods.
We now have a context system, if building a skin for 1.18+ please ensure
that you use ->getUser(), ->getLang(), ->getRequest(), and
->getOutput(), instead of $wgUser, $wgLang, $wgRequest, and $wgOut.
The linker is now static, skins wishing to use linker methods should
migrate away from calling them on $sk-> and use Linker:: properly.
Note that doEditSectionLink is now explicitly part of Skin, it's no
longer a Linker method, if you're using it take note of that. As a
result of this and some parser changes skins can now customize the
editsection link within their own skin by overloading the
doEditSectionLink method. Note that if you did this before 1.18 you
would pollute the cache and end up with other skins having your
customizations sometimes, and your skin losing it's customization
sometime. Make note of that if you override doeEditSectionLink as you
may want to include a conditional to leave it alone if your skin is used
in a release before 1.18.
We have two new pieces of information for skin, a relevant title and
relevant user. Relevant title is used when doing things like generating
tabs, special pages like Special:Movepage use it to make skins display
the tabs for pages they are relevant to instead of making them suddenly
disappear on the user (1.19 or later may have a more robust way of
handling tabs though). Relevant user is similar, pages like
Special:Contributions use it so things like the block link in the
toolbar are the same as when visiting a userpage.
The specialpageattributes key is no longer needed in your skin if it's
meant for 1.18+, there's better code in core now handling lang/dir for
the body.
The printfooter and debughtml have been pulled out of bodytext and are
now in separate printfooter and debughtml keys (I think I need to make
not of that in my own skins).
((I have some issues with this change (not mine), the situation may
change a little before release if I try to backport something))
The "Login / create account" link can now be split into two separate
"Login" and "Create account" links by user configuration using
$wgUseCombinedLoginLink. For now it defaults to the same behavior as
before. Skins which have a reason to need one behavior or another (eg:
turning the links into buttons and wanting to make sure they're both
there) can override the useCombinedLoginLink method and return either
true (combined) or false (split) to override the configuration.
A great one now. Sort of replacing content_actions we have a new
content_navigation tplkey. The Vector code generating it's own
hierarchical content_actions has been pulled out of vector and merged
into SkinTemplate, any skin that wants to take advantage of the better
organized namespace/variants/views/actions categorization of our tabs
can now use content_navigation to take advantage of them. Skins using
content_actions will still work, the content_actions array is created
based on content_navigation now, the content_navigation arrays are
annotated with information like 'primary' (vector uses this to stop
collapsing of tabs into the menu on small screens) and 'redundant' for
tabs like 'read' which tells the content_actions code that the tab is
redundant and shouldn't be included in content_actions.
Extensions which used SkinTemplateTabs and didn't add a
SkinTemplateNavigation hook will stop working as the
SkinTemplateNavigation hook has completely replaced SkinTemplateTabs
(ok, I admit I think there's an old SkinLegacy hack that still uses
SkinTemplateTabs for the tabs in legacy code). Extensions that had
issues with vector's code not including replacements for the
SkinTemplateBuildContentActionUrlsAfterSpecialPage and
SkinTemplateContentActions hooks will be happy to know that
content_actions now has equivalent replacement hooks
SkinTemplateNavigation::SpecialPage and
SkinTemplateNavigation::Universal which you can add. If you use these
hooks in new code, and don't need pre-1.18-non-vector compat, and aren't
worrying about SkinLegacy still using a SkinTemplateTabs hack you don't
need to include the old hooks since content_actions is extracted from
content_navigation.
There is new message fallback code in the i18n system. Many of the
messages for tabs like 'move' can be overridden per-skin with messages
like 'vector-action-move', 'modern-action-move', etc... If not defined
they will fallback to the normal message. Vector had some message
customizations before because of changes from monobook in how it handled
tabs so this was added so we'd have a way to keep those without doing it
in an ugly hacky way. Other skins can now include similar customizations
and individual wiki can include per-skin message overrides if there are
things like the edit button you want to customize the message for but
have an issue where it looks fine in one skin but messes up the
intuitiveness of another.
Skin QuickTemplates now have a $this->getSkin() method they can use
instead of fumbling around with $this->data['skin'].
We have a new BaseTemplate class that extends QuickTemplate, it includes
a number of helpers for skins and you can start to take advantage of
them in a 1.18 skin by extending from BaseTemplate instead of directly
from QuickTemplate.
This can kill a lot of ugly boilerplate from skins like the huge
boilerplate for personal_urls and content_{actions,navigation}. Links
and list items for many of the common tpl key arrays we have (ie:
content_{actions,navigation}, etc...) where there are arrays like
personal_urls that aren't in a format these helpers can handle we have
helpers like getPersonalTools that will give you an array in the right
format. The search input and search button have helpers to simplify them
too (I couldn't come up with a good helper for the search form opening
code though). You can replace the mess of bottomscripts, reporttime, and
debug trail in your skin now with a simple `$this->printTrail();`. And
those remembering my footerlinks and footericons code just introduced in
1.17 will be happy to know there are helpers here to simplify the
boilerplate for those. Also that horrible ugly massive boilerplate for
the toolbox you have to copy into any skin, we now have a getToolbox
helper that returns an array that will work with the mageListItem
helper, it also has a new hook BaseTemplateToolbox that will work on
that rather than have you output raw html not customized by skin. So
please do start using it in skins, it would be nice to deprecate those
html hooks and have extensions stop using them.
----
1.19 is in active development so there isn't much added yet, but I do
have a nice quick note on what is in there now.
Vector contains a pile of css for content styling which was basically
copied from Monobook and modified slightly. That css has now been
stripped out and put into three stylesheets in common/:
commonElements.css: This stylesheet contains all your basic elements;
Paragraphs, Links, Headers, etc... If you want anything from the common
styles you'll want this at least.
commonContent.css: This stylesheet contains more complex things which
are contained within the content area, right now it contains things like
the TOC and the frames that are wrapped around images. These are things
you might not want default styles for in your skin and might want to
customize in ways that having pre-existing styles could get in the way
of (it's easier to override simple styles by commonElements than it is
do undo the styling of the entire toc for example).
commonInterface.css: This stylesheet contains some extra common stuff
between MonoBook and Vector. These are tied to patterns in ids and
classes for things like the usermessage, catlinks, etc... which are
outside of the bodytext and the skin may decide on the ids and classes
for. If you're making a skin that sticks with the MonoBook/Vector
patterns of laying out and id/classing the content area you can include
this stylesheet to get some of the common styles.
There are a few notes on opting-in to this in your skins:
- I haven't figured out how to deal with the icons for external links
(the https, audio, etc... icons) yet, MonoBook and Vector use different
icons so while the pattern is common the images aren't. So they aren't
actually the same stylesheet wise. This may end up as a separate to
include stylesheet later on.
- When opting in you'll need to add a class="mw-body" somewhere into
your skin to define the area where content css stylings for things like
links will apply. In MonoBook this is on the same element as
#bodyContent and in Vector it's #content.
- To use these stylesheets include them into your ResourceLoader
'styles' array, that way it all gets combined into a single css file for
your skin.
-- I didn't make this a separate module because we include
&skin=skinname into the /load.php call, that means that even if I make
these modules they aren't reused between different skins. Hence there is
no value in having them in a separate module and it's better to include
them in the skin's own module where they'll be combined into a single
css file.
- With link styles and one or two minor changes from MonoBook to Vector
the Vector difference was preferred since Vector has replaced MonoBook,
MonoBook is now essentially outdated, and new skins will likely be
Vector based rather than MonoBook based. If you want things to look a
little more old and monobook like you may want to add some overriding
css in your own styles like the rules that monobook adds in it's own css
for links.
- MonoBook and Vector use different bullet images for ul {}, since
they're embedded images and would end up inlined in skins that might
override them I opted out of including them in the elements stylesheet.
If you want a list bullet image you'll have to embed one into your own
stylesheet. We have an old .gif that looks like the one in MonoBook
inside common, but the Vector one right now is only in vector. Though I
may contemplate moving that to common.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [
http://daniel.friesen.name]