Change 148424 had a related patch set uploaded by Bartosz Dziewoński:
Define fallback skin using $wgFallbackSkin instead of hardcoding Vector

https://gerrit.wikimedia.org/r/148424

Change 148508 had a related patch set uploaded by Bartosz Dziewoński:
Use a special fallback skin when selected skin is unavailable

https://gerrit.wikimedia.org/r/148508

Change 148424 merged by jenkins-bot:
Define fallback skin using $wgFallbackSkin instead of hardcoding Vector

https://gerrit.wikimedia.org/r/148424

(The second patch is still pending.)

Change 148508 merged by jenkins-bot:
Use a special fallback skin when selected skin is unavailable

https://gerrit.wikimedia.org/r/148508

Whee!

Close, but no cigar. Fallback need to works automatically in the installer (solved with I7b8bd77f5868af2ccf464e48db771f2e8e0472ff) but also after the installation without explicit inclusion of the Vector skin (bug 70114, bug 70222).

Sorry, but I don't understand what the problem is.

Bug 70114, as far as I can see, is entirely unrelated. It seems to be some issue with Vagrant getting confused and not MediaWiki itself. I definitely don't see what makes it a dependency of this bug.

Bug 70222 seems to be about command-line installer not enabling the Vector skin even if it's present, which then (correctly) results in the fallback skin, added per this bug, being displayed.

To recap, the "fallback skin" is what you're seeing when you get the "Whoops!" message.

I have added two bugs and reopened this bug because I have a need to document all issues related to automatic skin discovery and fallback. This is IMHO the right bug to do it (no need for an extra tracking bug or something).

If current fallback would be working, we would not have bug 70222. Bug 70114 is related to the skin autodiscovery/fallback issues, but the problem here lies most probably in the packaging of that particular Vagrant instance; therefore I have moved it to the Vagrant components but added as a dependency here.

Here is my rationale for what I believe would constitute a new better fallback/autodiscovery mechanism:

1. We have lost some crude form of skin autodiscovery, namely there was a list of skins that was hardcoded and they were tried one by one.

2. The only thing left is now $wgDefaultSkin settings, that in a typical git checkout points to a non-existing skin. We have some kind of workaround in the WebInstaller to switch to Vector if present.

3. I believe we need now a new way of autoconfiguring skins, which should be something more or less as follows:

(A) Define set of paths ($IP/w/skins/ $ip/w/skins-ext, whatever, maybe also php_includes) where we look for skin components.

(B) Try to dynamically include some conventional names if files exist (SkinName/SkinName.php or something like that).

(C) The list of $wgValidSkinNames[] gets populated either by enumeration code outside of the skin (my favourite now) or by the skin initialization code themselves.

(D) This way we have a potential list of candidate skins for the default.

(E) If Vector is not present, one of the present skins should be the new default one.

(F) Even if Vector is present, we might think of some other, pre-installation mechanisms to say, *This is my default skin*

(G) All of above should happen somewhere around includes/Setup.php and not in the installer (that's why I don't think "Installer" is the right component for the bug 70222).

(H) The WebInstaller picks the best default for itself.

(I) The installer offers skins to the end-user (this is bug 68331).

(I) Installer adds then appropriate require_once() code to the LocalSettings.php to all skins that are autodetected (this is bug 70222).

So some decent fallback/autodiscovery *is* needed to solve bug 70222 and bug 68331; if there is any issue in the Vagrant packaging with skin detection we should know that as well.

Acually (A),(B),(C) are already covered by findExtensions from WebInstaller.php (gerrit change 138652) so maybe this should be generalized (for all installers/setup code) and we need a sensible default skin selection or fallback.

I think that some independent MediaWiki distributions (BlueSpice from HalloWelt comes to my mind) could just ship some different default skins and use them for the installer as well. (Although the have http://www.blue-spice.org/de/produkte/packages/flexiskin/ that goes one step further).

(Adding Markus Glaser to CC)

There isn't, and there will not be, any form of skin autodiscovery outside of the installer or a hypothetical wiki configuration manage (unless someone else than me is willing to implement and maintain that). There already is a working skin autodiscovery mechanism in the installer that should be reasonably reusable should someone want to work on that. If you want to request it, please file a separate bug.

This bug was about creating a fallback skin and this has been implemented; I'm closing it back.