Symphony.

Yes, I’d be happy if you could help me with that! Host says CLI is called via:

>/usr/local/bin/php5-LATEST-CLI ( php5.2.17-cli ) 
>/usr/local/bin/php5-53LATEST-CLI ( php5.3.8-cli )

Edit: Symphony runs on 5.3.8

Yes, that was it!

Right now I have managed to get the CLI process to work, however another bug Michael pointed me to a few weeks earlier is popping up. Can we meet somewhere in a chatroom? That would definitely ease the process.

Brilliant thanks!

ICQ/AIM, or Jabber maybe?

Edit: sent you an e-mail

@huib
Just installed everything on the new host and works like a charm!
So no need for hacks.. (yet)
And, it's a dedicated server i think... don't know the name (no whois data available)

Just for the record, thanks to creativedutchmen my problem has been resolved.

There was an issue with the select field, I have sent a pull request: https://github.com/McKean/symphony-2/commit/a1e1a4bbf1087636fd665b9a9ea975237f062584

Thanks again huib!

Many thanks to Huib from me again too!

Let me know if you have consulted Michael.

Hooray!

Michael?

Huib said I had some kind of Collation Problem that you had somehow fixed? I’m still hopelessly stuck with this. Have you too been able to talk about this?

Many many thanks,

Alex

I forgot to post this issue on GitHub, sorry.

The problem here is: Beginning with the Members extension, the Working Group started to explicitely set a character set (UTF-8) and a collation for newly created tables in the database by using:

DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci

Some extensions have followed this example, but the core fields (packaged with Symphony) have not. The latter don't explicitely set a collation for tables, so MySQL will use the default collation (which is utf8_general_ci for the utf8 character set). So now we find different collations on tables in the database.

The Email Newsletter Manager uses a temporary table for 'sent' email addresses. In order to find the next batch of addresses to send to, it must JOIN this table with the table containing the recipient addresses. Here comes the problem: A JOIN only works on tables with the same collation, otherwise MySQL will throw an error.

The ENM uses utf8_unicode_ci collation on the temporary table. So if your email addresses use e.g. a standard Input field, the processs will break (assumed that you did not change the MySQL default collation or the collation of the Input field's entries table).

So what you can do at the moment is:

• Either: For your email addresses, use a field which has the utf8_unicode_ci collation. (This will not be a "core field".) I am using the Members: Email field, for example.
• Or: Manually set the collation of the entries table to utf8_unicode_ci. I don't know which side effects this might have, so do it at your own risk.

So you might get the ENM up and running. Nevertheless we should do two things in the near future:

• Clean up the "collation confusion" in Symphony (core fields, fields provided by extensions) and publish some "best practice" to tell people how DB tables should be created.
• For the ENM, maybe find a way to get the collation of the current email address field table, then use the same collation for the temporary table.

I posted a Symphony issue on GitHub. So if you want to collaborate to the Symphony part of this issue, please do it over there. If you have any comments on the ENM part of the problem, please stay here.

Moved to github issue.

Thanks so much Michael!

Switching to Members: Email did the trick! Oh joy!

Beta2 of this extension has been released today.

In this new version, we finally support dependent datasources and their params, so it is now possible to filter a section by {$ds-output}. Not all features Michael and I like to implement are supported yet, but the new version should make this extension a bit more powerful again.

In the background I am still working on the last outstanding bugs, so we can get this puppy to a stable release (if only I had more time :( )

It should be mentioned that there is no auto-detection for these dependencies. It you want to use {$ds-output}, you will have to add it to the dependencies array of your recpientsource file. (At the moment these dependencies will be overwritten by an empty array if you re-save the recipient group — but this will be fixed very soon.)

Nevertheless this is a big step forward, because now you can build really advanced filters for recipients!

I am getting a bit frustrated as I can't get the Email Newsletter Manager to send emails.

First, I created a new PLAIN email template called "Newsletter: Default Template". It's just simple with no data source attached (at the moment). I will attach the datasource once I get it working to make the emails perosnalized.

Newsletter Senders and Newsletter Recipients are also set up

My "Newsletters" section with following fields:

• Title (input)
• Email Body (textarea)
• Date Created (date)
• Newsletter (emailnewslettermanager)

When creating the "Newsletters" section, I selected the "Newsletter: Default Template" and my Newsletter Senders and Newsletter Recipients group.

Next, I try to create and entry and send the emails, but nothing happens. No errors at symphony-back end just...

Sending 0 emails sent 0 emails failed

So, I check manifest/newsletter-log.txt and I see this error:

[2012/03/27 08:24:41] pid: 1570 - Call to a member function get() on a non-object in file: /var/www/vhosts/ourfancysite.com/htdocs/extensions/email_template_manager/lib/class.emailtemplate.php on line 246

Am I missing something or have I set it up wrong? I suspect something is not configured right server-side, but what could it be?

Few facts about the server configuration:

• Ubuntu 11.10 (GNU/Linux 3.0.0-13-virtual i686)
• PHP Version 5.3.6-13ubuntu3.6
• php5-cli is already the newest version.

Hmm, yes. This is a bug we (michael and I) have been fighting about the past few weeks. The problem itself is incredibly simple: there is no datasource attached, and the code assumes there is. This also explains the error in the logs: there is no datasource to call the get() function on.

The simplest fix is to attach a datasource (for now), it's not the neatest solution, but at least it should work.

I believe this bug is already on github, and if it isn't, I will put it on.

Ok... I got it working now. Emails go through. I should've read the whole topic before posting. I attached the datasource and amongst other things I overlooked the "Email" field at Recipient Groups. I specified ID instead Email field there. Stupid, stupid me… :D

OK. I saw on GitHub that having Symphony in sub-folder doesn't allow parameters for newsletter template at this point.

Another question: in one of earlier versions I have created [[url]] parameter to dynamically link to profile page of recipient. How is that handled in the newest version (1.0 Beta2)?

I saw on GitHub that having Symphony in sub-folder doesn't allow parameters for newsletter template at this point.

I assume you are referring to issue #3, because that is the only open issue that has something to do with parameters, but rest assured: having Symphony in a folder has nothing to do with the issue. The problem is that the $url and $workspace variables are not correctly set.

Another question: in one of earlier versions I have created [[url]] parameter to dynamically link to profile page of recipient.

The ENM use XSLT for its template, and all its parameters. If you were using email newsletters (the extension this extension replaces) I am afraid there is no way to cleanly update from the old version to the new, so you will have to recreate all of your templates, senders and recipient groups using XSLT.

I understand that ENM has no direct upgrade path from Email Newsletters extension. I was trying to figure out how to get recipient data (first name, last name, id, email etc.) so that it can be added to XSLT template. Basically:

<p>Hello <xsl:value-of select="recipient/entry/first-name" />!</p>

I couldn't wrap my head around that I should be looking at Email Template Manager instead of Newsletter extension. The solution is obvious, for anyone having hard time figuring that out, just make data source with {$etm-recipient} parameter filter on email address and attach it to email template used by newsletter. Based on that you can casually xpath to data output from the datasource, for example:

<xsl:value-of select="/data/recipient/entry/first-name" /> 

Again, beautiful extension!

PHP and MODx are crashing your website.

Shitballs, this is exactly why I hate MODx. Thanks for the hint!