tl;dr: I am going to break your workflow and your wiki. Skip to the last section and read on.
== Background ==
As you know, I've been working on a GSoC project to better separate skins and core MediaWiki [1]. Moving Vector and MonoBook to separate repositories is the final step of it, and it's exactly as scary as it sounds.
Until recently MediaWiki was heavily interconnected with the core skins, particularly Vector – right now it is only slightly interconnected and I have some patches pending to make it not so at all [2].
[1] https://www.mediawiki.org/wiki/Separating_skins_from_core_MediaWiki [2] https://gerrit.wikimedia.org/r/#/q/topic:skinning,n,z
== The plan ==
* Fix up some remaining issues with Vector being required (I have already fixed most) * Stop always loading MonoBook and Vector [patch pending: https://gerrit.wikimedia.org/r/148509 + dependencies] * Use a special fallback when no skins are installed [patch pending: https://gerrit.wikimedia.org/r/148508] * Move MonoBook and Vector to separate repositories * Ship MonoBook, Vector and some more skins with the installer tarball * Enable them during the installation [patch merged: https://gerrit.wikimedia.org/r/138652]
== What it means for you ==
If you're upgrading a wiki or you're a developer working on master, THIS IS A BACKWARDS INCOMPATIBLE CHANGE. Your wiki will continue to work, it will just look ugly (no styles).
When we do this and you upgrade, you're going to get a big helpful message asking you to install and enable some skins and explaining how to do this (see https://gerrit.wikimedia.org/r/148508 for implementation; basically, put the files/repository under skins/ and require_once in LocalSettings).
Try it out with this patch: https://gerrit.wikimedia.org/r/148509
After you do this, you'll be able to switch to slightly older MediaWiki versions without things breaking, as the new skins will work with old MediaWiki (the new directory names are different… unless you're using a case-insensitive OS).
I hope this sounds reasonable to everyone, and I hope to have this done around the time of Wikimania (possibly during it; I'll be there). I don't think there is a less disruptive way to do this, other than not doing it at all; if you come up with one, please share it.
Hi Bartosz,
Sounds good.
Bartosz Dziewoński schreef op 28-7-2014 20:53:
If you're upgrading a wiki or you're a developer working on master, THIS IS A BACKWARDS INCOMPATIBLE CHANGE. Your wiki will continue to work, it will just look ugly (no styles).
And I assume whatever MediaWiki version this will be packaged into should will include an upgrade script for people who just bump one version?
Maarten
Why not just move them to an extension? moving them to their own repo begs for a headaches
On Mon, Jul 28, 2014 at 4:50 PM, Maarten Dammers maarten@mdammers.nl wrote:
Hi Bartosz,
Sounds good.
Bartosz Dziewoński schreef op 28-7-2014 20:53:
If you're upgrading a wiki or you're a developer working on master,
THIS IS A BACKWARDS INCOMPATIBLE CHANGE. Your wiki will continue to work, it will just look ugly (no styles).
And I assume whatever MediaWiki version this will be packaged into should will include an upgrade script for people who just bump one version?
Maarten
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Mon, 28 Jul 2014 22:59:40 +0200, John phoenixoverride@gmail.com wrote:
Why not just move them to an extension? moving them to their own repo begs for a headaches
I don't understand the problem you see here nor the solution you're proposing. Elaborate?
I use a standard git checkout. Moving these to their own separate location is going to be a pain in the ass. If the skins are moved to the existing extension system it causes far fewer problems and does not introduce additional steps in upgrading/maintaining a site. When we start having sub repos and forking left and right it gets ugly. We already have an existing framework for adding modules to mediawiki (Extensions) let's use that vs re-inventing the wheel.
On Monday, July 28, 2014, Bartosz Dziewoński matma.rex@gmail.com wrote:
On Mon, 28 Jul 2014 22:59:40 +0200, John phoenixoverride@gmail.com wrote:
Why not just move them to an extension? moving them to their own repo begs
for a headaches
I don't understand the problem you see here nor the solution you're proposing. Elaborate?
-- Matma Rex
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
@John: Extensions are git repositories. Moving it to an extension involves moving them in their own repo, like any other extension. I guess you're mostly concerned about it being repositories not under mediawiki/extensions, because it'll be a repository either way.
@Bartosz:
I'm inclined to agree. I personally do not see any use in having mediawiki/skins/* in Gerrit as separate structure for repositories that are extensions in every way. An extension can provide hooks, messages, config variables, special pages, skins, api modules, resource modules and more. A skin repo would typically provide at least three of these (messages, skin, resource modules) and possibly hooks and config variables as well. What's the point in having a separate scheme for repos that provide some arbitrary subset of these features?
But more important than the naming scheme in Gerrit (which I could care less about) is the local development workflow which affects developer productivity and understandability of our eco system. Let's aim to keep be as simple as possible without compromising on important benefits.
We have an mediawiki/extensions.git meta repository. To avoid conflicts with MediaWiki core's extensions directory (which, albeit being almost empty, will still conflict in unproductive ways when working with wmf branches), I always advocate people set up an extensions directory on their disk elsewhere (e.g. next to mediawiki-core, not inside), either as the meta repo clone or as your own container directory with git clones of individual extensions inside of it. Then simply configure $wgExtensionAssetsPath to point at localhost/git/extensions or whatever and require_once in LocalSettings from ../extensions instead.
That's a one time setup quite a few developers have already from what I understand (Reedy, Chad and Roan all recommended it to me originally, not sure who had it first) and from then on you just git-clone <path> or git-submodule-update--init <path> any extension you run into when working in different projects, and can add a require_once and it all just works.
This could be set up for skins as well, but it's tricky. Aside from having two systems then, it's still tricky. At least for a while to come (working with current wmf branches, and release branches) we can't guarantee skins/ to be empty. And unless we introduce a separate core skins path / external skins path variable, you can't really set one without breaking the other.
It is possible to get it right but it comes at the cost of several months / up to 2-3 years of inconvenience locally for everyone. We haven't committed to this new structure yet, and instead of taking this opportunity to create a mess for years to come, I'd rather take this opportunity to get rid of the mess that is mediawiki/skins altogether and just fold it all back into extensions.
To get the ball rolling: What's the downside of going that route? We have quite a lot to gain in terms of simplicity and compatibility.
Breaking things can be good, but I haven't seen any short or long term benefits so far that would justify it.
— Krinkle
On 28 Jul 2014, at 23:02, John phoenixoverride@gmail.com wrote:
I use a standard git checkout. Moving these to their own separate location is going to be a pain in the ass. If the skins are moved to the existing extension system it causes far fewer problems and does not introduce additional steps in upgrading/maintaining a site. When we start having sub repos and forking left and right it gets ugly. We already have an existing framework for adding modules to mediawiki (Extensions) let's use that vs re-inventing the wheel.
On Monday, July 28, 2014, Bartosz Dziewoński matma.rex@gmail.com wrote:
On Mon, 28 Jul 2014 22:59:40 +0200, John phoenixoverride@gmail.com wrote:
Why not just move them to an extension? moving them to their own repo begs
for a headaches
I don't understand the problem you see here nor the solution you're proposing. Elaborate?
-- Matma Rex
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Tue, 29 Jul 2014 13:00:37 +0200, Krinkle krinklemail@gmail.com wrote:
(…) I personally do not see any use in having mediawiki/skins/* in Gerrit as separate structure for repositories that are extensions in every way. An extension can provide hooks, messages, config variables, special pages, skins, api modules, resource modules and more. A skin repo would typically provide at least three of these (messages, skin, resource modules) and possibly hooks and config variables as well. What's the point in having a separate scheme for repos that provide some arbitrary subset of these features?
In the Glorious Future, there might come a day when skins will no longer need to provide any PHP code; they'd just define some configuration, HTML templates and CSS+JS. One can dream, eh?
mediawiki/skins/* is already the de-facto accepted hierarchy for skins in Gerrit, with about 20 repositories there (and most of them indeed functional) [1]; I am not aware of any skins in mediawiki/extensions/ other than Nostalgia (which has been migrated to skins/ too).
The naming has been discussed on this list in the past, and the result is summarized at [2].
[1] https://gerrit.wikimedia.org/r/#/admin/projects/?filter=mediawiki%252Fskins%... [2] http://www.gossamer-threads.com/lists/wiki/wikitech/465428#465428
But more important than the naming scheme in Gerrit (which I could care less about) is the local development workflow which affects developer productivity and understandability of our eco system. Let's aim to keep be as simple as possible without compromising on important benefits.
I don't think using skins/ in this way is as problematic as you're making it seem:
We have an mediawiki/extensions.git meta repository. To avoid conflicts with MediaWiki core's extensions directory (…) I always advocate people set up an extensions directory on their disk elsewhere (e.g. next to mediawiki-core, not inside), either as the meta repo clone or as your own container directory with git clones of individual extensions inside of it. Then simply configure $wgExtensionAssetsPath to point at localhost/git/extensions or whatever and require_once in LocalSettings from ../extensions instead.
This is possible with skins in exactly the same way, but instead of $wgExtensionAssetsPath you configure $wgStylePath.
The 'common' directory might be a bit problematic here. I think we should just get rid of it once and for all and put the assets in resources/ where they belong.
This could be set up for skins as well, but it's tricky. Aside from having two systems then, it's still tricky. At least for a while to come (working with current wmf branches, and release branches) we can't guarantee skins/ to be empty. (…)
It is possible to get it right but it comes at the cost of several months / up to 2-3 years of inconvenience locally for everyone. (…)
There will be no 'two systems'. We're removing skins from core and moving them to separate repositories. That will be the only way from now on. With the exception of the aforementioned 'common' that we need to kill, the skins/ directory will be empty.
The transition period will of course require some additional care, but I don't see how it could take years. The WMF will need to care about it for a total of about two weeks while the deployments roll by (less if we backport the changes, which might be a lot easier with our submodules setup). The people who backport changes would have to deal with it for longer, were it not for the fact that the new way is backwards-compatible with older MediaWikis (set up the skins/ directory the way you described, and it should work back to MW 1.19 at least) and the fact that we rarely need to backport changes to skins anyway.
We haven't committed to this new structure yet, and instead of taking this opportunity to create a mess for years to come, I'd rather take this opportunity to get rid of the mess that is mediawiki/skins altogether and just fold it all back into extensions.
To get the ball rolling: What's the downside of going that route? We have quite a lot to gain in terms of simplicity and compatibility.
Breaking things can be good, but I haven't seen any short or long term benefits so far that would justify it.
I'm really not convinced how it creates more of a mess than what you propose. This structure is consistent with user expectations (of skin developers and sysadmins), already established practices in the MediaWiki community and other projects like CMS-es and forums (again, see [2] and earlier discussion). I think that is a big win.
[2] http://www.gossamer-threads.com/lists/wiki/wikitech/465428#465428
On Thu, 07 Aug 2014 01:41:58 +0200, Bartosz Dziewoński matma.rex@gmail.com wrote:
We have an mediawiki/extensions.git meta repository. To avoid conflicts with MediaWiki core's extensions directory (…)
I always advocate people set up an extensions directory on their disk elsewhere (e.g. next to mediawiki-core, not inside), either as the meta repo clone or as your own container directory with git clones of individual extensions inside of it. Then simply configure $wgExtensionAssetsPath to point at localhost/git/extensions or whatever and require_once in LocalSettings from ../extensions instead.
This is possible with skins in exactly the same way, but instead of $wgExtensionAssetsPath you configure $wgStylePath.
The 'common' directory might be a bit problematic here. I think we should just get rid of it once and for all and put the assets in resources/ where they belong.
I filed a bug to track this and I'm actively working on it.
https://bugzilla.wikimedia.org/show_bug.cgi?id=69277
There is a bit of a problem as to where to put the static assets now; I have a pending patch where I try to introduce a directory for them: https://gerrit.wikimedia.org/r/#/c/155771/ – comments welcome.
On Mon, 28 Jul 2014 22:50:49 +0200, Maarten Dammers maarten@mdammers.nl wrote:
And I assume whatever MediaWiki version this will be packaged into should will include an upgrade script for people who just bump one version?
There is no need for an upgrade script. If you're upgrading using the tarball, then all you need to do is copy a few lines of code from the warning message and paste them into LocalSettings.php.
It looks like this: http://i.imgur.com/A6rOOFZ.png (I have a few custom skins installed in this example).
(The code for this is not merged yet, comments welcome at https://gerrit.wikimedia.org/r/148508.)
This has just happened.
The instructions MediaWiki will display should guide you through. Poke me on IRC if the email I send earlier and the instructions don't help :)
Hi,
I just went on to `git pull --rebase origin master` on getting MW 1.24 master and suddenly I see a "Whoops! The default skin for your wiki ($wgDefaultSkin), vector, is not available."
I have to say that I'm not really interested in modifying the LocalSettings.php just to get a MW working as it used to be.
I do expect when downloading MW it is at least functional and not comes with a message of "Whoops!" your missing something.
The other funny thing, is the message which says: "You can paste the following lines into LocalSettings.php to enable all currently installed skins:" ( empty )
So I should paste an empty message to `LocalSettings.php`, what the hell!!
If you at least provide a composer download for the standard skins, I could go on and do `composer mediawiki/vector-skin` without having the remember the location of some gerrit repo, doing some cryptic git submodule stuff or care about "mediawiki/skins/*" at all.
Cheers
On 8/7/14, Bartosz Dziewoński matma.rex@gmail.com wrote:
This has just happened.
The instructions MediaWiki will display should guide you through. Poke me on IRC if the email I send earlier and the instructions don't help :)
-- Matma Rex
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Exactly what I warned about. Yet another example of poor thinking/execution and exactly what I predicted.
On Thu, Aug 7, 2014 at 12:02 PM, James HK jamesin.hongkong.1@gmail.com wrote:
Hi,
I just went on to `git pull --rebase origin master` on getting MW 1.24 master and suddenly I see a "Whoops! The default skin for your wiki ($wgDefaultSkin), vector, is not available."
I have to say that I'm not really interested in modifying the LocalSettings.php just to get a MW working as it used to be.
I do expect when downloading MW it is at least functional and not comes with a message of "Whoops!" your missing something.
The other funny thing, is the message which says: "You can paste the following lines into LocalSettings.php to enable all currently installed skins:" ( empty )
So I should paste an empty message to `LocalSettings.php`, what the hell!!
If you at least provide a composer download for the standard skins, I could go on and do `composer mediawiki/vector-skin` without having the remember the location of some gerrit repo, doing some cryptic git submodule stuff or care about "mediawiki/skins/*" at all.
Cheers
On 8/7/14, Bartosz Dziewoński matma.rex@gmail.com wrote:
This has just happened.
The instructions MediaWiki will display should guide you through. Poke me on IRC if the email I send earlier and the instructions don't help :)
-- Matma Rex
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Ideally the fallback skin should make it easier to download a default skin (https://www.mediawiki.org/wiki/Category:All_skins is a horrible page to land on). I'm currently trying to find the url for Vector E.g. A link to save this to your skins folder. Either that or we might want to put Vector as a submodule?
PS. https://www.mediawiki.org/wiki/Skin:Vector needs an update.
On Thu, Aug 7, 2014 at 9:18 AM, John phoenixoverride@gmail.com wrote:
Exactly what I warned about. Yet another example of poor thinking/execution and exactly what I predicted.
On Thu, Aug 7, 2014 at 12:02 PM, James HK jamesin.hongkong.1@gmail.com wrote:
Hi,
I just went on to `git pull --rebase origin master` on getting MW 1.24 master and suddenly I see a "Whoops! The default skin for your wiki ($wgDefaultSkin), vector, is not available."
I have to say that I'm not really interested in modifying the LocalSettings.php just to get a MW working as it used to be.
I do expect when downloading MW it is at least functional and not comes with a message of "Whoops!" your missing something.
The other funny thing, is the message which says: "You can paste the following lines into LocalSettings.php to enable all currently installed skins:" ( empty )
So I should paste an empty message to `LocalSettings.php`, what the hell!!
If you at least provide a composer download for the standard skins, I could go on and do `composer mediawiki/vector-skin` without having the remember the location of some gerrit repo, doing some cryptic git submodule stuff or care about "mediawiki/skins/*" at all.
Cheers
On 8/7/14, Bartosz Dziewoński matma.rex@gmail.com wrote:
This has just happened.
The instructions MediaWiki will display should guide you through. Poke me on IRC if the email I send earlier and the instructions don't help :)
-- Matma Rex
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hmm, now i think about that point: The "normal" third party user should download the latest build of MediaWiki via the "tarball installer" [1]. In this packages, Vector (and monobook as well) is still included. So the "normal" third party user won't see any problem with this. The users normally download MediaWiki from git are developers or persons who want to learn MediaWiki development. And (that's my personal point of view), they can figure out, where to get Vector (or some other skin) from and put it into the installations skin folder. And if i run a composer command or git, sorry, but form e it doesn't really matter if i look at the effort that needs to do this.
Just my 2 cents :)
[1] https://www.mediawiki.org/wiki/Download
Freundliche Grüße / Kind regards Florian
-----Ursprüngliche Nachricht----- Von: wikitech-l-bounces@lists.wikimedia.org [mailto:wikitech-l-bounces@lists.wikimedia.org] Im Auftrag von Jon Robson Gesendet: Donnerstag, 7. August 2014 20:29 An: Wikimedia developers Betreff: Re: [Wikitech-l] Moving Vector and MonoBook to separate repositories and what it means for you
Ideally the fallback skin should make it easier to download a default skin (https://www.mediawiki.org/wiki/Category:All_skins is a horrible page to land on). I'm currently trying to find the url for Vector E.g. A link to save this to your skins folder. Either that or we might want to put Vector as a submodule?
PS. https://www.mediawiki.org/wiki/Skin:Vector needs an update.
On Thu, Aug 7, 2014 at 9:18 AM, John phoenixoverride@gmail.com wrote:
Exactly what I warned about. Yet another example of poor thinking/execution and exactly what I predicted.
On Thu, Aug 7, 2014 at 12:02 PM, James HK jamesin.hongkong.1@gmail.com wrote:
Hi,
I just went on to `git pull --rebase origin master` on getting MW 1.24 master and suddenly I see a "Whoops! The default skin for your wiki ($wgDefaultSkin), vector, is not available."
I have to say that I'm not really interested in modifying the LocalSettings.php just to get a MW working as it used to be.
I do expect when downloading MW it is at least functional and not comes with a message of "Whoops!" your missing something.
The other funny thing, is the message which says: "You can paste the following lines into LocalSettings.php to enable all currently installed skins:" ( empty )
So I should paste an empty message to `LocalSettings.php`, what the hell!!
If you at least provide a composer download for the standard skins, I could go on and do `composer mediawiki/vector-skin` without having the remember the location of some gerrit repo, doing some cryptic git submodule stuff or care about "mediawiki/skins/*" at all.
Cheers
On 8/7/14, Bartosz Dziewoński matma.rex@gmail.com wrote:
This has just happened.
The instructions MediaWiki will display should guide you through. Poke me on IRC if the email I send earlier and the instructions don't help :)
-- Matma Rex
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-- Jon Robson * http://jonrobson.me.uk * https://www.facebook.com/jonrobson * @rakugojon
_______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Yeh it's also worth pointing out that the installer does this all effortlessly. So this is really only effecting existing users. That said I wonder if someone could make this a more effortless step. If the default fallback skin said 'If you are administrator please run git submodule update' or 'composer install skin-vector' I think the reaction might be more forgiving?
On Thu, Aug 7, 2014 at 11:46 AM, Florian Schmidt florian.schmidt.welzow@t-online.de wrote:
Hmm, now i think about that point: The "normal" third party user should download the latest build of MediaWiki via the "tarball installer" [1]. In this packages, Vector (and monobook as well) is still included. So the "normal" third party user won't see any problem with this. The users normally download MediaWiki from git are developers or persons who want to learn MediaWiki development. And (that's my personal point of view), they can figure out, where to get Vector (or some other skin) from and put it into the installations skin folder. And if i run a composer command or git, sorry, but form e it doesn't really matter if i look at the effort that needs to do this.
Just my 2 cents :)
[1] https://www.mediawiki.org/wiki/Download
Freundliche Grüße / Kind regards Florian
-----Ursprüngliche Nachricht----- Von: wikitech-l-bounces@lists.wikimedia.org [mailto:wikitech-l-bounces@lists.wikimedia.org] Im Auftrag von Jon Robson Gesendet: Donnerstag, 7. August 2014 20:29 An: Wikimedia developers Betreff: Re: [Wikitech-l] Moving Vector and MonoBook to separate repositories and what it means for you
Ideally the fallback skin should make it easier to download a default skin (https://www.mediawiki.org/wiki/Category:All_skins is a horrible page to land on). I'm currently trying to find the url for Vector E.g. A link to save this to your skins folder. Either that or we might want to put Vector as a submodule?
PS. https://www.mediawiki.org/wiki/Skin:Vector needs an update.
On Thu, Aug 7, 2014 at 9:18 AM, John phoenixoverride@gmail.com wrote:
Exactly what I warned about. Yet another example of poor thinking/execution and exactly what I predicted.
On Thu, Aug 7, 2014 at 12:02 PM, James HK jamesin.hongkong.1@gmail.com wrote:
Hi,
I just went on to `git pull --rebase origin master` on getting MW 1.24 master and suddenly I see a "Whoops! The default skin for your wiki ($wgDefaultSkin), vector, is not available."
I have to say that I'm not really interested in modifying the LocalSettings.php just to get a MW working as it used to be.
I do expect when downloading MW it is at least functional and not comes with a message of "Whoops!" your missing something.
The other funny thing, is the message which says: "You can paste the following lines into LocalSettings.php to enable all currently installed skins:" ( empty )
So I should paste an empty message to `LocalSettings.php`, what the hell!!
If you at least provide a composer download for the standard skins, I could go on and do `composer mediawiki/vector-skin` without having the remember the location of some gerrit repo, doing some cryptic git submodule stuff or care about "mediawiki/skins/*" at all.
Cheers
On 8/7/14, Bartosz Dziewoński matma.rex@gmail.com wrote:
This has just happened.
The instructions MediaWiki will display should guide you through. Poke me on IRC if the email I send earlier and the instructions don't help :)
-- Matma Rex
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-- Jon Robson
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Thu, 07 Aug 2014 20:46:28 +0200, Florian Schmidt florian.schmidt.welzow@t-online.de wrote:
Hmm, now i think about that point: The "normal" third party user should download the latest build of MediaWiki via the "tarball installer" [1]. In this packages, Vector (and monobook as well) is still included. So the "normal" third party user won't see any problem with this. The users normally download MediaWiki from git are developers or persons who want to learn MediaWiki development. And (that's my personal point of view), they can figure out, where to get Vector (or some other skin) from and put it into the installations skin folder. And if i run a composer command or git, sorry, but form e it doesn't really matter if i look at the effort that needs to do this.
Indeed, that was my thinking. Developers can also use MediaWiki-Vagrant which has already been updated to handle the new way of including skins (<3 Gergő and Bryan).
[1] https://gerrit.wikimedia.org/r/#/c/152828/
On Thu, 07 Aug 2014 20:28:59 +0200, Jon Robson jdlrobson@gmail.com wrote:
Ideally the fallback skin should make it easier to download a default skin (https://www.mediawiki.org/wiki/Category:All_skins is a horrible page to land on). I'm currently trying to find the url for Vector E.g. A link to save this to your skins folder.
Yeah, the problem is that currently there really isn't a good landing page. :(
Either that or we might want to put Vector as a submodule?
Personally I wouldn't mind that, but git doesn't exactly make working with submodules easy, and in 90% of cases it's probably simpler not to use them. We should probably have a bigger discussion if we ever want to do that.
PS. https://www.mediawiki.org/wiki/Skin:Vector needs an update.
wctaiwan has already updated it before I got around to it. :)
I consider it rather bad style to launch personal attacks in what should be a technical discussion. In particular when your own arguments basically amounted to a statement that having to execute some git command would be "a pain in the ass". It was to be expected, that there would be some snags. Crying "I told you so" is somewhat less than constructive. I am sure Bartosz is already working on it.
And James, what is your problem? Try running a current MW with the LocalSettings.php from - I don't know - MW 1.16 or something. You expect that to work? Really?
Maybe everybody could cool down a bit and keep thing on a non-personal level? I'd appreciate it.
On 7 August 2014 18:18, John phoenixoverride@gmail.com wrote:
Exactly what I warned about. Yet another example of poor thinking/execution and exactly what I predicted.
On Thu, Aug 7, 2014 at 12:02 PM, James HK jamesin.hongkong.1@gmail.com wrote:
Hi,
I just went on to `git pull --rebase origin master` on getting MW 1.24 master and suddenly I see a "Whoops! The default skin for your wiki ($wgDefaultSkin), vector, is not available."
I have to say that I'm not really interested in modifying the LocalSettings.php just to get a MW working as it used to be.
I do expect when downloading MW it is at least functional and not comes with a message of "Whoops!" your missing something.
The other funny thing, is the message which says: "You can paste the following lines into LocalSettings.php to enable all currently installed skins:" ( empty )
So I should paste an empty message to `LocalSettings.php`, what the hell!!
If you at least provide a composer download for the standard skins, I could go on and do `composer mediawiki/vector-skin` without having the remember the location of some gerrit repo, doing some cryptic git submodule stuff or care about "mediawiki/skins/*" at all.
Cheers
On 8/7/14, Bartosz Dziewoński matma.rex@gmail.com wrote:
This has just happened.
The instructions MediaWiki will display should guide you through. Poke me on IRC if the email I send earlier and the instructions don't help :)
-- Matma Rex
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hi,
And James, what is your problem? Try running a current MW with the LocalSettings.php from - I don't know - MW 1.16 or something. You expect that to work? Really?
Honestly, I don't care about skins, when I download MW I'd expect it to work and not to figure out that I need another two, three or four steps just to have decent user experience.
I want my LocalSettings from MW 1.23 to work with MW 1.24 (we are not talking about an ancient release such as 1.16) without having to study an extra page on mw.org about skins.
Cheers
On 8/8/14, Stephan Gambke s7eph4n@gmail.com wrote:
I consider it rather bad style to launch personal attacks in what should be a technical discussion. In particular when your own arguments basically amounted to a statement that having to execute some git command would be "a pain in the ass". It was to be expected, that there would be some snags. Crying "I told you so" is somewhat less than constructive. I am sure Bartosz is already working on it.
And James, what is your problem? Try running a current MW with the LocalSettings.php from - I don't know - MW 1.16 or something. You expect that to work? Really?
Maybe everybody could cool down a bit and keep thing on a non-personal level? I'd appreciate it.
On 7 August 2014 18:18, John phoenixoverride@gmail.com wrote:
Exactly what I warned about. Yet another example of poor thinking/execution and exactly what I predicted.
On Thu, Aug 7, 2014 at 12:02 PM, James HK jamesin.hongkong.1@gmail.com wrote:
Hi,
I just went on to `git pull --rebase origin master` on getting MW 1.24 master and suddenly I see a "Whoops! The default skin for your wiki ($wgDefaultSkin), vector, is not available."
I have to say that I'm not really interested in modifying the LocalSettings.php just to get a MW working as it used to be.
I do expect when downloading MW it is at least functional and not comes with a message of "Whoops!" your missing something.
The other funny thing, is the message which says: "You can paste the following lines into LocalSettings.php to enable all currently installed skins:" ( empty )
So I should paste an empty message to `LocalSettings.php`, what the hell!!
If you at least provide a composer download for the standard skins, I could go on and do `composer mediawiki/vector-skin` without having the remember the location of some gerrit repo, doing some cryptic git submodule stuff or care about "mediawiki/skins/*" at all.
Cheers
On 8/7/14, Bartosz Dziewoński matma.rex@gmail.com wrote:
This has just happened.
The instructions MediaWiki will display should guide you through. Poke me on IRC if the email I send earlier and the instructions don't help :)
-- Matma Rex
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Actually Im not making personal attacks. I am pointing out the flawed process that is being/was implemented. What should have happened was that skins are migrated to extensions and use the existing structure. Doing that would require a lot of work, and a fairly major overhaul of the existing code. Because that is too much work/too complex/users want to take the "easy" way out the current process was used.
Doing something this critical half baked, which was specifically raised before and ignored, is a BAD idea. I know quite a few users who use GIT checkouts for their wikis. Guess what? this change will screw all of them and be a pain in the ass to fix and maintain such forking. Moving to an extension based system is the correct, logical and long term best solution. But you know what? it wont happen, instead skins will fork into a spaghetti code system that stifles users who want custom skins and causes a LOT more regression/bugs due to divergent code bases.
Ill repeat what I said (knowing it will probably be ignored) If your going to overhaul the skin system do it right and merge them into the existing extension framework dont re-invent the wheel and add more overhead to an already complex system.
On Thu, Aug 7, 2014 at 3:12 PM, James HK jamesin.hongkong.1@gmail.com wrote:
Hi,
And James, what is your problem? Try running a current MW with the LocalSettings.php from - I don't know - MW 1.16 or something. You expect that to work? Really?
Honestly, I don't care about skins, when I download MW I'd expect it to work and not to figure out that I need another two, three or four steps just to have decent user experience.
I want my LocalSettings from MW 1.23 to work with MW 1.24 (we are not talking about an ancient release such as 1.16) without having to study an extra page on mw.org about skins.
Cheers
On 8/8/14, Stephan Gambke s7eph4n@gmail.com wrote:
I consider it rather bad style to launch personal attacks in what should be a technical discussion. In particular when your own arguments basically amounted to a statement that having to execute some git command would be "a pain in the ass". It was to be expected, that there would be some snags. Crying "I told you so" is somewhat less than constructive. I am sure Bartosz is already working on it.
And James, what is your problem? Try running a current MW with the LocalSettings.php from - I don't know - MW 1.16 or something. You expect that to work? Really?
Maybe everybody could cool down a bit and keep thing on a non-personal level? I'd appreciate it.
On 7 August 2014 18:18, John phoenixoverride@gmail.com wrote:
Exactly what I warned about. Yet another example of poor thinking/execution and exactly what I predicted.
On Thu, Aug 7, 2014 at 12:02 PM, James HK <jamesin.hongkong.1@gmail.com
wrote:
Hi,
I just went on to `git pull --rebase origin master` on getting MW 1.24 master and suddenly I see a "Whoops! The default skin for your wiki ($wgDefaultSkin), vector, is not available."
I have to say that I'm not really interested in modifying the LocalSettings.php just to get a MW working as it used to be.
I do expect when downloading MW it is at least functional and not comes with a message of "Whoops!" your missing something.
The other funny thing, is the message which says: "You can paste the following lines into LocalSettings.php to enable all currently installed skins:" ( empty )
So I should paste an empty message to `LocalSettings.php`, what the hell!!
If you at least provide a composer download for the standard skins, I could go on and do `composer mediawiki/vector-skin` without having the remember the location of some gerrit repo, doing some cryptic git submodule stuff or care about "mediawiki/skins/*" at all.
Cheers
On 8/7/14, Bartosz Dziewoński matma.rex@gmail.com wrote:
This has just happened.
The instructions MediaWiki will display should guide you through.
Poke
me on IRC if the email I send earlier and the instructions don't help :)
-- Matma Rex
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
John, switching to extension based skins would have resulted in this EXACT same scenario. Since the only difference here is that the skins are in skins/ instead of extensions/. In both cases the vanilla core git repo would not have the skin checked out and you would still have to clone it in exactly the same way.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
On 2014-08-07, 12:30 PM, John wrote:
Actually Im not making personal attacks. I am pointing out the flawed process that is being/was implemented. What should have happened was that skins are migrated to extensions and use the existing structure. Doing that would require a lot of work, and a fairly major overhaul of the existing code. Because that is too much work/too complex/users want to take the "easy" way out the current process was used.
Doing something this critical half baked, which was specifically raised before and ignored, is a BAD idea. I know quite a few users who use GIT checkouts for their wikis. Guess what? this change will screw all of them and be a pain in the ass to fix and maintain such forking. Moving to an extension based system is the correct, logical and long term best solution. But you know what? it wont happen, instead skins will fork into a spaghetti code system that stifles users who want custom skins and causes a LOT more regression/bugs due to divergent code bases.
Ill repeat what I said (knowing it will probably be ignored) If your going to overhaul the skin system do it right and merge them into the existing extension framework dont re-invent the wheel and add more overhead to an already complex system.
On Thu, Aug 7, 2014 at 3:12 PM, James HK jamesin.hongkong.1@gmail.com wrote:
Hi,
And James, what is your problem? Try running a current MW with the LocalSettings.php from - I don't know - MW 1.16 or something. You expect that to work? Really?
Honestly, I don't care about skins, when I download MW I'd expect it to work and not to figure out that I need another two, three or four steps just to have decent user experience.
I want my LocalSettings from MW 1.23 to work with MW 1.24 (we are not talking about an ancient release such as 1.16) without having to study an extra page on mw.org about skins.
Cheers
On 8/8/14, Stephan Gambke s7eph4n@gmail.com wrote:
I consider it rather bad style to launch personal attacks in what should be a technical discussion. In particular when your own arguments basically amounted to a statement that having to execute some git command would be "a pain in the ass". It was to be expected, that there would be some snags. Crying "I told you so" is somewhat less than constructive. I am sure Bartosz is already working on it.
And James, what is your problem? Try running a current MW with the LocalSettings.php from - I don't know - MW 1.16 or something. You expect that to work? Really?
Maybe everybody could cool down a bit and keep thing on a non-personal level? I'd appreciate it.
On 7 August 2014 18:18, John phoenixoverride@gmail.com wrote:
Exactly what I warned about. Yet another example of poor thinking/execution and exactly what I predicted.
On Thu, Aug 7, 2014 at 12:02 PM, James HK <jamesin.hongkong.1@gmail.com wrote:
Hi,
I just went on to `git pull --rebase origin master` on getting MW 1.24 master and suddenly I see a "Whoops! The default skin for your wiki ($wgDefaultSkin), vector, is not available."
I have to say that I'm not really interested in modifying the LocalSettings.php just to get a MW working as it used to be.
I do expect when downloading MW it is at least functional and not comes with a message of "Whoops!" your missing something.
The other funny thing, is the message which says: "You can paste the following lines into LocalSettings.php to enable all currently installed skins:" ( empty )
So I should paste an empty message to `LocalSettings.php`, what the hell!!
If you at least provide a composer download for the standard skins, I could go on and do `composer mediawiki/vector-skin` without having the remember the location of some gerrit repo, doing some cryptic git submodule stuff or care about "mediawiki/skins/*" at all.
Cheers
On 8/7/14, Bartosz Dziewoński matma.rex@gmail.com wrote:
This has just happened.
The instructions MediaWiki will display should guide you through.
Poke
me on IRC if the email I send earlier and the instructions don't help :)
-- Matma Rex
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Thu, 07 Aug 2014 18:02:58 +0200, James HK jamesin.hongkong.1@gmail.com wrote:
Hi,
I just went on to `git pull --rebase origin master` on getting MW 1.24 master and suddenly I see a "Whoops! The default skin for your wiki ($wgDefaultSkin), vector, is not available."
I have to say that I'm not really interested in modifying the LocalSettings.php just to get a MW working as it used to be.
I do expect when downloading MW it is at least functional and not comes with a message of "Whoops!" your missing something.
On Thu, 07 Aug 2014 21:12:13 +0200, James HK jamesin.hongkong.1@gmail.com wrote:
Honestly, I don't care about skins, when I download MW I'd expect it to work and not to figure out that I need another two, three or four steps just to have decent user experience.
I want my LocalSettings from MW 1.23 to work with MW 1.24 (we are not talking about an ancient release such as 1.16) without having to study an extra page on mw.org about skins.
If you want a stable experience, it is unwise to use the git master to run your wiki. I recommend using the tarballs or checking out release branches.
Straight git master checkout *is* functional; it includes the minimal skin that you're seeing that also displays a (hopefully useful) information screen. If you have concrete suggestions on how to improve that message, I'd love to hear them.
I am sad to have introduced a breaking change, but these are sometimes necessary. I tried to make the transition as painless as possible. Again, I'd love to hear concrete improvement suggestions.
The other funny thing, is the message which says: "You can paste the following lines into LocalSettings.php to enable all currently installed skins:" ( empty )
So I should paste an empty message to `LocalSettings.php`, what the hell!!
That's interesting. Can you share any details about your personal setup, so that I can try to debug this? I have tested this and my MediaWiki installation correctly produces a message that you have no skins installed.
James HK has now submitted a patch to implement Composer support in the Vector skin [1] – somebody more familiar with Composer than me should probably review and merge it, and document how one can actually use this to install the skin.
[1] https://gerrit.wikimedia.org/r/#/c/152927/
On Sat, 09 Aug 2014 03:41:01 +0200, Bartosz Dziewoński matma.rex@gmail.com wrote:
James HK has now submitted a patch to implement Composer support in the Vector skin [1] – somebody more familiar with Composer than me should probably review and merge it, and document how one can actually use this to install the skin.
It has been merged now.
Somebody more familiar with Composer than me should probably update skin installation instructions in various places with a mention of the possibility of using Composer. :)
On 07-08-2014 16:32, Bartosz Dziewoński wrote:
This has just happened.
This is bad.
I do occasional work on Vector. This means I sometimes have to change stuff in core that interacts with Vector as well. This is now impossible because they now live in two different repositories, and I can no longer create a single patch.
I now have to submit two patches and hope they both get merged at the exact same time.
I regard skins as part of core. It may look more organized to split skins off, but core functionality should live in the core repository.
Regards,
But extensions have the exact same "problem". Normally then you first prepare core functions and then change the skin itself (maybe with two patches at the same time referring to each other). So the core patch is merged before the skin patch. It's more work for Vector skin, yes, but i want to ask (really, i don't know this fact): How often this happens?
Freundliche Grüße / Kind regards Florian
-----Ursprüngliche Nachricht----- Von: wikitech-l-bounces@lists.wikimedia.org [mailto:wikitech-l-bounces@lists.wikimedia.org] Im Auftrag von Erwin Dokter Gesendet: Donnerstag, 7. August 2014 22:06 An: Wikimedia developers Betreff: Re: [Wikitech-l] Moving Vector and MonoBook to separate repositories and what it means for you
On 07-08-2014 16:32, Bartosz Dziewoński wrote:
This has just happened.
This is bad.
I do occasional work on Vector. This means I sometimes have to change stuff in core that interacts with Vector as well. This is now impossible because they now live in two different repositories, and I can no longer create a single patch.
I now have to submit two patches and hope they both get merged at the exact same time.
I regard skins as part of core. It may look more organized to split skins off, but core functionality should live in the core repository.
Regards, -- Erwin Dokter
_______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Can we have a note in the installer where it says that skin is missing -- that it has to be included like other extensions with
require_once("$IP/skins/Vector.php");
On Thu, Aug 7, 2014 at 1:05 PM, Erwin Dokter erwin@darcoury.nl wrote:
On 07-08-2014 16:32, Bartosz Dziewoński wrote:
This has just happened.
This is bad.
I do occasional work on Vector. This means I sometimes have to change stuff in core that interacts with Vector as well. This is now impossible because they now live in two different repositories, and I can no longer create a single patch.
I now have to submit two patches and hope they both get merged at the exact same time.
I regard skins as part of core. It may look more organized to split skins off, but core functionality should live in the core repository.
Regards,
Erwin Dokter
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Thu, 07 Aug 2014 22:20:15 +0200, Lojjik L. Braughler llbraughler@gmail.com wrote:
Can we have a note in the installer where it says that skin is missing -- that it has to be included like other extensions with
require_once("$IP/skins/Vector.php");
The installer handles skin differently and this change doesn't cause any problems for it. (There is a set of checked-by-default checkboxes for every available skin during installation.)
Assuming you meant the fallback skin displaying the warning message, it should already display such a message if there is any skin available to be enabled (otherwise it will display general installation instructions). Does that not work for you?
Just using a straight master checkout and had the same LocalSettings, default skin Vector wasn't found and had to check it in to my skins folder. But I wasn't aware at first that it had to be included with a require_once() statement because the message didn't state it. Not a big deal though, I found it eventually :P.
On Thu, Aug 7, 2014 at 5:09 PM, Bartosz Dziewoński matma.rex@gmail.com wrote:
On Thu, 07 Aug 2014 22:20:15 +0200, Lojjik L. Braughler < llbraughler@gmail.com> wrote:
Can we have a note in the installer where it says that skin is missing --
that it has to be included like other extensions with
require_once("$IP/skins/Vector.php");
The installer handles skin differently and this change doesn't cause any problems for it. (There is a set of checked-by-default checkboxes for every available skin during installation.)
Assuming you meant the fallback skin displaying the warning message, it should already display such a message if there is any skin available to be enabled (otherwise it will display general installation instructions). Does that not work for you?
-- Matma Rex
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Thu, 07 Aug 2014 22:05:53 +0200, Erwin Dokter erwin@darcoury.nl wrote:
On 07-08-2014 16:32, Bartosz Dziewoński wrote:
This has just happened.
This is bad.
I do occasional work on Vector. This means I sometimes have to change stuff in core that interacts with Vector as well. This is now impossible because they now live in two different repositories, and I can no longer create a single patch.
I now have to submit two patches and hope they both get merged at the exact same time.
I regard skins as part of core. It may look more organized to split skins off, but core functionality should live in the core repository.
I actually consider this a positive change. Hopefully this will result in fewer unnecessary breaking changes in core skin interfaces, and thus less pain during MediaWiki upgrade for site administrators.
When it is actually necessary to make a breaking change and update the skins, it's not a big problem to synchronise it – if you describe the dependencies in the commit message, you can trust that the people with +2 rights will be smart enough to handle it, really. Feel free to poke me about any such changes.
Le 07/08/2014 22:05, Erwin Dokter a écrit :
I now have to submit two patches and hope they both get merged at the exact same time.
If we had test coverage, we could ensure the skin change is merged after the required change in core. And for wmf/release branches, have the test enforce the relationship by breaking.
But. We have no tests for skins :-/
On 8 Aug 2014 04:23, "Antoine Musso" hashar+wmf@free.fr wrote:
Le 07/08/2014 22:05, Erwin Dokter a écrit :
I now have to submit two patches and hope they both get merged at the exact same time.
The world we should be working towards is one where you'd only have to update the skin. Moving this code out of core I believe will help drive that. Submitting two patches _is_ annoying and this is why I think it will drive improvements to the skin API. :)
On 08/08/14 14:24, Jon Robson wrote:
On 8 Aug 2014 04:23, "Antoine Musso" hashar+wmf@free.fr wrote:
Le 07/08/2014 22:05, Erwin Dokter a écrit :
I now have to submit two patches and hope they both get merged at the exact same time.
The world we should be working towards is one where you'd only have to update the skin. Moving this code out of core I believe will help drive that. Submitting two patches _is_ annoying and this is why I think it will drive improvements to the skin API. :)
This. If it takes two patches, one in the skin, one in core, this seems like a good thing - because then it means the added support will then be available to all the other skins too, including mobile and the skins of various other projects. This is important, because it also means that it should become easier to not just focus on a single skin and ignore everything else (which has long been the case with vector).
While this should be great for third-party projects, even around here, users of monobook who've seen new features released that simply not work on their skin should also benefit, as well as potentially everyone else as well should the time come for a new default skin for Wikimedia, something that will have to happen sooner or later.
-I
I have just updated the [[Manual:Skin configuration]] page on mediawiki.org, which is linked prominently in the warning message. It should actually provide some useful information now. (More improvements or improvement suggestions very welcome!)
https://www.mediawiki.org/wiki/Manual:Skin_configuration
On 07/08/14 14:32, Bartosz Dziewoński wrote:
This has just happened.
The instructions MediaWiki will display should guide you through. Poke me on IRC if the email I send earlier and the instructions don't help :)
Would it be possible to get the common directory out of core/skins/ as well? With that gone, it'd be possible to just link the whole skins directory to a copy of the skins meta repo (like is commonly done with extensions), thus making development work on skins, or even just trying out random ones, a whole lot easier. Currently each skin needs to be individually linked, which gets a bit silly after awhile when the only thing NOT in the meta repository directory is something that was supposed to have been deprecated years ago anyway.
-I
On 8/9/14, 8:41 PM, Isarra Yos wrote:
On 07/08/14 14:32, Bartosz Dziewoński wrote:
This has just happened.
The instructions MediaWiki will display should guide you through. Poke me on IRC if the email I send earlier and the instructions don't help :)
Would it be possible to get the common directory out of core/skins/ as well?
That's https://bugzilla.wikimedia.org/show_bug.cgi?id=69277.
-- Legoktm
wikitech-l@lists.wikimedia.org