Talk:MediaWiki 1.26

Mysterious

It's quite mysterious how most of the bullets here are of interest for normal sysadmins. Thanks for adding them anyway, they can be rewritten or removed later. --Nemo 08:18, 30 August 2015 (UTC)

The current version seems ok to me; nothing superfluous on there, if you ask me. --88.130.96.6 19:32, 28 September 2015 (UTC)

Release schedule : 2015-11-25 Confirmed ? And decisions about the included extensions ?

Hello,

Is the 2015-11-25, the announced release schedule, confirmed ?

And what are the kind of differences to be expected, apart from the extensions that are present in the extensions folder in :

https://releases.wikimedia.org/mediawiki/1.25/mediawiki-1.25.3.tar.gz

and which are not present in :

https://tools.wmflabs.org/snapshots/builds/mediawiki-core/mediawiki-latest.tar.gz 

Theses extensions are :

• Cite
• CiteThisPage
• ConfirmEdit
• Gadgets
• ImageMap
• InputBox
• Interwiki
• LocalisationUpdate
• Nuke
• ParserFunctions
• PdfHandler
• Poem
• README
• Renameuser
• SpamBlacklist
• SyntaxHighlight_GeSHi
• TitleBlacklist
• WikiEditor

By the way, where is built the decision process about the extensions included in the different releases ?

Thx.

--Dieudo (talk) 15:27, 25 November 2015 (UTC)

Yes, the release has just happened, 1.26.0 is there. IIRC, the snapshots do not contain extensions. The extensions, which are included in the 1.26 release, are the same as those included in 1.25. They have been updated, but they are still all there, none got removed, and also none got added. --88.130.109.128 21:08, 25 November 2015 (UTC)

Thank you for your answer. A question remains for me. I guess there was a decision process taking place somewhere about which extension to include. Is it accessible ? And if yes where is it ? --Dieudo (talk) 07:23, 26 November 2015 (UTC)

Same question for the skins. Thx. --Dieudo (talk) 08:45, 26 November 2015 (UTC)

For the skins there has been a discussion before the last batch got removed (which was a year or so ago). I don't remember for the extensions (for addition in this case), but I expect the same here. The mailing lists or mediawiki.org should be the location where something like that should have taken place. --88.130.80.169 20:12, 26 November 2015 (UTC)

Minimum Password Length

The minimum password length is now 8 (eight) characters. I can't find this mentioned in the release notes / change log.

Plain install disabled skins

Hello,

I recently installed MW 1.26.0 stable by downloading the https://releases.wikimedia.org/mediawiki/1.26/mediawiki-1.26.0.tar.gz archive.
During installation I am asked what Skins to enable etc. My new LocalSettings.php (created from installer) has wgDefaultSkin set and wfLoadSkin entries as shown below.

When I open Main_Page I can see that the 4 default skins are disabled. Why is this and how can it be that just using a default installer ends up like this? Are there any other places a skin has to be enabled besides in LocalSettings.php as shown below?

   cologneblue / CologneBlue (disabled)
   modern / Modern (disabled)
   monobook / MonoBook (disabled)
   vector / Vector (disabled)

## Default skin: you can change the default skin. Use the internal symbolic
## names, ie 'vector', 'monobook':
$wgDefaultSkin = "vector";

# Enabled skins.
# The following skins were automatically enabled:
wfLoadSkin( 'CologneBlue' );
wfLoadSkin( 'Modern' );
wfLoadSkin( 'MonoBook' );
wfLoadSkin( 'Vector' );

Adding a skin with wfLoadSkin( 'SkinName' ); is all you have to do in order to make it usable.

I am not fully into the logic, which the installer uses at that place, but only so much: The lines, which you have posted, in fact enable the four skins and make Vector the default. Btw. you should not disable all skins, as you will need at least one to view the wiki. By default, that is Vector. Should all skins be disabled anyway (which is a configuration error that should be fixed), then a very minimal skin called Fallback will be used. --88.130.80.169 20:16, 26 November 2015 (UTC)

AuthPlugin::initUser() [...] should no longer replace the passed User object.

Ok, this breaks things. Basically now extension can't in any way modify the User after it is inserted into database, but before signup is "completely completed" in AddNewAccount.

One of my extensions modified username (it would be too late to do it in AddNewAccount) and needed to know user ID (it wasn't known before addToDatabase()). Any changes to User in LocalUserCreated() hook will be overwritten by $u->saveSettings() inside LoginForm::initUser. Will have to subclass LoginForm in this extension now... Edward Chernenko (talk) 01:36, 1 December 2015 (UTC)

You may want to look into AuthManager, then, which is bringing more changes to how authentication works in MediaWiki (see also this explanation of how things are generally going to work). If you have a usecase that's not going to be supported, it's not too late to make a case for supporting it. Anomie (talk) 17:45, 8 December 2015 (UTC)