Separating skins from core MediaWiki

Separating skins from core MediaWiki

 * Public URL: https://www.mediawiki.org/wiki/User:Matma_Rex/Separating_skins_from_core_MediaWiki
 * Bugzilla report
 * Core skins should initialise and include like other skins/extensions do
 * Unified approach for skin extensions


 * Announcement: tba

Name and contact information

 * Name: Bartosz Dziewoński
 * Email: matma.rex@gmail.com
 * IRC or IM networks/handle(s):
 * freenode IRC: MatmaRex
 * XMPP: matma.rex@gmail.com


 * Web Page / Blog / Microblog / Portfolio: https://github.com/MatmaRex
 * Location: Poland
 * Typical working hours: afternoons and evenings CEST

Synopsis
MediaWiki core includes four skins, and allows site administrators to create and install additional ones. However, the process is less than pleasant, due to several related problems (lack of documentation, more than one "correct" way to make a skin work, directory layout that makes packaging and (un)installation difficult, core skins and MediaWiki itself being interdependent, and possibly others).

I intend to solve at least two of the aforementioned issues by devising and documenting a saner directory layout for skins (and applying it to the four core ones) and then carefully disentangling them from MediaWiki code, removing cross-dependencies and making it possible for non-core skins to have the same level of control over all aspects of the look&feel as core ones currently have. This would make the lives of both skin creators and site administrators wishing to use a non-default skin a lot easier.

If everything goes well, the process would be culminated with moving the core skins out of core, to separate git repositories. This would require coordination with MediaWiki release managers (to have them shipped in the release tarballs the way certain extensions are shipped now) and Wikimedia Foundation Operations team members (to ensure the deployment of the new system on Wikimedia wikis goes smoothly), so it cannot be made a part of my core proposal.


 * Possible mentors: tbd

Deliverables
To avoid any confusion among both laypeople and developers, let's first state that I will not be creating any new skins, nor rewriting the  and   classes.

Stage 1: Improve skinning mechanisms ()
Define and document a standard, recommended way to create skins, after investigating the ways that are currently used.

I'm currently leaning towards a structure similar to the one used by extensions, but with the skins themselves staying in the  directory. This would either use an autodiscovery mechanism to make skins instantly available (similar to what MediaWiki does already) or require users to add an entry to  (similar to what extensions do already).


 * Document the expected directory layout.
 * Document how to define ResourceLoader modules and use them in the skin, making them work both in production and debug mode.
 * Create an example skin following the best practices. A husk with sane HTML structure and basic styles, that can be used as a starting point by lazy skin creators.
 * optional Create a tutorial on this.
 * optional Encourage using the same HTML structure in new skins (but do not enforce it). Writing skins that would be compatible with existing scripts and scripts that would be compatible with a wide variety of skins would be easier if everyone stuck to the same conventions.
 * optional Convert at least one existing skin to new standard.
 * optional Document the process of such conversion. I believe it will be straightforward enough that some examples will suffice.

Make it easier to install and manage skins.


 * Consider deprecating current autodiscovery mechanism, with  file and   directory, in favor of the new system. It makes it unpleasant to add or remove skins, makes it hard to add skins to .gitignore.
 * optional Investigate widely used non-core skins and ensure they will stay compatible with newer MediaWiki versions.
 * Provide support for enabling or disabling skins in the MediaWiki installer. Reusing the way it currently handles extensions should be relatively straightforward.

Make skins more powerful.


 * Provide a way for skins to add styles to core/extensions' ResourceLoader modules. This would be a hard prerequisite for stage 2, as core skins currently abuse core mechanisms to do this.
 * Consider deprecating, which allows the inverse: for modules to define styles only applied to certain skins. MediaWiki uses this heavily for core skins.
 * optional Provide a way for skins to interface with MediaWiki client-side. I might lay some foundations to this, but creating an entire, complete system might be a task for a few months by itself.
 * Allow skins to define methods for common UI operations (overriding default best-guess ones). Currently several core modules make some heavy-handed assumptions about skins' HTML structure to achieve some degree of compatibility. This includes, among others, AJAX watchlisting, adding navigation links (tabs, sidebar), showing notifications, defining the element that is the content wrapper…

Stage 2: Separate core skins from MediaWiki itself ()
This includes Vector (the default skin), Monobook, Modern and CologneBlue.

Identify and get rid of places where MediaWiki code is mixed with skin-specific code.


 * The basics: localisation messages, ResourceLoader modules, autoloader class definitions…
 * Audit all of core's CSS and JavaScript, remove anything skin-dependent.
 * If necessary in order to preserve functionality, create interfaces (broadly speaking) allowing the skin and MediaWiki to cooperate: hooks (server- or client-side), well-defined CSS classes, helper methods.
 * Audit major extensions and do the same. Two extensions that would definitely benefit from this are VisualEditor and Echo, there may be more.

optional Move all four core skins to separate repositories.

The separated skins would have to be bundled with the tarball, and would require some new process to be deployed and updated on Wikimedia servers. I have not investigated either of these in detail yet, but it seems like the solutions for handling extensions should be easy to reuse. I am hoping for some help from (respectively) the MediaWiki release managers and Wikimedia Foundation Operations team.

I marked this as 'optional' due to the caveats above, but I am really really hoping to complete this step. The project would nevertheless be beneficial to MediaWiki without it, but it would feel "incomplete" to me.

This would come with several benefits:
 * Being able to change what we ship with the tarball more easily. In the future (I'm just dreaming now, this is out of scope of this particular project) we might add some new pretty skins and maybe remove some of the default four which have been a bit neglected (but still make them available). Currently doing that would require migrating a lot of code between repositories and modifying it to match core conventions – with everything separated properly no code changes should be necessary.
 * More focus on keeping core code compatible with all skins. It will be clear that one might not make MediaWiki core depend on the layout of a particular skin.

If this is done, MediaWiki would require a tiny fallback skin (for situations when no regular skins are installed). It would show just the page content and basic navigation ( allows one to build it easily) with none or minimal styles, and a big message suggesting installing some skins.

About you

 * Education completed or in progress:


 * How did you hear about this program?


 * Will you have any other time commitments, such as school work, another job, planned vacation, etc., during the duration of the program?


 * We advise all candidates eligible to Google Summer of Code and FOSS Outreach Program for Women to apply for both programs. Are you planning to apply to both programs and, if so, with what organization(s)?

Past experience

 * Please describe your experience with any other FOSS projects as a user and as a contributor:


 * Please describe any relevant projects that you have worked on previously and what knowledge you gained from working on them (include links):


 * What project(s) are you interested in (these can be in the same or different organizations)?