Problems
- There is no separation of concerns between my project (i.e. my wiki with it's own custom skins and extensions) and the MediaWiki application.
- It is not clear what is user-editable and what is not. The only things that are user-editable are:
- cache
- extensions
- images
- skins
- composer.local.json
- composer.lock
- If you modify any other folder or files, you may have difficulty upgrading.
- It is not clear if bundled extensions should be upgraded with MediaWiki or if they ought to be upgraded independently. If it's the former than the extensions the user has installed are mixed in with the bundled extensions.
- If a user uses Composer's CLI, then composer.json (and composer.lock) will be modified. A user will have to merge the changes when upgrading.
- There is no easy way to upgrade MediaWiki with Composer.
- Users who use Composer should be able to exclude MediaWiki from their VCS repository (like you can with /vendor)
- If a user executes composer create-project mediawiki/core it works properly, but there is no way to upgrade using a similar method.
- Because the composer.lock file is shared between the user's project and the application, we are pinning versions in composer.json instead of the proper place which is composer.lock.
Solutions
- Move most of MediaWiki into a /core folder.
- This would involve moving anything that is not "user-customizable" into that folder (i.e. /includeswould become /core/includes
- The /core folder would have it's own composer.json and a read-only subtree split would be created (and maintained with the Ci server).
- The entry points would remain to maintain backwards compatibility, but would be modified to be very simple (i.e. just doing a require_once to a path inside /core). Since these are "user-customizable" the user would be able to alter them if they wanted /core in some other directory.
- To preserve other file paths, we could create relative symlinks that are optional (and would be deleted in a future version).
- If bundled extensions ought to be upgraded independently of MediaWiki, then they can be installed in /extensions. If not, then we would need to support two directories: /core/extensions that the user ought not modify, and /extensions that the user is free to modify.
- Create a mediawiki-app "wrapper"
- Would include a starting point composer.json that would require mediawiki/core and put it into the webroot.
- Would include a web root (/html) and inside of that web root would be core (where MediaWiki would go). Would also include slim entry points / symlinks. The reason we would have to put it in a subfolder is because MediaWiki must be in the webroot, but you cannot put extensions or skins (which also need to be in the webroot) within MediaWiki (which will be blown out on upgrade).
- Users who use the zip/tar would not benefit from this, unless we decided that the zip/tar should use the wrapper as well.