Symphony.

Anyone had any trouble with Member Forms and ETM on 2.2.3? Can't seem to register a user, it just reloads the page and XML response in events is just the usual "member-is-logged-in = 'no'" nothing else.. no errors/nowt :(

Sounds like a Members bug and not to do with emails... Is the new member entry created? If not, maybe best create a new thread to work through it.

Yep, member not being created. New thread on it's way :)

Hello!

I tried to follow the tutorial on fresh installation of symphony 2.2.3 with no luck.. i can't see anything from the extension is added into XML, not in param/ or event/ sections.

However, it sends emails (with no dynamic data, just plain text from template) & creates entries in 'Responses' section.

I even can't imagine what went wrong.. what additional data should i provide to solve this?

Hmm, what would help is if you select ?debug as your POST action. This should give you the normal debugging panel, where you can really see what is going on with your XML.

Have just launched a new website with ETM everything is working fine and all with events its just brilliant in conjunction with the Members extension, I sent the activation email, and when activated I get an email notifying me of a new activated user.

On my site users are allowed to post press releases say; however these have to be moderated prior to being published. I was wondering If I could possibly send an email when an article is confirmed so as to notify the user that his press release has been published and where it is available. Not sure if this is possible; If yes any guidance to where I can find the API/some hints would be appreciated.

Definitely can be done, although you'll have to get your hands a little dirty.

What you want to do is create an extension that listens for the EntryPostCreate and EntryPostEdit delegates. This delegates provides the Entry object, which you can use to find out if you field has a particular value or not. This is some psuedo code from an extension I wrote at work:

// Check the Entry is being edited in the moderation section
if($context['section']->get('id') != $this->moderation_section) return;

// Check that the moderation field is set to be something other than pending
// This check should only return true once, that is, the first time that this is
// changed from Pending to another value
if($context['entry']->getData($this->moderation_field_id, true)->handle != "pending") {
    // Do your EmailTemplateManager code in here!
}

In that example the Moderation field was a Select Box with Pending and Approved values.

That hopefully get's you on the right track.

I had to do something similar recently. An easier way of getting the field value:

$context['fields']['your-field-handle']

@brendo that's a really good start - just one thing in the comment it says that it should only return true once. So if I/someone else had to confirm/approve the entry. And someone else notices a mistake and edits it. The second time the event will not fire?

As the way I understand the code is that if its not pending the code fires which would mean I would have to do some extra checks correct?

Had in mind to use the delegates but I had missed some posts in the previous page on how to make ETM connect to them.

As the way I understand the code is that if its not pending the code fires which would mean I would have to do some extra checks correct?

Yep you'll need your own way to store whether the email has been sent already. It'd be as simple as a database table with one column storing the entry ID. Insert the entry when it has been sent.

Thought so - no its not a big deal for me - its just when I read the comment on top it read as if it makes the check - didn't want to write additional code for nothing.

Much appreciated Nick & Brendo. Hopefully this will mark my 2nd completed website using Symphony - I'm sure there are a lot of things I will add over time but possibly its the most complex I've worked on yet and its been a breeze with Symphony Kudos to you guys.

hello I'm using this usefull extension but I have a problem with the charset of sent email

if I send and email I have in the headers this:

Content-Type:   text/plain; charset=UTF-8
Content-Transfer-Encoding:  quoted-printable

and this is good for many email clients

but with some they display the text wrongly it looks like they dont accept the 'quoted-printable' and the mail, for exemple, looks like:

This is an automated email, please don=E2=80=99t reply.

instead of

This is an automated email, please don’t reply.

any idea to how to solve this problem? I think is a big problem becaus I'm using this extension for registration confirmation and login information; the email contain the url to click to activate te account, but the url is wroted wrongly so unusefull for dummy users...

anyone can help me?

tnx gio

Hmm, tough question. The reason we chose quoted-printable is because it is one of the widest supported standards for email character sets.

The bad thing here is: all text sent using the email API is by default encoded by this scheme, so there is no quick "fix" for this.

Can you please indicate which clients do not like the quoted-printable encoding?

Oh, and could you post the source (the part that is received by the client) of the email? Maybe something else is going on.

I cannot say u exactly the client that has this problem (I've asked and they dont reply me yet)

this is a tipical header:

From:   MAIL <noreply@www.something.com>
Subject:    Account Activation
Date:   September 28, 2011 3:25:45 PM EDT
To:     xxxx@yyyy.org
Return-Path:    <noreply@www.something.com>
X-Original-To:  xxx@yyy.org
Delivered-To:   12342@h.c
Received:   from 432432.xxx.com......
X-Php-Originating-Script:   33:email.sendmail.php
Message-Id:     <f58d3206f96b211f1c37e5f33a99ba9@www.something.com>
X-Mailer:   Symphony Email Module
Mime-Version:   1.0
Content-Type:   text/plain; charset=UTF-8
Content-Transfer-Encoding:  quoted-printable

this is the header as received originally in Gmail (but visualized correctly in the webmail)

Subject: =?UTF-8?Q?Account_Activation?=
X-PHP-Originating-Script: 33:email.sendmail.php
Date: Fri, 23 Sep 2011 12:55:06 -0400
From: =?UTF-8?Q?Symphony?= <noreply@www.something.com>
X-Mailer: Symphony Email Module
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I need a very easy text plain email just enough to say "wellcome" and put the confirmation url

any idea about how to fix it? no problem for me code locally the class.emailgateway.php &co but I need to know how to do that without create more problems (lol) I dont have time enough to study the whole platform

no problem for me code locally the class.emailgateway.php &co but I need to know how to do that without create more problems

To be honest, this would be an immense task. Right now, the entire platform has been written around quoted-printable encoding. Even stuff like: line breaks, line length and headers are all encoded using qEncode. This means these function calls are all over the place. Changing all of this would be a LOT of work.

On the other hand, it might be a better idea to investigate why the person on the receiving end did not receive the email properly. Was it because of a mess-up in the Symphony code? Or is it purely because the user has used an ancient email client, and is not willing to update?

I have just checked the emails I receive from major companies (Adobe, Facebook, Google) and most of them use quoted-printable as their encoding, so I think we can safely assume that there is nothing wrong with the encoding per-se.

We've battled with this at work since 2.2, we've found it's because the server seems to choke on \r\n. Find \r\n in class.smtp.php, class.emailhelper.php, class.emailgateway.php and class.sendmail.php and replace it with \n and see if that helps.

there is not a class.sendmail.php

but:

    class.email.php
    class.emailgateway.php
    class.emailgatewaymanager.php
    class.emailhelper.php
    class.smtp.php