Change Details

**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 # 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 [[ https://getcomposer.org/doc/03-cli.md | 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. **Solutions** # Move most of MediaWiki into a `/core` folder. - This would involve moving anything that is not "user-customizable" into that folder (i.e. `/includes`would 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 symlinks for entry points. 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.

**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 # 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 [[ https://getcomposer.org/doc/03-cli.md | 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. **Solutions** # Move most of MediaWiki into a `/core` folder. - This would involve moving anything that is not "user-customizable" into that folder (i.e. `/includes`would 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.

**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 # 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 [[ https://getcomposer.org/doc/03-cli.md | 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. **Solutions** # Move most of MediaWiki into a `/core` folder. - This would involve moving anything that is not "user-customizable" into that folder (i.e. `/includes`would 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 symlinks for entry pointslim 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.