Last modified: 2014-07-08 02:01:02 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T45658, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 43658 - Unified approach for skin extensions
Unified approach for skin extensions
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Interface (Other open bugs)
1.21.x
All All
: Normal enhancement (vote)
: 1.24.0 release
Assigned To: Bartosz Dziewoński
:
Depends on:
Blocks: 27292
  Show dependency treegraph
 
Reported: 2013-01-05 13:09 UTC by taste1at
Modified: 2014-07-08 02:01 UTC (History)
5 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description taste1at 2013-01-05 13:09:59 UTC
Currently, core skins are located in the skins/ directory, while for user-provided skins two systems exist:

1) Put into the skins/ directory (cf. documentation at https://www.mediawiki.org/w/index.php?title=Manual:Skinning&oldid=605468#File_Locations)

2) Put into the extensions/ directory (cf. https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/skins.git;a=tree;hb=df496d1f4dff27eed0bf44cab5c4f2377dfe5377)

It would be reasonable to have a unified approach which is suggested to all extension developers.

I think, it would be reasonable to have only core skins in skins directory and all other skins in extensions directory, i.e., variant 2. This would have the following implications:

a) New skins have to be registered like any other extenison, i.e., require_once(...) in LocalSettings.php

b) Skins can be activated/deactivated by the installer

c) Skin-extensions can be distributed like any other extension

d) You have a reasonable file structure

/extension/foo/Foo.php
/extension/foo/Foo.class.php
/extension/foo/bar.css
/extension/foo/...

and NOT

skin/Foo.php
skin/Foo.deps.php
skin/foo/bar.css
skin/foo/...

which somehow does not look well-organized

e) Skin-extensions can provide everything an extension can provide, like credits or additional preferences

f) The skinning system does not have to look for available skins in the filesystem, as core skins are known to core anyway and other skins provide their own $wgValidSkinNames['Foo'] = 'Foo';
Comment 1 taste1at 2013-01-05 14:37:50 UTC
(Some followup:)

Currently, there is a third way of Skins being implemented currently:

3) Like an extension, where the user is suggested to put it into /skins/ but using a folder structure as extensions would have. Here, it is also necessary to register them in LocalSettings.php:

cf. https://www.mediawiki.org/wiki/Skin:Erudite and https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/skins.git;a=tree;hb=df496d1f4dff27eed0bf44cab5c4f2377dfe5377
Comment 2 Daniel Friesen 2013-01-05 17:17:59 UTC
That third method is going to be the standard way to do skins in the future. It's outlined in a tutorial and bit by bit MediaWiki is going to be coded to autodetect stuff done in that method.

http://blog.redwerks.org/2012/02/08/mediawiki-skinning-tutorial/
Comment 3 Bartosz Dziewoński 2014-07-08 02:01:02 UTC
I believe that we can consider this done: see the list of changes I made and documentation I created at https://www.mediawiki.org/wiki/Separating_skins_from_core_MediaWiki#Stage_1:_Improve_skinning_mechanisms_.28bug.C2.A043658.29

(I have somehow neglected to comment on this bug earlier, sorry!)

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links