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]
MediaWiki 1.17 contains some new features for skin authors, most of my
skin system reform was backed out for later releases so it's only some
small stuff for now:
I'm not going to go over the ResourceLoader here since I didn't author
it. But do make note of it, skins should update themselves and take
advantage of the resource loader. If you ever thought that your skin's
css file was far too big this is now your chance to split it up into as
many cleanly separated stylesheets and have the resource loader combine
them all into a single stylesheet automatically so you can get the
organized code while keeping your skin nice and fast.
Also make note to use @embed rules and @noflip. You don't need a
separate rtl stylesheet anymore (though do test your skin in rtl
environments so you know what rules you need to @noflip). You don't need
to depend on css sprites anymore since images are embedded into
stylesheets with @embed. However do try to avoid using multiple @embed's
for the same image, if you use the same url() in multiple places in your
css try to consolidate them all into a single combined css rule.
Otherwise when you use @embed you'll be unnecessarily bloating your css
since they're now inline and not combined into one by the browser's cache.
Footer links:
Previously the list of links in the footer was hardcoded into individual
skins, there's now a new array managed by the skin template.
Skin authors can now use $this->data['footerlinks'] and it's sub-arrays,
the way to output the links is generally the same values in the
footericons sub-arrays are tpl keys.
Extensions can now tweak the list of footerlinks by registering a
SkinTemplateOutputPageBeforeExec hook, modifying the one of the
footerlinks sub-arrays in it by adding a new key, and setting a new key
of the same name on the $tpl.
One of these days the footericons may be replaced with a better system
that'll actually be customizable by system message config, but for now
for compatibility reasons this is what we've got.
Footer icons:
The previous copyrightico and poweredbyico keys are now depreciated in
favor of a new footericons setup. The icons are accessible by
$this->data['footericons'] which is populated from $wgFooterIcons, with
some extra guarantees like if "src" is set a width and height will
always be set so you don't need to test for them. There is a
Skin::makeFooterIcon method skins can use to simplify the creation of
the actual footer icons/text, actually I recommend that every skin makes
use of this method with the same kind of boilerplate used by
monobook/vector (for icons) or modern (for text).
Users can now use $wgFooterIcons to customize the icons in the footer.
Kill off the copyright icon, powered by, add an icon to wiki you host in
a wiki farm, add icons for someone responsible for managing your wiki,
etc... Extensions that want to customize this can look at how it's done
in SMW. However do so very sparingly, ONLY if you're a really big
extension like SMW that your users won't mind an icon showing up for (or
of course if your extension's only purpose is to customize that, eg: an
extension that creates a ui to let sysops add icons to the footer). If I
see extensions start to abuse this and bloat the footer with vanity
icons I'll personally go into svn and delete the icons from each extension.
Skin and Extensions authors and users can check the $wgFooterIcons
documentation for info.
Skins also have access to Skin::getCommonStylePath and
Skin::getSkinStylePath. These are helper methods you can use if you have
a need to include the url for a skin or common resource within your skin
itself. Mostly if you're doing something like inserting an image using
an actual <img> rather than a background-image.
Skins can override a new addToBodyAttributes method if there are any
attributes or css classes not in the built-in headelement <body> tag
that they want to be there.
By the way if you haven't already, please do start using the headelement
introduced in 1.16.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
You have been invited to the following event.
Title: Brown bag - Selenium Unit Testing
Selenium Unit Testing on Mediawiki
When: Wed Sep 7 12:30pm – 1pm Pacific Time - Vancouver
Where: SF Office Sixth floor
Calendar: wikitech-l(a)lists.wikimedia.org
Who:
* jpostlethwaite(a)wikimedia.org - organizer
* wikitech-l(a)lists.wikimedia.org
Event details:
https://www.google.com/calendar/event?action=VIEW&eid=ZjZuNmQ3NTRucm5sYWVwb…
Invitation from Google Calendar: https://www.google.com/calendar/
You are receiving this courtesy email at the account
wikitech-l(a)lists.wikimedia.org because you are an attendee of this event.
To stop receiving future notifications for this event, decline this event.
Alternatively you can sign up for a Google account at
https://www.google.com/calendar/ and control your notification settings for
your entire calendar.
For anyone who has doubts about the efficacy of bug triages, I offer
this observation that Siebrand made about the triage in IRC:
I loved this triage! Brilliant. And I really liked we didn't get
stuck in 164, it allowed us to cover everything we had prepared and
more.
Anyway, this was a pretty good triage. We focused on a small subset of
the over 100 bugs tagged with "i18n" and still managed to go over the
allocated 1hr for discussing things.
A couple of bugs were added to the triage since I sent out my
announcement, so I'll just use the etherpad
(http://etherpad.wikimedia.org/BugTriage-2011-08) for this report:
https://bugzilla.wikimedia.org/164 -- Support collation by a certain
locale (sorting order of characters)
We decided this one should be broken up into three separate tracking
bugs and a fourth bug for one specific issue:
https://bugzilla.wikimedia.org/30672 -- improve sorting on other
pages than category pages (tracking)
https://bugzilla.wikimedia.org/30673 -- Support locale-specific, or
tailored, sorting (tracking)
https://bugzilla.wikimedia.org/30674 -- Support better client-side
sorting (tracking)
https://bugzilla.wikimedia.org/30675 -- Use allkeys_CLDR.txt - the
CLDR tailored DUCET instead of allkeys.txt
https://bugzilla.wikimedia.org/24156 -- Messages of log entries should
support GENDER
Although I requested a UX designer to join us for this bug,
apparently there was a scheduling problem. As a result we continued
the triage on the assumption that the format of the RC and log pages
will not change in the future.
After some discussion about the scope of the work needed, Niklas
pointed out that the log messages were implemented differently and
he would like to bring some sanity to the underlying code. Niklas
said he would start on the work after he was satisfied that he could
get someone to review his design and code.
https://bugzilla.wikimedia.org/29000 -- Allow font selection by language
Krinkle and Santhosh discussed this bug heavily. Santhosh pointed
out that the Webfonts extension can already load a font based on the
user language and it could be adapted to load different fonts for
the content language(s) where languages would be specified like
<div lang="ar">.
This raised the question of how to scan the text -- should the text
scanning happen server-side in PHP or client-side in JS, where there
might be a "flash" as the appropriate fonts were loaded.
Finally, Niklas raised the issue of the sidebar which might have 100
different languages each with a different preferred font. To avoid
loading 100 fonts, we'd need to figure out where a font was needed
versus where the text would still be readable without it.
https://bugzilla.wikimedia.org/29005 -- Unnecessary Unicode Char code
change
This one was taken care of with the discussion already on etherpad
before the triage meeting. It is dependent on a Unicode issue with
the Malayalam language. Santhosh is talking with Indian government
agencies. He has prepared a report on this (and some other issues) - to
be submitted to the Unicode Technical Committee.
https://bugzilla.wikimedia.org/4030 -- EasyTimeline reversed text in RTL
languages
We were mostly looking for a Perl developer to take this over.
Since Amir had experienced the pain of this particular problem ("in
Hebrew we actually have to write the words in reverse") and has Perl
knowledge, we gave him full reign.
https://bugzilla.wikimedia.org/29495 -- Numbering system grouping for
Indian languages
Santhosh had already outlined the relevant specifications. When
Niklas asked if we could use the Common Language Data Repository
(CLDR, http://en.wikipedia.org/wiki/CLDR), Santhosh pointed out that
it was incomplete. Siebrand responded that since Wikimedia is a
member of the Unicode Consortium now, completing the CLDR is
actually feasible.
https://bugzilla.wikimedia.org/21429 -- Arabic double diacritics
presentation
This looked like it was mostly an issue of presentation, not any RTL
issues. Since we lacked any Arabic developers in our triage
meeting, Amir volunteered to bring this up next month at a meeting
that Wikimedia Israel had scheduled with some Arabic developers.
https://bugzilla.wikimedia.org/29671 -- Use user-language names of
Special pages in the URL
After a small bit of discussion, everyone agreed to WONTFIX my pet
bug.
As Niklas said in the comments on the bug: "URLs are kind of sacred
area, intended for both humans and computers. I'd avoid doing
anything overly clever there."
https://bugzilla.wikimedia.org/30130 -- Narayam does not work properly
on Chrome browser
Siebrand started discussion on Narayam and getting it re-enabled for
the Tamil wiki projects (https://bugzilla.wikimedia.org/29798).
This issue was the only blocker for that. Santhosh is to implement
a webkit-only workaround for Narayam since the upstream bug
(http://hexm.de/6m, http://hexm.de/6n) and related WHATWG
discussion (http://hexm.de/6o -- featuring our own Aryeh!) point to
long-standing issues in Webkit's handling of things.
Since the webkit problem is the only one remaining with Narayam
deployment, I've asked that it be redeployed for Tamil projects.
Thanks to all who participated in this week's triage. Next Wednesday:
Download Wizard.
Mark.
In an effort to be make the triage process work better (there is
*always* room for improvement), I've set up the next couple of triages
already and put them up on
http://www.mediawiki.org/wiki/Bug_management/Triage
You'll notice that there is nothing scheduled after September 14th --
yet. If you're interested in finding out what topics are going to be
covered, then please put that page on your watchlist.
I'll continue to announce that week's triage a day or two before it
happens here on wikitech-l, but you can get a better idea of what is
upcoming by watching that page.
Finally, if you have areas that you think should be covered in a triage,
let me know.
Mark.
Hi everyone,
I’m extremely pleased to welcome Aaron Schulz to Wikimedia Foundation
as a full-time developer in Platform Engineering. Aaron is a
long-time MediaWiki developer, starting as a volunteer in 2007. He
quickly proved adept at working with the FlaggedRevs extension, so WMF
hired him as a student contractor to take on development, and is now
still the primary developer of the FlaggedRevs extension in use on
many of our larger wikis today. More recently, he volunteered a lot
of the initial work on IPv6 compliance, and has made many small fixes
and improvement in the MediaWiki core. Aaron has been so active in
MediaWiki in the past few years that 5,527 of the 95,732 revisions in
our main source code repository have his name on them.[1]
This summer, Aaron continued his student contractor work on our
software deployment infrastructure, working on the Heterogeneous
Deployment project, which we plan to use to roll out MediaWiki 1.18 in
a controlled manner in September. He's one of many developers who is
slogging away at reviewing code commits in anticipation of 1.18, and
will generally be working on operational and performance-oriented
projects.
Welcome, Aaron!
Rob
[1] See http://www.mediawiki.org/wiki/Special:Code/MediaWiki/author/aaron
It looks like we've finally moved ahead of the curve with regard to
FIXMEs. Today, Sam Reedy (and others) plowed through some of them and
brought us up to where we need to be in order to deploy 1.18 in 3
weeks. We still need to keep up the pace, but we're in a better
position now.
There is one more area that we need to have work done, though, for 1.18
deployment and that is Bug #29068 ("Bugs to be fixed for 1.18 WMF
deployment"): https://bugzilla.wikimedia.org/29068
In order to close this tracking bug we need to fix the following:
https://bugzilla.wikimedia.org/29246 -- API errors occasionally with
unknown error 231
https://bugzilla.wikimedia.org/30192 -- Thumbnails of archived images
don't get deleted
https://bugzilla.wikimedia.org/30352 -- jQuery.makeCollapsible.js should
support 'autocollapse', 'innercollapse' and 'outercollapse' options
https://bugzilla.wikimedia.org/30384 -- extra newlines in nested
templates in tables [parser difference between 1.17 and 1.18]
Thanks for any help you can give on these bugs,
Mark.