3rd Party Email Transports on Mautic 5
-
Mautic 5 adds support for installing 3rd party email transports.
However, on Cloudron this is not possible because composer.json is locked.
Is there any way to add support for this?
List of transports:
https://symfony.com/doc/5.x/mailer.html#using-a-3rd-party-transport -
Have to see what this involves. Maybe, we should bundle this in the docker image itself.
I have many question: How does composer handle dependencies and conflicts? What if installing a email transport upgrade or downgrades a package that Mautic depends on? How are composer upgrades handled when updating Mautic?
-
@Dave-Swift said in 3rd Party Email Transports on Mautic 5:
Mautic 5 adds support for installing 3rd party email transports.
However, on Cloudron this is not possible because composer.json is locked.
Is there any way to add support for this?
List of transports:
https://symfony.com/doc/5.x/mailer.html#using-a-3rd-party-transportActually that was already possible to do with Mautic, the only thing different in regards to this, as far as I can see at the above link, is that it seems that tiers SMTP would now depends on some -not pre-installed- modules that would require to be installed independently through Symfony.
I have to check this out myself eventually when we can fix the upgrade issue to go on smoother
-
@micmc All the email transports were removed from Mautic's core and must be re-created as separate plugins.
Mautic did not previously support transports for Symfony Mailer because before V5, Mautic was using Swift Mailer.
-
@girish Composer looks at your composer.json to figure out what packages and versions your project needs. In composer.json, you can specify version constraints for packages.
If a package you want to install (like an email transport plugin) requires a different version of a package that Mautic already depends on, Composer identifies this conflict. It tries to find a version of the packages that satisfies all requirements. If it's impossible to reconcile these version requirements, Composer will throw an error and stop the installation process.
-
@Dave-Swift said in 3rd Party Email Transports on Mautic 5:
@micmc All the email transports were removed from Mautic's core and must be re-created as separate plugins.
Mautic did not previously support transports for Symfony Mailer because before V5, Mautic was using Swift Mailer.
Thanks though that resemble much almost exactly as what I said, just said differently
I use Mautic for more than 10 years
-
I have been using it for 7, what does that have to do with anything.
I wanted to clarify because the way you phrased your statement, it indicated that this isn't new and that it was possible before Mautic 5... when in reality it was an entirely different architecture.
Anyway, this isn't productive.
-
@Dave-Swift said in 3rd Party Email Transports on Mautic 5:
I have been using it for 7, what does that have to do with anything.
Just that you seemed to think I was green dude loll
Just read carefully before you answerIndeed it's just a matter of language and expression used, maybe my 30 years in IT web services provider have something to do with something here? Don't make a dish with matters of wording I did not say anything that was not correct technically speaking if you read me correctly.
I wanted to clarify because the way you phrased your statement, it indicated that this isn't new and that it was possible before Mautic 5... when in reality it was an entirely different architecture.
It's YOUR perception, get over it dude will you sleep better now that you've "clarify" what you felt needed to be clarified according to you?
Anyway, this isn't productive.
You say so...
-
@Dave-Swift ok, perfect, thanks for explaining. Which transport(s) do you need? For a start, I can pre-install them in the image already (instead of making composer.json configurable which seems like a bigger project).
-
I quickly tried this but installing via composer seems to mess up with mautic. Have to debug later.
17:49:19 - PHP Warning: include(/run/mautic/app/config/paths_helper.php): Failed to open stream: No such file or directory in /app/code/app/bundles/CoreBundle/Helper/PathsHelper.php on line 50 17:49:19 - PHP Warning: include(): Failed opening '/run/mautic/app/config/paths_helper.php' for inclusion (include_path='.:/usr/share/php') in /app/code/app/bundles/CoreBundle/Helper/PathsHelper.php on line 50 17:49:19 - PHP Warning: Undefined array key "root" in /app/code/app/bundles/CoreBundle/Helper/PathsHelper.php on line 185 17:49:19 - 17:49:19 - 17:49:19 - [WARNING] Some commands could not be registered: 17:49:19 - 17:49:19 - 17:49:19 - In FilesystemLoader.php line 92: 17:49:19 - 17:49:19 - The "/run/mautic/vendor/knplabs/knp-menu/src/Knp/Menu/Resources/views" dire 17:49:19 - ctory does not exist ("/run/mautic/vendor/knplabs/knp-menu/src/Knp/Menu/Res 17:49:19 - ources/views"). 17:49:19 - 17:49:19 - 17:49:19 - In PathsHelper.php line 187: 17:49:19 - 17:49:19 - root does not exist. 17:49:19 - 17:49:19 - 17:49:19 - In FileLoader.php line 38: 17:49:19 - 17:49:19 - The mapping file "/run/mautic/vendor/symfony/form/Resources/config/validati 17:49:19 - on.xml" does not exist. 17:49:19 - 17:49:19 - 17:49:19 - In FilesystemLoader.php line 92: 17:49:19 - 17:49:19 - The "/run/mautic/vendor/knplabs/knp-menu/src/Knp/Menu/Resources/views" dire 17:49:19 - ctory does not exist ("/run/mautic/vendor/knplabs/knp-menu/src/Knp/Menu/Res 17:49:19 - ources/views"). 17:49:19 - 17:49:19 - 17:49:19 - In FilesystemLoader.php line 92: 17:49:19 - 17:49:19 - The "/run/mautic/vendor/knplabs/knp-menu/src/Knp/Menu/Resources/views" dire 17:49:19 - ctory does not exist ("/run/mautic/vendor/knplabs/knp-menu/src/Knp/Menu/Res 17:49:19 - ources/views"). 17:49:19 - 17:49:19 -
-
@girish It seems like Composer needs to be tightly integrated, which is not yet the case.
I've installed a totally new instance of Version 5 on one of my servers-had to find out more since the upgrade didn't work, yet. Now it appears that this will not work until the Composer part is 'fixed'.
How we can know that? Because, as also reported here in the OP by @Dave-Swift, it is indicated within Mautic that Composer is not supported, and as a matter of fact this is going on for a while and been reported before by me, and some other Mautic power users.
We see this from the Marketplace section, this is in version 4.4 and it's the same thing we see in version 5 as well.
I have many question: How does composer handle dependencies and conflicts? What if installing a email transport upgrade or downgrades a package that Mautic depends on? How are composer upgrades handled when updating Mautic?
Here's the details concerning the actual major changes in the script.
And here you will find the composer.json file content, I guess that should help to see where it will stand in your investigation.
ADDED:
I also pull your attention on this post here, seems you have missed, of what I extracted from my logs after the glitched attempt to upgrade. TTYL -
I can't get symfony/amazon-mailer or symfony/mailgun-mailer installed outside cloudron as well. So, maybe if someone figures this out, we can add it later in the package.
-
I figured this one out. The magic incantation is:
composer require --no-update --no-install --prefer-stable --no-scripts symfony/amazon-mailer symfony/mailgun-mailer
The main thing was
--no-scripts
. The packages started building assets and they ended up being half baked since mautic is not even installed at that point. The latest package has the email transports installed. -
Has anyone tried to install new 3rd party plugins with improved mailer support already? E.g. Amazon SES by default is only supported with SMTP, no API and no bounce handling. Now there are 2-3 Plugins out there, which seems to handle it quite well.
Was anyone able to install those into Mautic Cloudron?
-
@dsp76 I don't have experience with this part of Mautic but can one not use https://docs.mautic.org/en/5.x/channels/emails.html#bounce-management ? Essentially, with webhooks to notify mautic.
-
@girish with the jump to v5, some functions have been moved from core to plugins. The core functionality of AWS Support doesn't include the API based bounce handling (with webhooks). Thats why there are several SES Plugins now:
- https://github.com/jos0405/mauticawsmailer
- https://github.com/pabloveintimilla/mautic-amazon-ses
- https://github.com/alexhammerschmied/MauticSesSnsBundle
- https://github.com/pm-pmaas/etailors_amazon_ses
- https://github.com/hachther/mauticawsmailer
I will give them a try and test it also with Cloudron.
-
- and 4. are not installable via composer in my trials at cloudron.
- throws an error:
Your requirements could not be resolved to an installable set of packages. Problem 1 - mautic/core-lib[5.0.0, ..., 5.0.4] require friendsofsymfony/oauth-server-bundle dev-upgrade-2 -> found friendsofsymfony/oauth-server-bundle[dev-master, 1.0.0, ..., 1.7.x-dev, 2.0.0-alpha.0, 2.0.x-dev (alias of dev-master)] but it does not match the constraint. - pabloveintimilla/mautic-amazon-ses[v1.0.0, ..., v1.0.2] require mautic/core-lib ^5.0 -> satisfiable by mautic/core-lib[5.0.0, ..., 5.0.4]. - Root composer.json requires pabloveintimilla/mautic-amazon-ses ^1.0 -> satisfiable by pabloveintimilla/mautic-amazon-ses[v1.0.0, v1.0.1, v1.0.2]. You can also try re-running composer require with an explicit version constraint, e.g. "composer require pabloveintimilla/mautic-amazon-ses:*" to figure out if any version is installable, or "composer require pabloveintimilla/mautic-amazon-ses:^2.1" if you know which you need. Installation failed, deleting ./composer.json.
Not sure if this is related to the Cloudron environment. I also wonder if this has a chance to succeed at all as the code path is read only by design?
Would a necessary plugin needed to be added to the cloudron mautic package?
-