Page MenuHomePhabricator

Ingomueller-net (Ingo Müller)
User

Projects

User does not belong to any projects.

Today

  • Clear sailing ahead.

Tomorrow

  • Clear sailing ahead.

Monday

  • Clear sailing ahead.

User Details

User Since
Nov 4 2015, 11:29 AM (214 w, 3 d)
Availability
Available
LDAP User
Unknown
MediaWiki User
Ingomueller-net [ Global Accounts ]

Recent Activity

Dec 16 2015

Ingomueller-net added a comment to T117856: composer/installers and wfLoadSkin do not assume the same path ('skin-name' vs. 'SkinName').

I guess it does the job. However it makes the task of extension developers more error-prone. For the very least, it should be documented clearly (here?).

Dec 16 2015, 10:36 AM · MW-1.27-release (WMF-deploy-2016-01-12_(1.27.0-wmf.10)), Metrolook, Vector, MediaWiki-skins-Slate, Patch-For-Review, MediaWiki-Configuration, Composer
Ingomueller-net added a comment to T61872: Add mechanism to prevent autoloading of Composer installed extensions via LocalSettings.php.

@saper: the problem with autoloading are use cases where the code of many extensions/skins should be deployed, but only part of them should actually be used. See the "wikifarm" use case here and here. If extensions/skins do not autoload (as in calling wfLoadExtension themselves), then one can choose in his/her LocalSettings.php, which ones one wants (using require_once or wfLoadExtension as appropriate for the extension in question).

Dec 16 2015, 10:32 AM · WorkType-NewFunctionality, Composer, MediaWiki-General

Nov 5 2015

Ingomueller-net added a comment to T88596: Improving extension management.
Nov 5 2015, 9:59 PM · Wikimedia-Hackathon-2018, MediaWiki-Configuration, TechCom-RFC
Ingomueller-net added a comment to T88596: Improving extension management.

As seen on the github issue, when I explained what wiki farms need from
composer -- enabling or disabling extensions based on the wiki being
used from a single code base -- the scenario was dismissed.
The alternative suggested was to have a different mediawiki installation
for every wiki.
With the developers of composer being unwilling to adapt it to
multi-site use cases like a wiki farm, I agree with the developers:
composer isn't suited for managing MediaWiki extensions.

Nov 5 2015, 9:56 PM · Wikimedia-Hackathon-2018, MediaWiki-Configuration, TechCom-RFC
Ingomueller-net added a comment to T88596: Improving extension management.

Thanks for the explanation! Is this documented somewhere? Since the mechanism is already used in REL1_25, which is out, it would be good to have documentation for it...

Nov 5 2015, 3:54 PM · Wikimedia-Hackathon-2018, MediaWiki-Configuration, TechCom-RFC
Ingomueller-net added a comment to T88596: Improving extension management.

How does the plugin know which composer.jsons to take into account? Does the admin have to populate the include property in his composer.json manually or will the composer.local.json be generated somehow?

Nov 5 2015, 2:24 PM · Wikimedia-Hackathon-2018, MediaWiki-Configuration, TechCom-RFC
Ingomueller-net added a comment to T61872: Add mechanism to prevent autoloading of Composer installed extensions via LocalSettings.php.

I am with @JanZerebecki and @bd808: To me it looks like disabling some extensions selectively is attacking the problem at the wrong end. I think that an extension should not be loaded (in the sense of wfLoadExtension) when it is installed with composer. In particular, this means that composer.json should not autoload the file ExtensionName.php. Rather should composer only be used to merely install the files, then the extension would be activated in LocalSettings.php using wfLoadExtension('ExtensionName') or require_once "$IP/extensions/ExtensionName/ExtensionName.php".

Nov 5 2015, 2:06 PM · WorkType-NewFunctionality, Composer, MediaWiki-General
Ingomueller-net added a project to T61872: Add mechanism to prevent autoloading of Composer installed extensions via LocalSettings.php: Composer.
Nov 5 2015, 10:44 AM · WorkType-NewFunctionality, Composer, MediaWiki-General
Ingomueller-net added a project to T467: RfC: Extension management with Composer: Composer.
Nov 5 2015, 10:43 AM · Patch-For-Review, Proposal, Composer, TechCom-RFC
Ingomueller-net added a project to T117856: composer/installers and wfLoadSkin do not assume the same path ('skin-name' vs. 'SkinName'): Composer.
Nov 5 2015, 10:26 AM · MW-1.27-release (WMF-deploy-2016-01-12_(1.27.0-wmf.10)), Metrolook, Vector, MediaWiki-skins-Slate, Patch-For-Review, MediaWiki-Configuration, Composer
Ingomueller-net created T117856: composer/installers and wfLoadSkin do not assume the same path ('skin-name' vs. 'SkinName').
Nov 5 2015, 10:24 AM · MW-1.27-release (WMF-deploy-2016-01-12_(1.27.0-wmf.10)), Metrolook, Vector, MediaWiki-skins-Slate, Patch-For-Review, MediaWiki-Configuration, Composer
Ingomueller-net added a comment to T88596: Improving extension management.

I just thought of an argument why using composer and another dependency manager at the same time might be a bad idea, at least if they are agnostic to each other.

Nov 5 2015, 9:31 AM · Wikimedia-Hackathon-2018, MediaWiki-Configuration, TechCom-RFC

Nov 4 2015

Ingomueller-net added a comment to T88596: Improving extension management.

@MarkAHershberger, can you be precise about what was the argument against using composer only in the discussion on github?

Nov 4 2015, 10:46 PM · Wikimedia-Hackathon-2018, MediaWiki-Configuration, TechCom-RFC