On Sat, 09 Aug 2014 03:41:01 +0200, Bartosz Dziewoński
matma@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
On Thu, 07 Aug 2014 01:41:58 +0200, Bartosz Dziewoński
matma@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
On 08/08/14 14:24, Jon Robson wrote:
On 8 Aug 2014 04:23, Antoine Musso hashar+...@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
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!)
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?
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
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
On 8 Aug 2014 04:23, Antoine Musso hashar+...@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
On Thu, 07 Aug 2014 20:28:59 +0200, Jon Robson jdlrob...@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
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/
--
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
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
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.hongkon...@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
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
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
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
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.
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,
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
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
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
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
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 er...@darcoury.nl wrote:
On 07-08-2014 16:32, Bartosz Dziewoński wrote:
This has
On Thu, 07 Aug 2014 18:02:58 +0200, James HK
jamesin.hongkon...@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
On Thu, 07 Aug 2014 20:46:28 +0200, Florian Schmidt
florian.schmidt.wel...@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
On Thu, 07 Aug 2014 22:05:53 +0200, Erwin Dokter er...@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
On Thu, 07 Aug 2014 22:20:15 +0200, Lojjik L. Braughler
llbraugh...@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
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
On Tue, 29 Jul 2014 13:00:37 +0200, Krinkle krinklem...@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
@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
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
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
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 maar...@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
On Mon, 28 Jul 2014 22:50:49 +0200, Maarten Dammers maar...@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
On Mon, 28 Jul 2014 22:59:40 +0200, John phoenixoverr...@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
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
36 matches
Mail list logo
