Fri, Nov 17
Mon, Nov 6
@Paladox, I've got another issue: In BlueSpice Version 3 we wanted to split the ExtJS Application Framework from the BlueSpiceFoundation (BSF) extension and make a dedicated extension ("ExtJSBase"). Still BSF defines some RL modules that depend on ExtJSBase (even though it doesn't really invoke them). Now some RL-Test crash . I've tried to add the dependency to the CI configuration but it looks like I did something wrong . Can you help me with that? Do I need to add ExtJSBase as a dependency to all other extensions and skins as well?
The error seems to be gone. Probably just some mismatch during the decoupling process.
Fri, Oct 27
My team is working on splitting up BlueSpiceExtensions repo in seperate repos. We already moced BlueSpiceExtensions/Readers to BlueSpiceReaders . Now I often get the error 
Oct 20 2017
Oct 18 2017
Oct 13 2017
Sep 25 2017
Sep 22 2017
@Anomie Thanks for your quick reply! The MediaWiki Stakeholder group is actually working on an appropriate replacement for Extension:LdapAuthentication. It's likely to be a combination of Extension:PluggableAuth and Extension:PuggableSSO (plus some other extensions :) )
Is there any documentation on when and how to use "LdapPrimaryAuthenticationProvider"? On the official extension page I did not find any information about it.
@Raymond Sorry for the mess I've created with the first six extensions. I've merged them all now. Can you take care of the "mediawiki-extensions.txt"? I promise next time I'll be more careful.
Sep 21 2017
As extension.jsonallows to invoke the composer autoloader ("load_composer_autoloader": true) you can already make use of composers classmap feature.
Sep 19 2017
Sep 18 2017
Sep 14 2017
Sep 13 2017
I don't mean that this should be implemented in Extension:Configure, but the other way round. Having a detailed description of particular configuration options (like a description, data type, possible values, ...) is the first step to build a user interface that provides proper input fields (e.g. a "Namespace-Selector") to modify them. At the moment Extension:Configure does exact that. Unfortunately it is broken with MW 1.29 and I believe, that if someone is going to change that, the new/next version of Extension:Configure should probably use the available information from the extension registry. Ideally an extension should be allowed to provide a custom input type. A mapping between input type and configuration would be needed though
Sep 12 2017
Is this something Extension:Configure should be build upon? The extension page tells that it is not compatible with MW1.29. Does anybody know whether the author already works on this?
@Legoktm thanks for clarification. Will "load_composer_autoloader" : true in extension.json then be dropped?
Sep 11 2017
Sep 7 2017
Sep 6 2017
Sep 4 2017
Sep 1 2017
Aug 31 2017
From a third party user and extension developer perspective I'd be totally okay with PHP7 as requirement.
Regarding the question of how extensions should use namespaces:
Aug 11 2017
@Tgr Is a namespace convention like MediaWiki\Extensions\<extension name> or MediaWiki\Skins\<skin name> somewhere documented? Or better are there any examples of extensions that already do use such namespaces? Background of my question is, that the BlueSpice-team is going to use namespaces (and composer based PSR-4 autoloading) for future development. And we are still discussing about conventions. I want our new code to be as close to MediaWiki conventions as possible.
Aug 9 2017
- Good use of the MediaWiki framework (e.g. using framework provided functions instead of native PHP or external library functions)
Aug 2 2017
Jul 31 2017
Jul 28 2017
Jul 21 2017
Jul 19 2017
Jul 18 2017
Awesome, thank you. Really the double quotes?
Jul 17 2017
@Paladox I test only with MediaWikiCore@REL1_27.