Symphony.

After reading the extension tutorial and this whole thread I still wonder if i can easily secure the page generating the mail so it can't be readed by anyone using the frontend.

Readed the 404 redirect thing but I didn't fully understood that.

@Guillermo, your problem is exactly why me and michael developed the ETM.

Hey all,

I am running Symphony version 2.2.5 and trying to get ETF to work, I need to use ETF as it appears to be the only extension that supplies what I need, including Email Attachments.

I have set it up by following the tutorial supplied, it sends an email which includes the correct template, however, it fails to email any data. It also doesn't include the data in the "Sender Name and Senders".

When I go to the template page "{$root}/email-contact-details/{$entry-id}" the data pulls in fine so it fails on the emailing part.

Does anyone have any ideas on how to fix this issue please?

Thank you.

Ahhh, managed to fix it. Basically, I had added "etf" as a page type to the email template but not the actual page where the form was in. Working as wanted. :)

any chance this is getting updated for 2.3.1

Have you tried the 2.3.x branch on GitHub?

@michael-e, @jeff, the integration branch is the branch you are looking for. For the ETM (email template manager) it's the 2.3.x branch :-)

ah thanks ill try that right away

appears to work but my template got erased ill have to figure out how i had that setup. Tnx.

Ooops, I messed it up. Should've known the names.

Fatal error: Call to undefined method Extension_EmailTemplateFilter::getDataParam() in /home/../extensions/emailtemplatefilter/extension.driver.php on line 350

I get this error when I try to send, did the php requirements change for this extension?

Edit: Im also using the urltopdf with the etf

Ok, so I commented out line 350 of the extension driver

##  $this->getDataParam($value, $child);

And my email sent without any problem, also the pdf was generated and attached properly.

I guess I'm just wondering if that's going to be a problem?!

I'm going to be honest here and say this extension should be deprecated. Is it possible to get the Email Template Manager to work with attachments? I believe that is the only downside to working with the EMail Template Manager.

It just seems that there's a lot of duplication here and that efforts should be focused on a single extension.

I use it to send attached generated pdfs for invoicing I dont know if the ETM works with the htmltopdf extension.

Is it possible to get the Email Template Manager to work with attachments?

Sure, the ETM supports attachments just fine, but there is no "user friendly" (as in: gui) way of doing so.

Maybe deprecating the ETF, and handing the ETM to the symphonists so it can be patched a bit faster is a good idea.

I don't think that it would be a good idea to build this into the ETM. The main task of the ETM is to build email header fields and render plain text and HTML content, not building or sending complete emails. The latter is the task of Symphony's Core Email (API) stuff.

You can, however, use the Core Email API and the ETM's API to send whatever you want — but you will have to write your own event (or event filter) instead of using the supplied event filter.

I don't see a universal way of attaching auto-generated PDFs. While some people use htmltopdf or something similar, I would prefer using XSL-FO which requires the PHP Command Line Interface and a processor like the Apache FOP (Formatting Objects Processor). Some people might as well want to send CSV attachments or JPEG images. So if there is no universal way of doing it, how should the logic be to define an attachment for an email?

Could we build some generic URL scheme including parameters to describe an attachment? In this case the developer would have to build his own "attachment API" that follows this URL scheme. That doesn't make things much better. And even this wouldn't help if suddenly you decide to send two or more attachments.

So my conclusion is: An extension like the ETM can not help to create every email content (like PDF/JPEG/XLS/DOC/whatever attachments), but it should focus on its main task. You will have to get your hands dirty anyway. Build your own event, it's not too hard.

Ah, @creativedutchmen beat me. But I was more verbose. :-)

handing the ETM to the symphonists so it can be patched a bit faster

You don't want to support it anymore?

ETM supports attachments just fine

Hmm, that's not exactly what I thought (and explained above). Can you elaborate?

You don't want to support it anymore?

Sure do, but experience shows that development is slow:)

Can you elaborate?

The ETM supports attachments out of the box, because the email API supports attachments out of the box (and the ENM uses the API directly). The only pickle right now is that you'd have to create your own event for it, because the ETM does not have a gui (or a ui, for that matter) for it.

However, conceptually attachments are not a big deal. The API is smart enough to know the difference between a pdf and a jpg, and will send the right stuff over the wire. So, the way I can see this happening is this: add a duplicator on the email template settings page where you can insert the location (path or url) of a file, or upload one.

It will then work with the htmltopdf extension, my (unreleased) wkurltopdf, JIT image manipulation, etc - as long as the file has a path or a url it will work.

Does that answer your question, or have I been babbling?:)

Regarding the concepts: I don't really see any conceptual problems with integrating attachments in the ETM directly, simply because the ETM is there to make your life easier when sending emails.

We've added an event filter later on, because it turned out that was very useful - all events using the ETM will look basically the same, so why not bundle that code with the extension directly? I can see the same with the attachments: I have created my own events for that, michael, you have, so why not build a gui for it and let everybody (even without php knowledge) do it?

The ETM supports attachments out of the box, because the email API supports attachments out of the box (and the ENM uses the API directly).

I see, that was what I tried to say above.

I don't really see any conceptual problems with integrating attachments in the ETM directly

Fair point. But we should try and fix the bugs first. :-)

experience shows that development is slow

I might try and kick your ass from time to time. :-)) Honestly, in this special case — emailing — further development wouldn't be simple for the community either.