Symphony.

I rolled out Symphony 2.0.8 RC3 on seven different S2 websites today without any Symphony-related issues — and the extension works fine as well.

Some days ago I did another Email Newsletters implementation on one of these websites, including email personalization. Looks like the extension will loose its “release candidate” status soon.

Email Newsletters updated to version 1.0 on 10th of July 2010

Email Newsletters updated to version 1.0.1 on 13th of July 2010

Email Newsletters updated to version 1.0.2 on 13th of July 2010

This release reverts the changes which were made for 1.0.1. Although by no means critical, they turned out to be useless. The issues which I tried to fix here were mainly caused by firewall settings. The second problem was: SwiftMailer’s Swift_TransportException seems to be broken at the moment. But we can still leave the ‘transport test’ as it was in 1.0, because it will NOT break a process that wouldn’t break anyway (upon the first connection attempt).

Sorry for any confusion.

Hi Michael,

This is a great extension! Thanks for your work in putting this together.

Noticed a few things that tripped me up so thought I’d mention them in case they cause problems for others.

1. The php function shell_exec() has to be enabled in your hosting but it is quite often not. At least with my provider there was an option in the control panel to remove the function from php’s disabled function list.
2. The next problem I hit was that the shellexec() call inside the extension didn’t appear to do anything - After quite of bit of digging I tracked this down to the fact that the CGI environment variables from that were being passed to the php cli were causing it to fall over. To get this working I had to add “env -i ” to the beginning of the command line passed to shellexec. This cleans out the shell environment (see http://www.php.net/manual/en/function.shell-exec.php#38905).
3. The last thing that caught me out is that the first configuration example has the wrong attribute names in (ie “reply-to” instead of “reply-to-email”). I guess the attribute names were changed at some point?

Simon

Hi Simon, thanks for your response! I am glad that you like it.

RE 1: The shell_exec function is used because in earlier versions of this extension there was a single shell process doing all the sending. Then I realized that — while theoretically these processes can run forever — in practice some providers kill any processes owned by PHP after some minutes even if they run in the shell. So I changed the loop logic to start new processes after each email slice, still using the shell_exec function. I am thinking of removing the shell_exec funtion completely now. The only disadvantage is PHPs max_ececution_time, which will be a limit to the sending pauses.

RE 2: At this point I am not sure what cleaning out the shell environment actually means. Are there any disadvantages? Does this have an influence on multiple processes (sending several newsletters at the same time)? These questions will be obsolete if I decide to remove the shell_exec function.

The last thing that caught me out is that the first configuration example has the wrong attribute names in (ie “reply-to” instead of “reply-to-email”). I guess the attribute names were changed at some point?

RE 3:You are right. This typo indeed tells us that attribute names were changed. I pushed the correction to the Github repository.

Hi Michael,

Sorry for not getting back to you sooner

By cleaning out environment I was finding that the forked php process was (weirdly) just returning the html output of the current symphony page. After doing a bit of a google my understanding is that the CGI vars that are passed to the containing web site php process to tell it what page to render are then being passed via the environment to the php process via shell_exec. I think these overwrite the command line used in some circumstances and cause it just to render the symphony page.

From the search I did it appears that env -i prevents all environment variables from being passed to the forked php process and cause it to do the right thing. From what I could tell this has no negative effects so might be worthwhile as a safeguard in all cases but if you’re removing the shell_exec call this problem will go away, anyway…

Simon

As I understand, this extension doesnt manage the subscriberlist or opt-in and out, since you just have to supply an xml list of your subscribers.
I would like to hear how you guys have been setting this up.

Rather then using the Frontend Membership extension, I would prefer to hook into google contacts API, it just makes more sense to me to have to have all my subscribers consolidated into gmail/google apps email. (can be synced with my addressbook in leopard, and my ERP can sync with my addressbook via carddav) I guess an extension that can add google contacts (as per this) example would facilitate that.

I like the idea of newsletters based on 3 best of breed solutions:

• symphony with email template filter extension for composing
• google contacts for subscriber management
• cloudservice (postmark, critsend) for reliable sending and analytics

Its much more flexible then all-in-one services like mailchimp, if only for the posibility of automated composition of the html messages and localisation of the backend/GUI.

I have seen postmark mentioned at the forum, but think critsend migth be even better because pricing, and you can just set it up as an smtp, so not even an api needed!

It’s true, the Email Newsletters extension does not handle opt-in/opt-out — there are many possible requirements (and solutions).

I have set up the extension on different websites, using custom “double opt-in”/”single opt-out” procedures. It’s not too hard to build this in Symphony (if you don’t care about getting your hands dirty). You will need:

• Section: Recipients (email address, UID, approval flag)
• Events:
  • registration
  • opt-in
  • opt-out
• Event Filters:
  • send registration email

Altogether it’s around 350 lines of custom code, which I packed in extensions. Since the requirements are slightly different every time, I never managed to create a “universal” (i.e. rather generic) extension.

Email Newsletters updated to version 1.0.4 on 26th of September 2010

I fixed a bug and added skeary’s proposal to prevent problems if PHP is runnign as CGI module.

This really seems like a great extension and I managed to set it up, but the the server I’m using doesn’t allow shell exec, and after going through the support of the provider they told me that they don’t allow it to be turned on…

So my question: Is there a way to remove the shell exec on my own? Could you tell me what lines of code to alter?

Thank you very much.

Kind regards

Christopher

I thought about removing shell_exec, but in the end I couldn’t come up with a good solution. If anybody has an idea, I am all ears. But please consider that sending a newsletter may take a long time — so we can’t do things while rendering a frontend page (as it is standard for PHP scripts)!

It might help to look at the Pommo mass mailer for example to reverse-engineer its sending (loop) logic. Unfortunately I don’t find the time at the moment. And changing my extension’s logic to not use shell_exec anymore wouldn’t be very straightforward.

In short words: There’s no quick solution, but I’d love to hear suggestions.

Email Newsletters updated to version 1.0.5 on 12th of October 2010.

MySQL 5.5 compatibility, as described in this thread.

Michael-e, if using critsend smtp, or api, to send the emails, wouldn’t it be instantanious, and thus not needing shell_exec? You just pass the task on to an external service. In fact I wonder of the throttling of swiftmailer is even needed when workign with critsend?

I need to start doing email newsletters too, and also can’t use shell_exec, so if you come up with a solution, all the better…

@newnomad: I don’t want to give up using standard SMTP servers. Those will have certain limits, which means that we can never send “instantanious” — in other words: we need some sort of throttling. The extension itself should be able to send some 10.000 (personalized) emails which may take some time… So shell_exec is a very good solution to me.

@designermonkey: I will take a brief look at PoMMo (which I have been using for a client once) to see how the background process is handled there. But I can’t promise anything.

No worries. I’ll find a way :)

Email Newsletters updated to version 1.0.6 on 29th of October 2010.

Fixes a single bug which occured only when invalid email addresses were used.

Email Newsletters updated to version 1.0.7 on 8th of December 2010

That’s just a bugfix release which finally eliminates the counting (statistics) bug.