Newsletter Made Simple Is Seriously Buggy

[applejack]

Hi All

I have found NMS to be seriously buggy the worst one so far is that if a user unsubscribes and then tries to re-subscribe using the same email address then it won't allow it as unsubscribing only changes the list settings to which they are subscribed to 0 i.e. no list.

Keeping them in the database if they are unsubscribed is a good idea, however to make use of it

1. They must be allowed to re-subscribe.
2. If importing users from a CSV file then they must be cross referenced so that if they are unsubscribed they do not get re-subscribed.

If anyone has worked this out then I would like to know.

This is using NMS v1.0.3 CMSMS 1.2.3

[calguy1000]

1. They must be allowed to re-subscribe.

This is fixed in NMS 2.0

2. If importing users from a CSV file then they must be cross referenced so that if they are unsubscribed they do not get re-subscribed.
  - no, I want the other behaviour..... if I'm importing from csv it's not a 'merge' operation it's an import, and whatever the csv file says rules.

[applejack]

Hi Calguy

Re :

2. If importing users from a CSV file then they must be cross referenced so that if they are unsubscribed they do not get re-subscribed.
  - no, I want the other behaviour..... if I'm importing from csv it's not a 'merge' operation it's an import, and whatever the csv file says rules.

However the reason why I think that the CSV file should not rule is that many companies keep an offline database and add to it ongoing. Therefore if a user has unsubscribed via the website then they are going to get re-subscribed from the CSV file which is not a good idea which is going to annoy the user when the get a further newsletter.

Where is version 2.0 is this available yet as 1.3 is the latest showing in the modules download?

[calguy1000]

NMS 2.0 is currently in testing.

[applejack]

OK thanks for letting me know and please bear in mind what I said about the CSV file because as it is currently then it is unusable for many companies so at least the option not to rewrite over the unsubscribed user would be most useful when importing the CSV file.

[cb2004]

I agree on the csv issue.

[calguy1000]

Agree with who?

[nivekiam]

As a business owner who runs a mailing list, I agree with applejack about the file importation.  If someone has unsubscribed, yet they are still listed in the offline file we add people's email addresses to, then I don't want to import them back into the mailing list database.  Getting new customers is hard enough, but trying to win back customers you've lost is a lot harder and there is a lot of people who are pretty sensitive about their email.

I know this is more work and more coding, but here is what I would like to see:

A checkbox to import all email addresses even if that email address has been unsubscribed.  I would make that unchecked by default.  That way someone doesn't accidentally import unsubscribed email addresses.  For those that want to overwrite everything, if they didn't, they can easily re-import, checking that box.

Then another checkbox/button to save that (or all options) as the current default, so next time you visit the page to import or even after an upgrade, you don't have to remember to check that option if you want it checked by default.

Everyone wins.

[calguy1000]

the NMS CSV import is currently an import.... it contains the username, the email address and the list that the user should be subscribed to.... and that list has to exist already. 

Also, when a user unsubscribes from a mailing list, I simply delete a row from a table that indicates which lists particular users are subscribed to.  There's no data telling if a user has explicitly 'unsubscribed' from a list.  If the user is not subscribed to any lists, then his user info is still in one table, but the other table that lists subscriptions has no information for that user.

I had these choices when writing the import stuff:
1) just import users into the database and don't add them to any list
    - Then there could be thousands of users in the database that are not subscribed to any lists, and there
      would need to be considerable bulk actions and stuff to manage it.
     
2) import users into the database and add them to the particular list(s) specified in the file
    - This just adds the user into the users table, and adds the appropriate 'membership' records into the user_lists table
      no significant amount of work required.

3) Ask the administrator on install which list(s) to add the users to
    (no real benefit over step 2).

so there aren't many choices here. 

And either way... NMS 2.0 is eminent.. so it's not going to change at this point.  Maybe later if there's enough priority.

[nivekiam]

I see.  Thanks for the explanation.  I can see that the "simple" options I mention above would actually be considerable work, as there is a lot more to take into account than I thought.

I guess I could have also clarified what I currently do.  I run an announce only mailing list and get a copy of all subscribe and unsubscribe messages.  When someone unsubscribes, I currently go into our offline file and remove that email address from the list (I actually move it to another place so we still have it in case we still need or want to use their email address to communicate with the person).  Every month I re-import the email addresses to the mailing list to insert any new addresses.

I'm currently using Mailman as that's the only mailing list option my host offers and we are not allowed to install our own mailing list.  Mailman appears to store email addresses with each list instead of having an account and being signed up for multiple lists.  But I'm not sure 100% if that's how it works.

My future plans involve either signing up with someone like ConstantContact or getting a second domain for my business just for the mailing list and hosting that domain with a different host.  That would give me more control over my mailing list.  That's why I'm currently looking at NMS and phplist.

[applejack]

Hi Calguy

I appreciate the complexity involved re the import because of the way that the tables are setup as I took a look the other day to see if I could re-write this myself but I am not a PHP programmer but have been a Perl programmer for 10 years.

There are 2 possible ways that I can think of how you could do a work around.

After the import could a script not be run so that it checks imported users against the table which has the unsubscribed users and if there are any users who have the same email address and are not subscribed to any list then they are deleted from the subscribed list. Another way would be to cross reference when the actual newsletter is sent out but I would have thought that the first option would be the better of the 2.

Anyhow just a thought.

[cb2004]

Agree with who?

I agree that a csv should not just be a straight import. It should check who is subscribed to what list and not subscribe them again. The customer could get very miffed and I am sure that re subscribing somebody is breaking some sort of computer act?