To improve the user experience of using and upgrading MediaWiki, Most of MediaWiki should be moved inside of a `/core` folder.
This keeps the root directory (and all sub directories) as "user customizable". This makes it easier to upgrade MediaWiki (most of the time just replace the `/core` folder). It simplifies what a user can modify and ought not modify. It also would give users the ability to upgrade MediaWiki core with Composer (T166956). And even completely exclude the `/core` folder from their repository altogether.
Drupal has done this and it seems to be have been a good move in terms of usability and developer experience. ([[ https://www.drupal.org/node/1327978 | Change Notice ]]) ([[ https://www.drupal.org/node/22336 | Issue ]])
This would involve moving the following files/directories:
* `/docs` → `/core/docs`
* `/extensions` → `/core/extensions`**Problems**
* The "core" extensions would be moved to `/core/extensions`, but a new,# There is no separation of concerns between //my// project (i.e. empty `/extensions` would be created for users to add extensions tomy wiki with it's own custom skins and extensions) and the MediaWiki //application//.
* `/includes` → `/core/includes` # It is not clear what is user-editable and what is not. The only things that are user-editable are:
* `/languages` → `/core/languages` - cache
* `/maintenance` → `/core/maintenance` - extensions
* `/mw-config` → `/core/mw-config` - images
* To preserve backwards compatibility, a `/mw-config` directory should be created win an `index.php` that loads `/core/mw-config/index.php`- skins
* `/resources` → `/core/resources` - composer.local.json
* `/serialized` → `/core/serialized` # If you modify any other folder or files, you may have difficulty upgrading.
* `/skins` → `/core/skins` # 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 ]], * The "core" skins would be moved to `/core/skins`, but a new,then `composer.json` (and `composer.lock`) will be modified. empty `/skins` would be created for users to add extensions toA user will have to merge the changes when upgrading.
* `/tests` → `/core/tests` # There is no easy way to upgrade MediaWiki with Composer.
* `/api.php` → `/core/api.php` # Users who use Composer should be able to exclude MediaWiki from their VCS repository (like you can with `/vendor`)
* Most of the logic should move# If a user executes `composer create-project mediawiki/core` it works properly, but a `/api.php` should continue to exist that loads `/core/api.php` (or the logic could be moved elsewhere).
* `/autoload.php` → `/core/autoload.php`
* `/img_auth.php` → `/core/img_auth.php`there is no way to upgrade using a similar method.
**Solutions**
* Most of the logic should move, but a `/img_auth.php` should continue to exist that loads `/core/img_auth.php` (or the logic could be moved elsewhere)# Move most of MediaWiki into a `/core` folder.
* `/load.php` → `/core/load.php - This would involve moving anything that is not "user-customizable" into that folder (i.e. `/includes`would become `/core/includes`
* `/opensearch_desc.php` → `/core/opensearch_desc.php` - 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).
* Most of - If bundled extensions ought to be upgraded independently of MediaWiki, the logic should moven they can be installed in `/extensions`. If not, but a `/opensearch_desc.php` should continue to exist that loads `/core/opensearch_desc.php` (or the logic could be moved elsewhere)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.
* `/profileinfo.php` → `/core/profileinfo.php` # Create a `mediawiki-app` "wrapper"
* Most of the logic should move, but a `/profileinfo.php` should continue to exist- Would include a starting point `composer.json` that loads `/core/profileinfo.php` (or the logic could be moved elsewhere)would require `mediawiki/core` and put it into the webroot.
* `/thumb.php` → `/core/thumb.php` - 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).
* Most of the logic should move, but a `/thumb.php` should continue to exist that loads `/core/thumb.php` (or the logic could be moved elsewhere).
Other files like `/index.php` can remain as-is since they contain such little amount of code that it is doubtful that they will ever need to be altered. If- Users who use they do zip/tar would not benefit from this, we will need to instruct users to manually update the files (which they already do anyways).
Special care may need to be taken for config files like `phpcs.xml` but we should look at Drupal's example to resolve these issue(s)unless we decided that the zip/tar should use the wrapper as well.