This is a feature which would be great to add, but we will need to write that in Mautic itself, it isn’t a feature that comes with the integration.
The WIP PR to allow the install/uninstall of plugins can be found here:
mautic:4.x ← dennisameling:marketplace-installation-feature
opened 12:27PM - 10 Oct 21 UTC
<!-- ## Which branch should I use for my PR?
Assuming that:
a = current ma… jor release
b = current minor release
c = future major release
* a.x for any features and enhancements (e.g. 4.x)
* a.b for any bug fixes (e.g. 4.0, 4.1, 4.2)
* c.x for any features, enhancements or bug fixes with backward compatibility breaking changes (e.g. 5.x) -->
| Q | A
| -------------------------------------- | ---
| Bug fix? (use the a.b branch) | 4.1
| New feature/enhancement? (use the a.x branch) | yes
| Deprecations? | no
| BC breaks? (use the c.x branch) | no
| Automated tests included? | WIP
| Related user documentation PR URL | mautic/mautic-documentation#...
| Related developer documentation PR URL | https://github.com/mautic/developer-documentation-new/pull/10
| Issue(s) addressed | Fixes #...
<!--
Additionally (see https://contribute.mautic.org/contributing-to-mautic/developer/code/pull-requests#work-on-your-pull-request):
- Always add tests and ensure they pass.
- Bug fixes must be submitted against the lowest maintained branch where they apply
(lowest branches are regularly merged to upper ones so they get the fixes too.)
- Features and deprecations must be submitted against the "4.x" branch.
-->
#### Description:
In Mautic 4.0.0, the Marketplace was added as read-only beta. This PR will add the functionality to either install or remove plugins from Mautic's UI or CLI 🎉
Some key info:
- We add `composer/composer` as a dependency to Mautic itself. This way, we can control the version of Composer we use. Next to that, some hosting environments have different PHP versions in the CLI and webserver, so by running Composer in-process we can be sure that we run the same PHP version that Mautic runs in
- Bumped `friendsofphp/php-cs-fixer` to 2.19.2 as that version supports `composer/xdebug-handler` 2.0.0 and higher, which is needed by the `composer/composer` package. Proper PR which includes code style updates: https://github.com/mautic/mautic/pull/10519
- Explicitly defined Mautic's version in `app/composer.json`. This is needed for local development environments to work correctly, otherwise it's not possible to install plugins using Composer (will add some additional info/explanation later).
You can already run `php bin/console mautic:marketplace:install shinde-rahul/helloworld` which will install the helloworld plugin into the `plugins` folder.
To do:
- [x] Automatically clear cache after plugin installation/removal
- [x] Add automated tests
- [x] Add UI functionality for installing plugins (we can use our new `Mautic\MarketplaceBundle\Service\Composer` service for that)
- [x] Create a `composer.json` that we can include in Mautic's installation ZIP (it's currently excluded in the build process). We need to decide if we want to include dev dependencies (php-cs-fixer, PHPSTAN, etc.) in it as well
- [x] Create developer docs (https://github.com/mautic/developer-documentation-new/pull/10)
- [ ] Create end-user docs (ping Favor for that)
- [x] Set up allowlist and parse it in the Marketplace (https://github.com/mautic/marketplace-allowlist)
- [ ] Ensure that Mautic installs stable plugins only (or provide a dropdown to select version) - IIRC from testing, our current Composer config is set up in such way that doesn't prefer stable packages so will install dev/beta versions of plugins which we probably don't want. But will need to re-test this
- [ ] Bundle a `composer.phar` with Mautic - updating Mautic through the UI/CLI has changed slightly in this PR. We still overwrite all files from the update ZIP file, except for the vendor folder and composer.json/composer.lock. Otherwise we would just overwrite all of the user’s installed plugins on each Mautic update :sweat_smile: In the PR I’m already adding `composer/composer` as a dependency to Mautic itself. However, this becomes problematic when it tries to update `composer/composer` itself and things break horribly. Hence the suggestion for adding `composer.phar` as a “standalone” executable
- [ ] Add the new plugin events that Alan shared in https://github.com/mautic/mautic/pull/10518#issuecomment-990419709
- [ ] Officially deprecate updating Mautic through the UI (update the docs accordingly), and remove it in M5, in favor of `composer update`.
- [ ] Update release leader doc to bump the Mautic (`mautic/core-lib`) version on every Mautic update. Otherwise plugins can’t be installed if they depend on a minimum `mautic/core-lib` version
- [ ] Fill the allowlist with plugins that we tested manually with Mautic https://github.com/mautic/marketplace-allowlist
- [ ] Create guidelines for developers submitting new plugins to the allowlist
- [ ] Update the old developer docs portal for the Marketplace
<!--
Please write a short README for your feature/bugfix. This will help people understand your PR and what it aims to do. If you are fixing a bug and if there is no linked issue already, please provide steps to reproduce the issue here.
-->
#### Steps to test this PR:
<!--
This part is really important. If you want your PR to be merged, take the time to write very clear, annotated and step by step test instructions. Do not assume any previous knowledge - testers may not be developers.
-->
1. Load up [this PR](https://mautibox.com)
2.
<!--
If you have any deprecations, list them here along with the new alternative.
If you have any backwards compatibility breaks, list them here.
-->
<a href="https://gitpod.io/#https://github.com/mautic/mautic/pull/10518"><img src="https://gitpod.io/button/open-in-gitpod.svg"/></a>
We are planning to include this in the 4.2 release at the end of February.
2 Likes
