Home
This contains an explanation of how the package manager works and what it has to offer.
- Installing Extensions
- Updating Extensions
- Checking for Updates
- Global Flarum Update
- Patch-Minor Flarum Updates
- Major Flarum Update
- Flarum Updates (global, minor, major)
There are some obstacles that need to be taken care of before this can be used.
The relevant machine web user needs to have permissions to read and write to: vendor, composer.json, composer.lock and storage. Right now a warning shows up when this is not the case, this should preferably be changed to mention only the files/dirs where permissions are lacking instead of all of them.
In development environments (and production in rare scenarios) there should a path repository to a directory containing (mostly dev) packages, the path to this directory must be changed to an absolute path otherwise composer will have trouble running any command. Additionally the path repository by default has higher priority, so requiring an extension that exists in that repository will probably fail, unless a *@dev constraint is specified, in which case the package manager should not be used for dev purposes anyway.
There is currently now hint of any of this in the package manager UI.
Each one of the features listed above is basically a composer command or two, and there are common actions/common behaviour between them all.
- Restricting access to the admin.
- Validating the provided package name or the extension id if given.
- Erroring out if installing an existing extension, updating or removing a non existing extension ...etc
- Running the command. This auto logs the output.
- Erroring out on command failure.
- Dispatching an event.
- If running an update:
- Clear Cache.
- Run Migrations.
- Publish Assets.
- Run an update check, and log any extensions that didn't update to their latest versions in the update process.
Considering this is still experimental and especially for the sake of easier support, each command output is logged to storage/logs/composer just like the flarum error logs, allowing to go back and see what happened during a command execution.
When a composer command fails (recognised by the exit code), an exception is thrown containing a reason guessed by the exception based on the command output text. Guessed causes render into proper explanatory alert messages on the frontend.
This executes the command composer outdated -D --format json which checks for updates of packages directly required in the root composer.json and outputs the results in JSON format. Only packages marked as semver-safe-update and update-possible by composer are displayed.
The information about the last update check is saved into a JSON setting.
Simply runs the command command update --prefer-dist --no-dev -a --with-all-dependencies, useful for updating all packages.
This changes directly required package versions to * and then executes the command command update --prefer-dist --no-dev -a --with-all-dependencies.
This changes directly required package versions to *, changes core to the latest major version requirement and then executes the same command above. Upon failure, it can be correctly guessed that some extensions are not compatible with the new major version, the exception details will include an array of extension package names that are not compatible, and it'll be rendered in the frontend, with the ability to run a composer why-not flarum/core 2.0 for more details.
Information about the last updates ran are saved in a last_update_run JSON setting, which can contain an array of extension package names that didn't update to their latest version in the process, this is rendered in the frontend as warning icon buttons on the extension items, clicking on them will execute a composer why-not, displaying the details of the failure in a modal.
