concretecms
concretecms copied to clipboard
concretecms
Make Email Settings more Modular
Right now for email you have 2 options, PHP's built in thing, and SMTP,
I want to expand this to be more modular like File Storage Locations so that we can add others, (SES, Mailgun, etc)
Anyone have suggestions or comments?
(any suggestions on a system like FlySystem but for email?)
Mail importers / senders seems like a useful component.
I know Swiftmail has a library that implements a few different transports, not sure what it would take to hook into something like that to make it extensible though.
As far as the mail importers go, it seems like an extremely useful thing to be able to integrate with mail systems, whether it be via pop3/imap/owa/etc. So many applications now require events to trigger on an email being received and processed and it would be cool to be able to bake something like this into the core.
Just found https://github.com/juriansluiman/SlmMail which looks sick, are we using ZF2 in the core?
It would make stuff like #1765 easier
@Mnkras do you think that the SlimMail library would actually make things more modular or just give a richer feature set? I think at first glance it looks like a pretty well written library I just have 2 concerns:
-
What would it take to make it so that users could hook in and add their own Transport / Services in via the Concrete5 packages / application directories
-
If this library is simply adding additional email providers and not providing a great means of making the Concrete5 email stuff more modular I think that it probably belongs in a package rather than in the core, and the core simply needs to be adapted to support hooking in and building on these sorts of things.
@EC-Joe good point,
-
Not too much work, it uses Zend's autoloader so where the files are isn't a problem, we might have to modify how it fetches its config values (and sets them) but besides that I think it will work.
-
Its making it so that we have a unified email interface for sending email, currently we have 2 choices and a limited amount of options for those choices.
Well, technically we don't – we have a single email interface. The Mail service. If you're actively rolling your own that doesn't use that code you're doing it wrong. You won't get email logging, etc... It's true that the email interface is limited to two methods of transport, but that's not the same as there being two interfaces.
I guess I should amend what I wrote, my original thought that sparked this was "I want to use mailgun with c5" and that just got me thinking, I was envisioning something like how File Storage Locations work in the end where it all just happens in the background.
That's totally valid – we use Sendgrid on concrete5.org for a similar reason. We're able to just get by using their service through an SMTP server, which is why we haven't needed to explore a deeper plugin architecture for mail services.