This post by Nemo bis was moved on 2015-03-02. You can find it at Thread:Talk:MediaWiki 1.23/mediawiki login.
I'm seeing a lot of warnings about skin autodiscovery in the error log as I have a number of custom skins running. Is this going to be part of the release, as Manual:Skin autodiscovery isn't ready yet? How do I correct the warning?
Hello, 1.23 should be unaffected. Please ask on talk of Separating skins from core MediaWiki, giving information on the structure of your skins so that it can be considered in the refactor.
Sorry, I haven't written the page yet. I'll do it this week (before the 1.23 release) and it will contain a migration guide (both for skin developers, and for site admins who just want the warnings to shut up) – it's actually rather easy to fix up, basically you need to move the MySkin.php file into the MySkin directory with skin resources (or create one if it doesn't exist), adjusts paths in it if they were relative, add the skin to $wgValidSkinNames in the Myskin.php file and add a
require_once( "$IP/skins/MySkin/Myskin.php" ) to your LocalSettings (similarly to how it's done for extensions).
MediaWiki 1.23 only adds the warnings – if you've acknowledged them and they bother you, then I suppose you could comment-out the line that emits them in Skin.php, in the getSkinNames() method. Skins using autodiscovery will continue working like it did for years in 1.23 LTS and 1.24 (with warnings), and support will only be removed in 1.25 (and 1.27 LTS), giving you plenty of time to migrate.
I added a note on this page (MediaWiki 1.23#Skin autodiscovery deprecated) and created the beginning of the manual page (Manual:Skin autodiscovery, still could be expanded a little bit). I'd really love it if you could test out the process and tell us how it was :)
The changes were pretty straightforward. I made the changes to the four custom skins we have and it looks like the warnings have disappeared and they still work. Thanks!
I find it a bit strange to follow a different casing convention than the default skins, but if I view them as extensions it makes sense.
Thank you, I'm glad you found the guide useful :)
So do I – we will hopefully standardize on something before 1.24 (and hopefully it will be camel-case).
That's great. This autodetection was always a bit irritating from my point of view. Nice to see it go. Thus "Vector" and "Monobook" will have to be invoked explicitly, too.
Yup, we'll probably need some extra magic in the next release to handle this well. We might retain some minimal form of skin autodiscovery for a few versions just to require the four "former core skins" if they're there and are not required explicitly. This has been discussed briefly on https://gerrit.wikimedia.org/r/#/c/135439/ (which is not the very best venue for such a discussion, to be honest).
While I am generally neutral to this change, I must say that at least the current state in the REL1_23 branch is just badly inconsistent: If you use skin autodiscovery for your own skins, MediaWiki bothers you with PHP warnings while the MediaWiki skins themselves still do exactly the same without raising warnings. The according diff reads like a joke.
This is a good example for a feature, which has been merged in the last minute - maybe because it just had to be included -, although it was long not ready.
It is, and no one is happy with the current state – but my project (I'm the driving force behind these changes, with support of several other people; see the project page at Separating skins from core MediaWiki) was always intended to be finished in July/August (in time for 1.24 release) and couldn't possibly be finished now. I have several related code changes pending review right now.
However, I felt it was worthwhile to backport just the deprecation warnings to 1.23 because it is an LTS release, as otherwise LTS users could be somewhat surprised if their skins suddenly disappeared on next upgrade – Mark and Markus agreed and helped me push it through just in time.
1.23 is not released yet, and we can always make amendments in point releases – do you have any suggestions on how this could be handled better?
Reading your project pages I get the point. Nice idea behind it all! :-)
The problem I have with what currently is in the 1.23 branch is that Core skins and custom skins are treated differently in a way that authors/admins are first bothered with a problem and then when you check how the MediaWiki Core itself does it - which if not that should be the right way to do things? - then you see that the Core does exactly the same without being yelled at.
You obviously don't want to deprecate autodiscovery for the core skins (otherwise you would not need the exception in the diff I linked to). For me it would already be OK, if just the Core skins would no longer use autodiscovery. Then you can go to the skin authors and tell them to adjust, but with the current state telling them to change while MediaWiki itself did not, it's just pointless.
If you're still interested – the core skins don't use autodiscovery now (on master). :)
Changes to Common.css and Vector.css don’t affect all pages.
The ‘Preferences’ and ‘Login’ pages on 1.23.5 are not affected by any changes I make to Common.css and Vector.css. I didn’t have this problem on 1.22.
Others have tested it and report the same result. Is there any solution to this?
Currently not except for creating a custom skin or adapting the standard skins at server level (be cautious when upgrading in the latter case). This behaviour was introduced with 1.19.20, 1.22.12 and 1.13.5 so solve bugzilla:70627. Bug bugzilla:71621 was opened to address your very issue (you are not alone) but this is currently getting anywhere as you can see. Still searching for solutions here.
See also Thread:Project:Support desk/How to add custom CSS via LocalSettings.php (2). Note that this require someone to edit the CSS and JS for the site on files on the server, rather than just editing MediaWiki pages.
This page is not palatable at all, even compared to MediaWiki 1.22. We need at least a couple images and at least the sections in "What's new" need a more positive, human-readable prose.
Additionally, the links to bugs and patches are ugly and inconsistent.
Forgiveness if this has been beat to death. Current host does not allow proc_open() and it appears this release calls for it. Recent previous versions (I started with 1.22.6) didn't seem to have a problem. Currently it doesn't appear like I can generate thumbs for my media files. Halp.