And here it is: https://www.mediawiki.org/wiki/Skin:Example and
https://git.wikimedia.org/tree/mediawiki%2Fskins%2FExample.git
Thank you for the comments. It's nice knowing that somebody cares about
the work I've been doing with this :)
--
Matma Rex
\o/
On Mon, Jul 21, 2014 at 11:28 AM, Bartosz Dziewoński
matma@gmail.com wrote:
And here it is: https://www.mediawiki.org/wiki/Skin:Example and
https://git.wikimedia.org/tree/mediawiki%2Fskins%2FExample.git
Thank you for the comments. It's nice knowing that somebody cares about the
work
Late, but done: https://gerrit.wikimedia.org/r/#/c/147690/ . I'd love if
some more people glanced at it before i make it official.
-- Matma Rex
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
I just wanted to thank Bartosz for all the good work he's done here!
It's great that finally installing a skin is consistent with
installing an extension :)
I wonder if we should create a skin boilerplate repository, to make it
really easy for people to get started making their own skins?
On
On 14/07/14 18:41, Jon Robson wrote:
I just wanted to thank Bartosz for all the good work he's done here!
It's great that finally installing a skin is consistent with
installing an extension :)
I wonder if we should create a skin boilerplate repository, to make it
really easy for people to get
Thanks for the info Isarra!
Does anyone want to make it not empty...? :)
I'll personally +2 any changes if the author sends me a private email to
the patchsets!
On 15 Jul 2014 07:39, Isarra Yos zhoris...@gmail.com wrote:
On 14/07/14 18:41, Jon Robson wrote:
I just wanted to thank Bartosz for
On Tue, 15 Jul 2014 16:38:52 +0200, Isarra Yos zhoris...@gmail.com wrote:
On 14/07/14 18:41, Jon Robson wrote:
I wonder if we should create a skin boilerplate repository, to make it
really easy for people to get started making their own skins?
Theoretically that's what the skins/Example
I finally implemented most of the ideas discussed here into documentation,
and I think I settled on something that should be acceptable to everyone.
The canonical recommended way to do skins, and one we hopefully all agree
on, is now described at
On Wed, May 28, 2014 at 02:00:36PM +0200, Stephan Gambke wrote:
You are late. ;-)
A type mediawiki-skin exists.
Oh, fantastic :) Thanks for letting me know.
It would probably be good to add this info to the
Manual:Skinning/Tutorial page. I'll do that when I've made it work
for Erudite, if
On Tue, 27 May 2014 05:28:41 +0200, Dan Garry dga...@wikimedia.org wrote:
I am not a developer and therefore I cannot speak for them, but from a
product perspective I have no insurmountable issues with either the /skins/
or the /extensions/ solution. It seems that there's pros and cons for each
One related thing that could be useful would be creating a
mediawiki-skin type for composer, so skins could use composer and
be assured of going into the skins/ directory.
I haven't used composer yet, but presumably it's a reasonable thing
for skins to support, once they can be automatically
On Sat, 24 May 2014 21:12:26 +0200, Bartosz Dziewoński matma@gmail.com
wrote:
First of all, something we all agree on: let's murder skin autodiscovery. I'll
submit patches to emit deprecation warnings if a skin using it is found (to
master and 1.23 LTS release), and another patch that will
On 24 May 2014 14:12, Bartosz Dziewoński matma@gmail.com wrote:
Are there any fundamental, insurmountable issues with having skins in
'skins/'
in WMF production?
I am not a developer and therefore I cannot speak for them, but from a
product perspective I have no insurmountable issues
On Sun, 25 May 2014 00:11:28 +0200, Daniel Friesen dan...@nadir-seen-fire.com
wrote:
However $wgValidSkins isn't
something should become case insensitive, attempting that for array keys
is asking for bugs. Same for putting non lowercase keys in the database
and trying to make them case
A skin has (or imho should have) (only) two name like properties:
1) Internal identifier (id):
- Used for processing at the application level and as public API
(configuration variables, url parameters, API properties, database values,
dynamically constructed page names such as for site and
On Tue, 20 May 2014 23:38:14 +0200, Tyler Romeo tylerro...@gmail.com wrote:
I wouldn't consider this change to be truly revolutionary. Would would
really be a great restructuring of the skinning system is if I could make a
skin by just writing a couple of HTML templates (probably using
On Wed, 21 May 2014 00:06:57 +0200, Jack Phoenix j...@countervandalism.net
wrote:
The pros of using /extensions/SkinName are:
[...]
* All non-core code in one place.
While this is true and somewhat handy, there can be unexpected situations
such as two independent developers (or teams)
On Wed, 21 May 2014 09:48:21 +0200, Daniel Friesen dan...@nadir-seen-fire.com
wrote:
And for the bit on re-caching that is simple.
Assets for core skins like Vector and old skins that are implemented
using the autoloader are currently at:
{mediawiki}/skins/vector/*
If you change the directory
On Wed, 21 May 2014 22:38:00 +0200, Stephan Gambke s7ep...@gmail.com wrote:
There seem to be three popular ways:
* $IP/skins/SkinName.php for the main file plus $IP/skins/skinname/
for
...
* $IP/skins/SkinName/ for both assets and PHP files
($IP/skins/skinname/SkinName.php etc.), using
On Wed, 21 May 2014 19:56:53 +0200, Jon Robson jdlrob...@gmail.com wrote:
What is the advantage of doing
this instead of just using the tried and tested extensions directory?
What stops a new user from plopping the folder into the extensions
directory by accident out of habit?
Stephan has
Thank you for all the comments! I've had a few busy days, sorry for only
replying now. I'm going to try summarizing everything.
I have replied to a few tangenial messages separately. Many things have been
said here (and in several disconnected threads), so I might have missed
something – please
On 2014-05-24, 12:12 PM, Bartosz Dziewoński wrote:
First of all, something we all agree on: let's murder skin
autodiscovery. I'll
submit patches to emit deprecation warnings if a skin using it is
found (to
master and 1.23 LTS release), and another patch that will remove it
entirely
On 2014-05-24, 10:49 AM, Bartosz Dziewoński wrote:
On Wed, 21 May 2014 09:48:21 +0200, Daniel Friesen
dan...@nadir-seen-fire.com wrote:
And for the bit on re-caching that is simple.
Assets for core skins like Vector and old skins that are implemented
using the autoloader are currently at:
On Sun, 25 May 2014 00:53:09 +0200, Daniel Friesen dan...@nadir-seen-fire.com
wrote:
On 2014-05-24, 10:49 AM, Bartosz Dziewoński wrote:
I'm sorry, but this is very silly reasoning. Cache is not forever
anyway, and ResourceLoader includes cache-busting timestamps in URL
queries for each
On 21/05/14 07:25, Bartosz Dziewoński wrote:
* $IP/extensions/SkinName/ for everything, the rest as above. This
makes the skin work exactly like an extension. The only example I
could find on mediawiki.org is the Nostalgia skin [5].
I introduced this facility to core many years ago, and I
On 2014-05-20, 10:28 PM, Isarra Yos wrote:
On 20/05/14 23:05, Daniel Friesen wrote:
* The skinname you require is the same one assigned to $wgValidSkins
and set on $wgDefaultSkin and set on $skinname, and $stylepath.
* For all skins using the old autoload pattern the assets
On 2014-05-21, 6:02 AM, Jon Robson wrote:
I've always found it silly that skins are installed in a different way
to extensions. It seems silly to teach a user 2 ways. To be honest I
still haven't got the hang of skin installation. I usually crudely
plop a folder in the skins directory which
I tend to agree that skins should be installed in exactly the same way as
other extensions. This will also help make installation more automateable.
-- brion
On May 20, 2014 11:39 PM, Tim Starling tstarl...@wikimedia.org wrote:
On 21/05/14 07:25, Bartosz Dziewoński wrote:
*
On 21 May 2014 13:01, Brion Vibber bvib...@wikimedia.org wrote:
I tend to agree that skins should be installed in exactly the same way as
other extensions. This will also help make installation more automateable.
From a product perspective, +1 for this.
Dan
But why create a new system to learn? What is the advantage of doing
this instead of just using the tried and tested extensions directory?
What stops a new user from plopping the folder into the extensions
directory by accident out of habit?
On Wed, May 21, 2014 at 5:42 PM, Daniel Friesen
(Firstly, apologies for breaking threading, and not quoting things
as fully as I normally would. I only just subscribed to this list,
so don't have previous mails in my mail client.)
I'm the main author of the Erudite skin[0], which Daniel Friesen
helped a good deal with when shepherding it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
There seem to be three popular ways:
* $IP/skins/SkinName.php for the main file plus $IP/skins/skinname/
for
...
* $IP/skins/SkinName/ for both assets and PHP files
($IP/skins/skinname/SkinName.php etc.), using require_once in
...
*
On Wed, May 21, 2014 at 1:38 PM, Stephan Gambke s7ep...@gmail.com wrote:
Using that reasoning you could just put all of MW in one
directory (or in one file, even) and be done with it.
That's the most sensible idea I've read all week :D
-Chad
___
On 21/05/14 20:38, Stephan Gambke wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
There seem to be three popular ways:
* $IP/skins/SkinName.php for the main file plus $IP/skins/skinname/
for
...
* $IP/skins/SkinName/ for both assets and PHP files
($IP/skins/skinname/SkinName.php etc.),
On Tue, May 20, 2014 at 5:25 PM, Bartosz Dziewoński matma@gmail.comwrote:
tl;dr Let's start putting all skins files in a single directory, and let's
use a grown-up structure with one class per file + separate init code for
them. Okay?
I wouldn't consider this change to be truly
On Tue, May 20, 2014 at 2:25 PM, Bartosz Dziewoński matma@gmail.comwrote:
tl;dr Let's start putting all skins files in a single directory, and let's
use a grown-up structure with one class per file + separate init code for
them. Okay?
Sounds good to me. I agree with Tyler that there's
On Wed, May 21, 2014 at 12:25 AM, Bartosz Dziewoński matma@gmail.comwrote:
As you might know, I am doing a Google Summer of Code project aiming to
disentangle the mess of MediaWiki's skinning system a little bit, make
creating custom skins a bit less painful and improve the separation
On 2014-05-20, 2:25 PM, Bartosz Dziewoński wrote:
There seem to be three popular ways:
* $IP/skins/SkinName.php for the main file plus $IP/skins/skinname/
for assets, using an autodiscovery mechanism to automagically make the
skin available after the files are copied in the right place. This
On 20/05/14 22:07, Daniel Friesen wrote:
On 2014-05-20, 2:25 PM, Bartosz Dziewoński wrote:
There seem to be three popular ways:
* $IP/skins/SkinName.php for the main file plus $IP/skins/skinname/
for assets, using an autodiscovery mechanism to automagically make the
skin available after the
On 2014-05-20, 3:48 PM, Isarra Yos wrote:
Out of curiosity, what are your reasons for advocating lowercase skin
names over the standard camelcase format used throughout the rest of
MediaWiki?
I included those in my bullet points.
* The skinname you require is the same one assigned to
On 20/05/14 23:05, Daniel Friesen wrote:
On 2014-05-20, 3:48 PM, Isarra Yos wrote:
Out of curiosity, what are your reasons for advocating lowercase skin
names over the standard camelcase format used throughout the rest of
MediaWiki?
I included those in my bullet points.
* The skinname you
41 matches
Mail list logo
