michael-e / email_newsletter_manager Goto Github PK

The current HEAD (as of: now) honours recipientsource/DS dependencies if they are added manually to the dependency array. But when a recipientsource gets saved, the dependency array is overwritten.

When multiple recipient group options have been defined for a newsletter field, the field (in the entry editor) will always display those groups in alphabetical order. This causes usability issues if groups have some "inner logic". Prefixing them with numbers is not a solution here, because different groups might be used in different newsletter fields.

i've got the following message when i try to create a new template from ENM:
Symphony Fatal Error: Call to undefined method Widget::wrapFormElementWithError()
extensions/email_newsletter_manager/fields/field.email_newsletter_manager.php around line 73

Fresh symphony install and extensions :)

In case the Email Newsletter Manager field is configured to let the user choose a sender or recipient group(s), it should display the user's choice during sending and on success.

E.g. upon success it just says:

1 emails sent
0 emails failed
Started 2011-12-22 19:36

which should be s.th. like:

1 emails sent
0 emails failed
Started 2011-12-22 19:36
Sender: John Doe
Recipient group(s): Symphonians, Girlies

I ran into an issue which is probably a non-issue for most use cases. But if you run a big website (around 100.000 entries) and make excessive usage of ENM's possibilities (especially: > 15 recipient groups, all using advanced filters), this may be rather serious!

When the field adds to the datasource ouput, it will also attempt to add a count attribute to each of the recipient groups. Depending on the filters used in each group, the corresponding MySQL query may require several table joins, e.g.:

SELECT SQL_CACHE count(DISTINCT `d`.`value`) as `count` 
    FROM `sym_entries` AS `e` 
    LEFT JOIN `sym_entries_data_371` AS t371_1 ON (e.id = t371_1.entry_id) 
    LEFT JOIN `sym_entries_data_383` AS t383_1 ON (e.id = t383_1.entry_id) 
    LEFT JOIN `sym_entries_data_512` AS `t512` ON (`e`.`id` = `t512`.entry_id) 
    LEFT JOIN sym_entries_data_359 AS `d` ON `e`.`id` = `d`.`entry_id` 
    AND ( t371_1.value IN ('yes') OR t371_1.value IS NULL ) 
    AND (t383_1.value IN ('yes')) 
    AND (`t512`.relation_id IN ('1') ) 
    AND `d`.`value` IS NOT NULL

These queries may become very expensive and slow. (And the more recipient groups you add, the worse the whole thing will become.)

A a quick fix I commented two lines in field.email_newsletter_manager.php, so I am fine now. (I don't desperately need the counts, although they were "comfortable".)

My question is: What should we do?

• A: Don't do anything. Only crazy people with crazy websites will experience this, and they may apply the above hack.
• B: Think about a configuration option for group counts. (I don't know how to implement this, so I'd probably need help.)
• C: Attempt to make these counts run much more effective. (I have no idea if or how this could be done.)

Hello,
trying to install 1.1.1 on Sym 2.3.2, but I get a blank page on installing/enabling.

Thanks

Sending to static recipients is broken. In line 105 of class.recipientsourcestatic.php the temporary table is created without the utf8_unicode_ci collation, so the JOIN will not work if your database's default collation is different (which will be the case in most MySQL installations).

I tested the following issue with Symphony 2.2.5. At the moment I have no time to verify it using Symphony 2.3.

If you have two recipient groups, and at least one of them contains a German umlaut character, sending may break. (In this special case each group contained the same single recipient, and I set the extension to send 10 emails per batch. I do not know how important this is to verify this bug.)

I tracked this down to the following:

In class.emailnewsletter.php, the _markRecipientGroup function calls getHandle on the recipient group object. The getHandle function in class.recipientsource.php correctly calls Lang::createHandle. Once again (and we had this in other places as well) Lang::createHandle does not work properly when called for the first time. Indeed the first handle that is returned will still contain the umlaut character (so the transliteration has not been applied). All subsequent handles will be correct.

You can test this by adding the follwing to the _markRecipientGroup function:

$test = (is_object($group)?$group->getHandle():$group) . "\r\n";
file_put_contents('/some-path/debug.txt',var_export($test, TRUE),FILE_APPEND);

Once again a quick and dirty fix is to add Lang::activate(); as first line in the getHandle() function (in class.recipientsource.php). (We already use this in two other places in the extension.)

I still wonder why the language class behaves so strange.

The switch statement in the field's prepareTableValue function has a status called 'idle' which is never set by the extension.

Instead, the extension always defines 'idle' classes etc. if no other value is available (e.g. the default case in switch statements).

So the above mentioned lines should be removed.

In commit 4c5400c we made the loop continue no matter which exception occurs.

However, this can be undesirable, especially when sending using Amazon SES. (If you are sending too fast to SES, the gateway may throw an exception. If you don't pause sending then, your account may get suspended.)

So we decided that there should an additional option in the field settings called "pause on errors" or similar. Additionally, failed email addresses might be logged to a separate logifle (e.g. newsletter-40321-failures.log) to help the developer.

(This option must be added to the README, of course.)

If you are using dependencies, the order of filters will influence the result. Assumed you have the following filters:

    public $dsParamFILTERS = array (
  'id' => '{$ds-enm-kunden-admins}',
  171 => 'Yes',
);

and you have defined the dependeny:

    public $_dependencies = array (
  0 => '$ds-enm-kunden-admins',
);

everything will work. But if you now reverse the order of the filters:

    public $dsParamFILTERS = array (
  171 => 'Yes',
  'id' => '{$ds-enm-kunden-admins}',
);

The first filter (171 => 'Yes') will not do anything.

When an SBL field is used to filter a section, preview breaks with a Symphony Fatal Database Error:

Unknown column 't333_1.value' in 'where clause'
An error occurred while attempting to execute the following query
SELECT SQL_CACHE `e`.id, `e`.section_id, e.`author_id`, UNIX_TIMESTAMP(e.`creation_date`) AS `creation_date` FROM `sym_entries` AS `e` LEFT JOIN `sym_entries_data_333` AS t333_1 ON (e.id = t333_1.entry_id) LEFT JOIN sym_entries_data_170 AS `d` ON `e`.`id` = `d`.`entry_id`LEFT OUTER JOIN `sym_entries_data_168` AS `ed` ON (`e`.`id` = `ed`.`entry_id`) WHERE 1 AND `e`.`section_id` = '27' AND t333_1.value IN ('4009') AND `d`.`value` IS NOT NULL GROUP BY `d`.`value` ORDER BY `ed`.`value` asc LIMIT 0, 17

Using "value" on an SBL table can not work, since SBL has a relation_id column instead.

See here: http://symphony-cms.com/discuss/thread/82064/2/#position-33

This has been fixed in 403e2f6.

If multiple recipient groups are available, the Email Newsletter Manager field will presume to send after "send" has been clicked even if no group is selected.

If you are using an ETM template for an ENM newsletter, the ETM's template preview will break:

Fatal error: Call to undefined method Lang::activate() in /Users/me/Sites/dev/maschine/extensions/email_newsletter_manager/fields/field.email_newsletter_manager.php on line 775

So this is related to the ugly Lang::activate() hack which we introduced in commit aa4f29b. (There is a similar bugfix hack in 995a0e7, BTW).

Looks like Lang::activate() doesn't exist anymore.

I will test if these bugfixes are still needed in Symphony 2.3.3.

I'm using Email Newsletters and ENM (while I migrate) on Symphony 2.2.5.

When I try to send a newsletter from email newsletters I get this error:

Error sending email newsletter Newsletter with id not found.

The corresponding error in the main Symphony log is:

UNKNOWN: SymphonyErrorPageHandler 0 - Newsletter with id not found. in file /srv/www/popchoir.com/public_html/symphony/lib/core/class.symphony.php on line 542

See thread in Symphony forum

In Symphony, handles always use hyphens. But ENM handles for senders and recipients use underscores instead.

This should be changed, because we will need to add the handles to the output XML as well (e.g. to be able to build frontend forms). But we must add this information (and manual database update instructions) to the README (for everybody who already uses the extension in production).

Even when empty, Email sender's reply-to-name and reply-to-email-address values will override the email template's values. It should be discussed if this should only happen when both values are explicitely set (i.e. not empty).

Related to #4. In the works.

Currently the Email Newsletter Manager field outputs the following elements to XML:

• subject
• senders
• recipient_groups
• template

It should be "sender", because there can only be one sender.

I still see three occurences of the MySQL class' getLastError function. According to the Symphony 2.3 docs these should be removed, but I don't really know how this exceptions stuff works...

I hope you can take a look.

/lalala/extensions/email_newsletter_manager/content/content.senders.php:
  163           else{
  164               $this->pageAlert(
  165:                  __('Could not delete: ' . Symphony::Database()->getLastError()),
  166                   Alert::ERROR
  167               );

/lalala/extensions/email_newsletter_manager/lib/class.emailnewslettermanager.php:
   47       }
   48       else{
   49:          throw new EmailNewsletterManagerException(Symphony::Database()->getLastError());
   50       }
   51   }

/lalala/extensions/email_newsletter_manager/lib/class.recipientsourcestatic.php:
  124           }
  125           else{
  126:              throw new Exception(Symphony::Database()->getLastError());
  127           }
  128       }

Posted on the Symphony website (by Komb):

If website's DB is in "utf8 unicode", it gave an error about conflict between unicode and general collations and mails were not sent (can't select recipients).

I solved it by adding proper collation for tmp tables query in class.emailnewsletter.php

Posted on the Symphony website (by Komb):

Root solves to "http://hostname/var/www/blah/blah/emailnewslettermanager/lib/" Workspace behaves the same, but with added workspace folder of course.

Very bad for building absolute image paths and such.

Custom (display) names for recipient groups, senders and email templates would be great to reduce clutter in the entry editor's email field. When organizing lots of recipientgroups, senders or templates you will probably namespace them (or at least have long names) in the Symphony backend. At the same time you probably want to display simplified names to the author.

Additional email headers are supposed to be supported (see sender files), but they are not added to the email when it is actually sent.

If an entry edit page is open in two browser windows, you can start the newsletter in one window, then start in the second one. Two things may happen:

• either: Incorrect Process Auth used. This usually means there is more than one process running. Aborting.
• or (if the first one has already finsihed): emails are sent twice and counted twice.

This is a major flaw. Starting a newsletter should never be possible if a newsletter for this field/entryID is already running or completed. (only cancel/stop/restart should be allowed).

Up to now, the ENM is only passing two params to the ETM:

• $enm-newsletter-id
• $etm-recipient (=email address)

We could easily enhance flexibility if we passed another param:

• $etm-sender (=email address)

This param could be used to filter datasources for the ETM, thus easing any "sender personalization", e.g. a contact address at the bottom of an email.

It turns out that this can be achieved easily. In fact it's already working, and I will push the fix when I assume it's fine.

These lines use Administration::instance() to find the current author. This, of course, can not work universally, but only in the Symphony backend.

It should be discussed if we remove this completely or try and replace it by something more useful (fallback: Author/Member/nada).

"Started by" should not be written on every save. It should contain the author resp. member who actually started the newsletter.

Posted on the Symphony website (by Komb):

It created "symemailnewsletters" instead of "customprefixemailnewsletters" as expected. Note: old newsletter extension was present, so maybe this was the cause of this (possible naming conflict).

Update: Not related to old Newsletters extension.

Currently the Email Newsletter Manager field outputs a recipient_groups element to XML. To be consistent, it should be recipient-groups.

An error appears when creating a recipient group. The entry gets created, but will not let me open it or edit it.

Upon creating the group:

Fatal error: Call to a member function fetchHandleFromID() on a non-object in C:\www\sitename\extensions\email_newsletter_manager\content\content.recipientgroups.php on line 173

The recipients are only filtered by a "yes" value of a checkbox.

Seeing the list with the group created and the (correctly filtered) number of recipients is ok. Only when I try to open the entry, the error appears.

No errors if entry is created without filters.

(Symphony 2.3.1)

See forum: http://symphony-cms.com/discuss/thread/82064/2/#position-40

When a recipient email address occurs in several recipient groups, this address will receive mutiple emails.

There should only be one email pre recipient per campaign (=newsletter).

This has been introduced in bca0faf. We must check is_object before atempting to get the sender handle.

This may break ETM previews and frontend pages alike.

The ENM reveals the start time of a newsletter (in the field and in the XML output), but not the completion time.

See Symphony issue — @brendo proposed a possible solution there.

In the newsletter field's displyPublishPanel function, all the states (cases) use

$this->_addStandardForm()

which creates hidden form inputs.

It is simply unclear if this is (still) needed.

Meanwhile, if an error occurs upon sending, the extension will allow to restart the newsletter without problems. But there is only a single generic error message. So if, for example, multiple senders are available and the author does not select one, he will see this generic error message ("error, see log file" or similar...). In these cases it would be good to display the real problem ("sender is missing, try again").

This could be solved by implementing additional statusses (like "error_sender", "error_template", "error_recipientgroup"), which would be a good occasion to clean up the code of the GUI's status switch. (There is a lot of repeated code for the different statusses.)

@creativedutchmen: I can do this if you like the idea.

The flagcolumn in the sym_email_newsletterstable seems to be completely unused. It has a default value of "idle", but the value is never set by the extension.

It should be removed. Since we are still in beta state, I don't think that we need an update function to handle this. (Existing installations may as well simply keep the column.)

TheinitEmailNewsletter() function receives the entry ID using the send button value. (Same applies to stopRestartNewsletter().)

However, it should be checked if this is useful at all. Since these functions are always working in a 'save/entry context', the entry ID could simply be found using $context['entry']->get('id').

This might also mean the the default "Waiting for input" state is not necessary. The extension is using a postSave delegate to trigger sending — so at this stage the entry ID should be available anyway.

(I vaguely remember that we invented the default "waiting" state mainly because we thought that we must pass the entry ID inside the button's value.)

It should be tested, however, if changing the default state of the GUI is useful to authors.

Looks like the completed_recipients DB field is only filled with a group's name if another group follows the completed one. So the last completed group will always be missing.

Might be a "timing problem".

The field's XML output needs 'id' attributes for the template, the sender and the recipient groups. Otherwise it would be impossible to use the datasource output in frontend forms (i.e. auto-generate the 'selected' attribute for option elements).

I haven't found any way to filter recipients dynamically based on a newsletter's pseudo_root value — except hacking the recipients file (by adding some real custom code in an additional __construct function). Unfortunately the file can be overwritten in the Symphony backend. It would be very useful to have an allowEditorToParse function which may be set to false (similar to datasources).

Obviously the extension does not check if the chosen recipient group is actually configured for the current field (in the section editor). This allows authors to send newsletters to any recipient group in the system by manipulating the DOM.

Probably the same applies to senders or templates.

Suggestion: Check if the posted value is actually configured for the current field. (If not, throw an error.)

(Theoretically this might as well be handled during field validation, but it's probably better to use custom logic and throw an ENM error.)

This extension's extension.meta.xml is missing compatibility attributes (@min and @max) from the releases element. It's easy to add, and will help people find the best version of this extension to use. See the spec here: http://symphonyextensions.com/schemas/extension/1.0/. Thanks! :-)

The Symphony convention is to use uppercase names for delegates.

If you try and save a recipientsource which generates a handle that already exists, you will see a warning:

Could not save: Recipientsource already exists. Please choose another name.

If you do the same with a sender, an existing sender with the same handle will be overwritten.

If multiple senders are available, the complete entry page will break when "send" is clicked without selecting a sender beforehand. An empty page is displayed. The newsletter is not saved to the database (sym_email_newsletters table).