Installation of plugins is broken in Mautic package
-
@dsp76 Currently, the only option is the good old "download zip and upload it". Alternatively, you can also wget it. For the first way:
As a user with the correct role, switch to the settings view of your mautic instance on Cloudron.
Switch to File Manager
From here to plugins
And then upload your zip.
Go to the Terminal (see the first screenshot or use the shortcut directly from the file manager window), change the directory to Plugins (cd /app/data/plugins/). Unzip the zip file, delete it and change the owner of the new files (chown -R www-data: NewUploadedPluginBundle).
It is recommended to clear the cache (https://docs.cloudron.io/apps/mautic/ sudo -E -u www-data php /app/code/bin/console cache:clear)
That's what I remember from my last plugin installation. If I've forgotten something important, feel free to add it here.
-
Yes, because Composer is a beast in combination with a read-only file system.
-
Then we seem to require support by the cloudron team to get one or the other Amazon AWS SES plugin added by default to the Mautic Package (https://forum.cloudron.io/topic/10885/3rd-party-email-transports-on-mautic-5/19?_=1712869768070) and also other plugins.
... which is a bit of a problem, as it would increase the maintenance effort for Cloudron (core updates + plugin updates = package updates). On the other hand, if there is no real solution Mautic users on cloudron may be locked out from future developments in the marketplace as well.
Do you see a solution? Would it maybe require to have a Mautic Dev package - same as with the WordPress Dev package, which contains managed images, but are not read only for the core files?
-
@dsp76 yeah, marketplace does not work well in cloudron packaging context.
To me, using "composer" is equivalent to managing a development environment. It modifies dependencies and you are on your own for future update of mautic and the plugin. At this point, you are making the sysadmin ... a developer. I think if people want to go down this route, the LAMP app is the preferred approach. WordPress dev is really no different than LAMP but with WordPress pre-installed.
In some ecosystems, like WordPress, you can just download release bundles and upload it into a plugin directory. This approach would be preferred instead of making the user run composer and having the dependencies of mautic itself changed. Does mautic support simply uploading plugins?
-
G girish referenced this topic on
-
Yes - it works for plugins, that don't require composer to run. So I guess whenever someone needs to have more than just "standard" setup - LAMP is the way to go.
I don't quite understand, that the included E-Mail transport in Mautic for AWS is now so basic compared to the features before (no API access, no bounce handling) and for real use we now need a composer based plugin.
At the end all Mautic installs I managed or suggested to clients in the past included AWS SES with API and proper bounce handling. It means that Mautic on Cloudron is not making things easier anymore for future prospects - which is in no way meant to be complaining about Cloudron, just about the situation.
-
@dsp76 yeah, I am not sure why all these are "plugins" . It seems like it should part of the basic software. But let me set aside my rant on plugins for the moment
In general, you can always run composer on your laptop/somewhere and upload the result, no?
Let me try experiment with the approach mautic has taken and get back.
-
@girish I will need to check with our devs. I fear that the composer requires some write access in protected directories - so if it changes or adds something, for instance in the /vendor directory, this will be in the protected environment in Cloudron, right?
Looking forward to your experiences. Thanks a lot!
(I promoted the Cloudron approach in a recent community call in D/A/CH... so I could imagine there are some people watching the progress too. No pressure
) -
D dsp76 referenced this topic on
-
@girish no that won't work, as the installation needs the central composer.json and also update it. It also loads more directories into the vendor directory, which is read-only in Cloudron. Did you come to some conclusion with your experiments?
Looks to me like the Mautic plugin concept doesn't work well with the Cloudron way of things.
Potential Scenarios:
- Plugins should be installed with composer, a lot of directories and the central composer.json would need to be writable... not good.
- Cloudron Mautic image would have some basic required plugins preinstalled, how to decide which? For me it would be (AWS)Mail, Custom Objects, Multi Domain plugins. Probably it would need to be different mailers. But this would increase maintenance, as plugins may have urgent updates outside of release cycles of Mautic.
- Cloudron set up like WordPress (Dev) - like a preinstall but without continuous updates of core (because that would kill customizations). A little improvement, as the initial installation is fine and working (at least causing 50% of Mautic beginners trouble otherwise).
- Cloudron self maintained on LAMP stack. Almost all the benefits of Cloudron lost.
Which other options did I miss?
(Ask me about B2B marketing automation & low code business solutions, if thats interesting for you.)
-
@dsp76 I think your analysis is spot on. I don't really have a solution. I think people who want to use custom plugins/marketplace will have to use the LAMP app and install mautic themselves.
Just my 2c . As it stands, mautic's marketplace/plugin mechanism is untenable. Basically, a plugin can have random requirements, and it can change the dependencies that mautic was actually tested and released with. If you install multiple plugins.. forget updates, even the installation is at best in an unknown state and one has to go with "it worked when i clicked around". I doubt Mautic upstream devs have the resources to debug such setups. Indeed, I don't know who this system is intended for. I am not part of Mautic community, so I might be completely missing the point of plugins.
About the actual plugins themselves:
- Multi Domain plugins does not work with Mautic 5 .
- For the AWS bounce processing, this thread suggests some plugins. Those plugins don't even have 5 stars. In fact, one of them has 0 stars. I think pre-bundling such code is out of question.
- Custom Objects - is actually maintained. And tbh, it's the only plugin which is developed in entire Mautic it seems
Maybe because this is also by the authors of Mautic.
This is not a critique of Mautic, we use Mautic ourselves. Just that one has to limit oneself to using it without plugins.
-
I've been trying to install Mautic via the LAMP app and it seems like it won't work. Has anyone been able to do this successfully?
-
@Dave-Swift I did. I needed to tweak composer a bit. I think I needed to change some environment variable, as composer did expect to write to a read only directory. I wanted to look it up in my shell history, but thats empty now...
-
Thanks @dsp76. I figured it was something like that.
It would be great to have a one-click Mautic Dev install, like we have for WordPress!
-
@dsp76 said in Installation of plugins is broken in Mautic package:
@Dave-Swift I did. I needed to tweak composer a bit. I think I needed to change some environment variable, as composer did expect to write to a read only directory. I wanted to look it up in my shell history, but thats empty now...
So, how does it sounds like until now would that be sustainable?
And, is it just me or it seems like since Mautic 5 and Cloudron 8.x it is incredibly slooow to save things in configuration sometimes it takes up to a minute?
And I run A BIG server. Anyone has noticed such thing or would be aware of the reason for this slow configuration saving? -
@micmc said in Installation of plugins is broken in Mautic package:
And, is it just me or it seems like since Mautic 5 and Cloudron 8.x it is incredibly slooow to save things in configuration sometimes it takes up to a minute?
Can you maybe open a separate thread about this? Are you able to reproduce this with the demo instance?
-
@joseph Yeah, I'll open a new thread about this, right.
Thanks and I tried with the DEMO as you suggested, and on the demo it's quite fast as it should be however since I'm referring to the saving in configuration section which can take up to a minute, I do not think in the DEMO version changes made really save whatever to the database, hence likely why it is fast. -
Here is the tweak, to use composer with NPM in the LAMP stack (@girish might be interesting for other apps in the LAMP stack as well, if someone with knowledge can confirm this approach):
export NPM_CONFIG_CACHE=/tmp/npm_cache export NPM_CONFIG_USERCONFIG=/tmp/.npmrcthen
mkdir -p /tmp/npm_cache touch /tmp/.npmrc npm ci --prefer-offline --no-auditprobably better prefix it with
sudo -E -u www-data ...otherwise new created directories have the wrong ownership and need to be adjusted with
chown www-data:www-data MailjetBundle/ -R"MailjetBundle" was the example I used it for.
