Hi, a few answers.
Lists can be simply defined from the admin side, giving them a name, or you need to use update_option(…) for the key “newsletter_lists” (it’s an array, WP takes care to serialize and unserialize).
To mark a subscriber as “imported” I suggest to use a list instead of the country, it’s semantically more correct.
You can possibly use the subscriber’s metas: we don’t use them too much right now, but it’s an option.
Stefano.
Thanks, Stefano.
I found out where the list names are kept … in the wp_options table. I am able to extract them and display them in my program with their names, if any.
The reason I don’t want to use a list to distinguish “users” from “subscribers” is that the plugin lets the admin change the list names, add/delete addresses from the lists. But I might look into that. It does, indeed, make more sense.
The other question was about the token. As I said, I create a token for users I add to the database using the PHP uniqid() function. It seems to work OK. How does the system use that token?
Also, I asked how the subscribe popup knows not to popup again for the same person each time he connects to our system?
Thanks.
The uniqid is ok, or you can use the password generator of WP. The popup uses cookies to track the closing.
I have everything working fine. Via my program that uses mySQL to manipulate the newsletter data base, I can add and delete people, add or remove them from lists.
I have some suggestions to make it easier for people like me who want to manipulate the database externally.
First, it would be useful to have a flag in the database to distinguish subscribers from people added externally. This would not be seen by the plugin users.
Second, having the list data in a newsletter table rather than in the wp-options table would make life a lot easier for external access. It would then be easier to have more flags for list entries. One flag that would be useful is a “lock” flag. If this flag is set, the list can’t have its name changed via the plugin, and probably its contents can’t be changed either.
This stuff would only be useful to people like me who have a need to manipulate the newsletter database externally.
Thanks
Hi, about the wp_options table this is the standard way to save options so we cannot change that, it would be an extra effort for something that already work well out of box by WP.
About the flags, you can use the wp_newsletter_user_meta or add a column to the wp_newsletter table: the upgrade process does not remove added columns. Or create a new dedicated table with the user ID and the flag.
Stefano.
OK. I can add a column to the newsletter table safely. Good news.
I don’t think the lists are an option, as you would normally think of options. The email rate (emails/hour) is an option. The lists are actually “tables” in a database sense. There is one row for each list, with the list number, the list name, the list flags as columns. I assume that you read in the list data from the options table at startup, and write it back out when the user changes the name, or one of the flags. Smells like a database table to me! (an aside … I am a database person … that’s what I do))
If it looks like a duck, walks like a duck, and talks like a duck, maybe it should be a duck!
Don’t think I am criticizing the plugin … I think it is great. We have been using it quite a lot. The subscription stuff, the way it works, is very clever. Nothing is more annoying than something that pops up every time you connect. I love the mail bounce addition! And I can live with the way the lists work. We are a small company, and we can enforce rules such as “Don’t change the name of the following lists, ever!” I just thought you might look at my ideas to see if they make sense to a wider customer base. I suspect there are a lot of customers who are similar to us. There are subscribers, and then there are others you get in via the import addition, of via database manipulation.
Just some thoughts. Great product.
Thanks for discussing these things with me.
Hi, I know the lists are not managed in a classical way: that is for historical reasons, and changing them now would be very dangerous. 🙂
Stefano, I have my upload stuff working just fine now. The newsletter database now has all our customers in it. What happens if someone tries to subscribe via the popup, and their email address is already in the database (i.e. via our upload)?
Second question, for testing, I want to delete the cookie the popup uses, so I can force the popup to appear. How do I identify the cookie in Chrome’s cookie list? What is the name of the cookie?
