Page MenuHomePhabricator

Allow the path to the vendor directory to be customized within MediaWiki
Open, Needs TriagePublic

Description

Problem
Composer allows the path to the vendor directory to be customized. A common practice (and security precaution) is to put the vendor directory outside of the webroot.

However, there are many places where this path is hardcoded:

Solution
Perhaps a new constant, similar to MW_CONFIG_FILE that would allow the customization of the config file?

Event Timeline

Change 433719 had a related patch set uploaded (by Dbarratt; owner: Dbarratt):
[mediawiki/core@master] Allow the vendor directory to be configured.

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

I found an alternative way to do this, we could set the autoloader-suffix to something like MediaWiki then we can just check to see if the ComposerAutoloaderInitMediaWiki class exists, and if you need to retrieve the autoloader, you could do so by executing ComposerAutoloaderInitMediaWiki::getLoader().

This would require a change to MediaWiki as well as MediaWiki-Vendor but I think it would work well.

We could technically just check to see if Composer\Autoload\ClassLoader exists, but without setting the autoloader-suffix, there isn't a way to retrieve the autoloader. It doesn't look like we are using Composer's autoloader anywhere, so this is an acceptable alternative.

Previous Art: https://github.com/drupal/drupal/blob/4ecf7cb1cbb9b048a434c713e86200cba2c2d06f/core/composer.json#L224

Upon further reflection, I think the constant is the best option, it is similar to what's already being done and it doesn't require someone to have config in their root composer.json that has to be consistant with core, so having the constant is overall less brittle than attempting to load the autoloader by a specific class name, and I don't like the idea of removing the ability to return the autoloader instance, so I'm going to stick with what is there. :)

Vvjjkkii renamed this task from Allow the path to the vendor directory to be customized within MediaWiki to ztcaaaaaaa.Jul 1 2018, 1:09 AM
Vvjjkkii removed dbarratt as the assignee of this task.
Vvjjkkii triaged this task as High priority.
Vvjjkkii updated the task description. (Show Details)
Vvjjkkii removed subscribers: gerritbot, Aklapper.
CommunityTechBot renamed this task from ztcaaaaaaa to Allow the path to the vendor directory to be customized within MediaWiki.Jul 2 2018, 4:05 PM
CommunityTechBot assigned this task to dbarratt.
CommunityTechBot raised the priority of this task from High to Needs Triage.
CommunityTechBot updated the task description. (Show Details)
CommunityTechBot added subscribers: gerritbot, Aklapper.

Is this *strictly* necessary to make https://packagist.org/packages/davidbarratt/mediawiki work? (I mean it currently requires this patch):

`
radziecki> composer init --name='saper/mediawiki-test' --description='Testing MediaWiki as a composer dependency' --stability=dev -n
radziecki> composer require davidbarratt/mediawiki
Using version dev-master for davidbarratt/mediawiki
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Installation request for davidbarratt/mediawiki dev-master -> satisfiable by davidbarratt/mediawiki[dev-master].
    - davidbarratt/mediawiki dev-master requires mediawiki/patches ~1.0 -> no matching package found.

`

Is this *strictly* necessary to make https://packagist.org/packages/davidbarratt/mediawiki work? (I mean it currently requires this patch):

I haven't looked at this in a long time, but I think so. I was experimenting with requiring MediaWiki as a dependency of another project, but MediaWiki expects the vendor directory to be in its own directory.

This task does not describe a problem. It describes something that is possible elsewhere and not possible here. Please explain why it matters for MediaWiki.

@dbarratt: Could you please answer the last comment? Thanks in advance!

Please explain why it matters for MediaWiki.

This is a subtask of T166956. I think that task describes the problem fairly well. If that isn't something we want to support then feel free to decline both. Arguably it only effects 3rd party wikis and the developer experience of them, unless we also want to resolve T178137, in which this would be my preferred solution.