View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0009687||phpList 3 application||Campaign Send Process||public||08-04-07 01:04||18-02-08 14:08|
|Target Version||2.10.7||Fixed in Version||2.10.5|
|Summary||0009687: Confusing use of the word "Both", indicating one email with both text and html and not two emails|
|Description||tried to find way to search bug database with zero success. so here goes...|
both txt and html formatted emails sent to whole list after reconciling with “mark all users to receive html”
listen up folks. this is happening across the board to all emails on all accounts in version 2.10.4. it is perhaps only supposed to do it on the test, but the point not yet made clear is that this is many times reliably reproducible and regarding the test little is intuitive.
now we're all a little irritated that our clients are ALL getting double emails which is classifiable as spam! [to paraphrase previous and now to quote direct]
"Two emails of the same message in two formats? Completely unprofessional, ridiculous."
total text html both PDF both
555 3 0 552 0 0
so basically, no matter what the user chooses when sending the message, that choice is overridden by settings that a good percentage of intuitive power users eager to start their email campaign would ever think of searching/finding/changing before believing all the relevant settings were set.
i don't want, and will not, go find/edit the config file at all to achieve something so basic and core to the concept of email list managment - i'd rather log a bug and ticket to create link in ui to key documentation.
main page > admin interface > manage users > reconcile users > select "mark all users to receive html" is nice advise that does not change anything. the problem stated is that all clients get two emails – both html and text – after reconciling users to receive html and selecting only html in the send off routine.
problem is that in "reconcile users" a key link is missing.
1. mark all users to receive html ONLY
2. mark all users to NOT receive txt
another soul says: In the subscribe page choose "Don't offer choice, default to HTML", so all the people will get the html messages. nice advise again except that this relates not to the email list but to one single user who is choosing to setup their own account
now this is just the 2nd hurdle for intuitive power users who resolved the first.
when an intuitive user goes to TEST their message and has read enough to know it is to arrive in 2 formats then they will assume the sending of both formats is not going to happen when they select html only in the “send message” routine/ui.
so it comes as a shocking surprise when the reports inform them that in fact they have sent text-only messages which is exactly what happened to us on our first real run post-successful tests.
we had to find out the painful way that "reconcile user settings” related to format override the listadmin’s settings in the “send message module”. the listadmin must somehow intuit to first go to main page > admin interface > manage users > reconcile users > select "mark all users to receive html".
but wait! your problems are only just beginning. we did that only to find that all customers would then get two emails – one for each format. great! stellar! phplist just created yet another non-intuitive hurdle.
see the need? great. now fill it.
total solution: a simple few words near the test button that says "more info" could link to a set of guidelines that spells out 3 extra prudent steps to do before launching a single email into the real world. seems obvious to some given phplist is stamped on both pieces of mail that will not earn points performing like this. but no. this problem was first logged 1 year ago.
there is no acceptable workaround short of modifying the config file which makes this a high-priority item to resolve. i rate this a P2 by any good bug database standards.
|Additional Information||is there a good reason that finding a link to the bug url http://mantis.phplist.com is so hard to find? i had to click phplist > support > search forums and then search it to find it in a post.|
might phplist put a link to the issue tracker like other sites do in the margin with a warning that asks people to check everything else first?
|Tags||No tags attached.|
What the "mark all users to receive html" does is to change a value in the phplist_user_user table to 1/0, so there isn't an option for text and another for html, it's just one value.
Have you check with a lot of users that they actually received 2 emails?
When you see the "both" col in the sent messages, and it has the number of users that actually should have received only html, it's because you forgot to check the 'Send as' "html" radio button in the format tab, while creating the message.
If the docs are not clear enough and you can contributte writing about the issue you were involved, that will be great.
"Both" means that a user receives ONE email with Both the text and the HTML versions in it. This is common to do, as some email readers cannot render HTML emails and will show the text version instead.
It does not mean they receive two emails. One of the most important features of phplist is that it will never duplicate a message to a user, provided of course you do not enter the same content twice in two different messages (which phplist won't check).
unless you can give us a way to reproduce this problem, it is going to be closed, as it's unlikely this is a real software issue and it sounds more like a confusion.
That would of course mean some update to the documentation would be useful, but it's not actually an error in the software.
However, it may well be that it happened, in which case it would be useful to know how to replicate the problem.
||by the way, keeping things brief, makes it more likely it gets read.|
a. send yourself a TEST message and know that you get 1 html and 1 text copy by design.
b. the user/emails are all set by default to receive text-only emails no matter if you select "send as html" option when creating the message before clicking send. so if you really want your targets to receive html, you must first go to main page > admin interface > manage users > reconcile users > select "mark all users to receive html".
c. now the report will show them all as receiving "both" html and text formats which hopefully means they received both formats in one email in case their client is not set/designed to display html. if this is the known, then why "mark all users to receive html" is not the default setting is difficult logic to reconcile? perhaps one enhancement is to make it the default.
* i can not prove nor do i believe that two emails were actually sent to each address after "reconciling users". i was drawing a conclusion based only on the report.
buried in this "alleged bug" are a few usability enhancements including a default value change to prevent joe blow from sending text-only messages even if he chooses "send as html":
1. make "mark all users to receive html" as the default setting
2. create a "reconcile users" button/link in ui
3. create a "more info" link near the test button and/or "send as html" button
I have updated the subject, as it seems this is all caused by the confusion in the use of the word "Both" which really means "one email with both text and html" and not "two emails, one text and one html".
Apart from that, I just noticed a posting in the forums where someone was complaining that phplist can even send an HTML only email, which according to them is not supposed to be possible if you work in the standards industry.
Bas, actions on this:
- sending an HTML only email should be removed. It's either text or multi-part Mime, with both text and HTML
- take out "Both" where it is displayed and replace with HTML. So that, basically HTML email means Both in one email.
That will (a) remove confusion and (b) increase use of standards (sending HTML emails only is not a standard)
0009687: Confusing use of the word "Both", indicating one email with both text and html and not two emails
Changed (hopefully) all displaying of 'text and HTML' to 'HTML'
Removed 'text and HTML' option from interface
Statistics will only show 'HTML' but will add the existing 'text and HTML' count to it
HTML will always include a text MIME multipart
Removed or commented out the string 'text and HTML' from all translation and help files.