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

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
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