Support/Comments for TXNewsletters

the confirmation email get’s sent out regardless of the settings in the TXNewsletter configuration as well as subscriptions do not get added to the database list of subscribers although the subscription is confirmed by email ? I’m not getting any error messages

mmjaeger:
I don’t think I understand the question. The TXNewsletter module has a configuration settings to enable and disable email confirmation. When email confirmation is enabled emails are recorded to the database only after the confirmation process is complete.

Frisco:

I need to have a comment inside the xml, saying something like "fields with * are mandatory". How should I do this?

I don’t think this is possible, I added a similar statement in html after the TXNewsletter subscribe snippet.

The confirmation email has two same entries in the to-field ([email protected], [email protected]

I have not seen this before.

The encoding of the email seems to be wrong

I’m guessing this is a problem with your server’s email settings. I am sending utf-8 emails and all of my emails use non-english letters successfully including in the email subject.

etal:

I need to have a comment inside the xml, saying something like "fields with * are mandatory". How should I do this?
I don’t think this is possible, I added a similar statement in html after the TXNewsletter subscribe snippet.

Yes, I tried this too, but then this statement is visible even when the subscription confirmation is shown without the form being visible, which is, hm, at least irritating.

I’m guessing this is a problem with your server’s email settings. I am sending utf-8 emails and all of my emails use non-english letters successfully including in the email subject.

Will check this, I’m using msmtp with google mailserver via google app. Maybe I can put something there in the config.

Cheers
Frisco

Email works now - thanks.
Now I have a different problem: When I want to upload a csv file, it tells me: "The imported file must be a csv file conform to xml structure definition.". My CSV file looks exactly the same as the exported file from the TXNewsletter script (which, when I try to import it again, gives me the same error message).
The fields are in the correct order, it’s semi-colon delimited, all the text is in ’ " ’. What more can I do?
Thanks

Does your csv file have the first row with the names of the columns? Copy it from the exported csv file.

thanks for your suggestion - however, I don’t see how this would make a difference - as mentioned earlier, I unable to re-import a previously from TXNewsletter exported file either.

Hi,

etal:

I’m guessing this is a problem with your server’s email settings. I am sending utf-8 emails and all of my emails use non-english letters successfully including in the email subject.

As far as I could track it down, it could be about not using quoted-printable, special chars in the header have to be encoded like that. And remember, my Amavis says:

"X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char E4 hex): Subject: Best\344tigung Ihres ko[...]"

It’s only about the subject, the mail body is allright!

TXNewsletters sends: Content type: "text/html; charset=UTF-8".

I looked up my emails, if a
Content-Transfer-Encoding: quoted-printable
is used, everything looks fine.

TXNewsletters seems to use
Content-Transfer-Encoding: 8bit

Would it be possible to change TXNewsletters to use quoted-printable?

I changed sendConfirmation() line in txnewsletter.inc.php accordingly, but that didn’t do the job - maybe php has to encode the subject in the mail body with a built-in function for quoted-printable?

I than checked other emails from me which look right and saw that they have:

Content-Type: text/plain; charset=ISO-8859-15

thus I changed sendConfirmation() to text/html; charset=ISO-8859-15, (encoding 8bit again), but that made it even worse, messing up umlaute in the mail body as well.

Any clues?

Cheers
Frisco

Solutions:

Wrong subject (german umlaute):
For the correct subject encoding, I found out that

$subject = str_replace(": ","",iconv_mime_encode("", $subject));
or
$subject = mb_encode_mimeheader($subject); // , "UTF-8", "Q"

added in sendConfirmation() at line 1757 (right before $result=mail(...) ) in txnewsletter.inc.php does the job.

I suppose sendNewsletterMail(...) has to be changed as well.

I found that my lang/lang.german.inc.php had utf-chars, I had to change the subject in
$modx->TXNewsletters[’txtlang’][’confirmation_email_subject’] so that german umlaute were displayed correct (changing À to ä), but that maybe depend on your text editor, I use joe. This applies only for the subject, I didn’t touch the rest of the lang file.

Double To:
You have to comment out line 1749 to
//$headers .= ’To: ’ . $email . "\n";

Looking at
sendNewsletterMail(...)
I found that this was already done there, maybe one only forgot to do this in sendConfirmation() as well.

Cheers
Frisco

Quote from: Frisco at Nov 16, 2009, 03:47 AM

For the correct subject encoding, I found out that

$subject = str_replace(": ","",iconv_mime_encode("", $subject));
or
$subject = mb_encode_mimeheader($subject); // , "UTF-8", "Q"

added in sendConfirmation() at line 1757 (right before $result=mail(...) ) in txnewsletter.inc.php does the job.

I tried both alternatives, but none of them worked (And yes, I also tried [tt]$subject = mb_encode_mimeheader($subject, "UTF-8", "Q");[/tt] as well.)

In a PHP tutorial I read that mb_internal_encoding has to be set to UTF-8 before mb_encode_mimeheader can be used. I’m not really into PHP, but could this be a solution resp. the reason why it doesn’t work in my test here?

I tried both alternatives, but none of them worked Sad (And yes, I also tried $subject = mb_encode_mimeheader($subject, "UTF-8", "Q"); as well.)

Have you changed the lang file as I described too?