Support Forums

Get help. Give help.

Pending

Two email lists

Nov 14 2013 @ Peter Jackson 4 Comments
Type: Label: Status:

Hi Frank

I’d like to maintain two email lists. The first list is for paid-up members, which we’ll create and maintain using PauPress & its database and can manually send emails to via the Mailchimp list specified in Paupress.

The other list will be for the usual ‘sign-up-for-our-blog’ users, which needs only the email address to sign up (which PauPress does not seem to allow) and which will result in new posts being sent to subscribers automatically. WP & various plugins are already well set up to do this , adding new users to the WP ‘subscriber’ role. Or I can do it using Mailchimp, in which case I’ll need to create a second list to connect to Mailchimp directly via a Mailchimp signup form on our website.

Doing everything through Mailchimp has some appeal but I don’t need to interact with the database for the second set of users and don’t much want them appearing in the PauPress database.

So, any advice on how best to set up the second list please? Will Paupress interact cleanly with just one of two Mailchimp lists, or should I use a different set of plugins (like MailPoet/wysija) for the blog subscribers?

Thanks, Peter

4 thoughts on “Two email lists”

  1. Frank Neville-Hamilton Frank Neville-Hamilton says:
    November 18, 2013 at 2:38 am

    hey Peter!

    forgive the sledgehammer approach to your question but, hopefully, that approach should serve you well. I do appreciate your willingness to both take it on and to reply back – feedback is always good. – so, thank you. To your points:

    1) did you set this up in PauPress Options > Forms (tab) or PauPress Options > E-Mail Options > Forms (tab)? Either way, yes, there was bug as late as version 1.3 that did not correctly delete previous forms. If you add it back again and then delete it, it will be gone forever.

    2) You should be able to create an e-mail signup form at PauPress Options > E-Mail Options > Forms (tab) and it automatically knows to subscribe the individual since that is the expected behaviour. So, no need there to include the field itself though, I will take a look at that as it appears to be a bug in correctly setting the defaults. If you are simply segmenting your subscribers by the “true” value of the email subscription preference, then your work is done – unless, of course, you want to send an email to just subscribers and not members, in which case you’d want to qualify that this is not for members. Am I understanding this correctly?

    3) If someone unsubscribes from MailChimp, PauPress receives that notification and sets their subscription preference to “false” such that they will no longer fall into your queries of “show me everyone where subscription preference is ‘true'”.

    1. Peter Jackson Peter Jackson says:
      November 20, 2013 at 3:18 pm

      Hello again

      Thanks for your reply. I had used the sign-up form to sign up members, not realising that it was intended for subscribers in particular. I’ve fixed that now.

      Going back to my original questions, I understand that if I enable email for posts then when I write a new post I can complete the email section at the bottom and send it out to subscribers (only) via Mailchimp. Good – that’s what I want.

      But I also want to send emails to other groups (members, say) which will include include users who are not subscribed. From your documentation & Mailchimp’s, it sounds like Mailchimp will not send any emails to those unsubscribed users. Is that right? If so, how to fix?

      Thanks, Peter

  2. Peter Jackson Peter Jackson says:
    November 17, 2013 at 6:35 pm

    Thanks Frank

    Understood – just one list!

    Few minor points though:
    1. Previously I’d set up a new email-only form. But I’d forgotten to change the shortcode from an old form and the old one still got served up even though I’d deleted it. Do deleted forms still hang around in the WP database somehow?
    2. Your example of segmenting the list won’t work for me, so instead I’ve added the ‘subscribe to email’ field to the subscribe form so I can search for subscribers directly using this field. I changed it to checkbox/required set to ‘true’ but when the form opens it is set to ‘false’ instead. It then won’t close the form unless the user changes it to true, but that is obviously what the user wants so how can I make it come up ‘true’ when the form opens?
    3. If a subscriber later clicks on ‘unsubscribe’ in an email sent by Mailchimp, what does that actually do to their record in PauPress?

    Thanks again.

  3. Frank Neville-Hamilton Frank Neville-Hamilton says:
    November 17, 2013 at 2:54 am

    hey Peter –

    forgive the delay in getting back to you on this – I’ve been meaning to write back a substantial answer for you…

    There’s lots of ways you could do this but the “PauPress” way is derived from best practices we’ve gleaned and tested from MailChimp and other ESPs so, here are our three “rules of thumb”:

    1) You really should only have one list. While you may know that you have multiple lists your subscribers only think about what’s immediately in front of them and when they subscribe or unsubscribe, to them it’s final and absolute.

    2) You really, really should only have one list. A list is just that – a list. However, whatever decision you make that determines who you are sending to should be made elsewhere – like in a database where you can build exact queries based on whatever variables you want. With that in mind, we’ve made the search engine as flexible as possible so that you can save queries against it such that you can send emails to just subscribers or, just members or, subscribers who have potential to be members. If you have your total readership split between two lists then that gets harder to do.

    3) Your really, really, really should only have one list because you really do want everyone in your database. Subscribers that sign up and you may not want to track information about are always potential members and if they’re already in the database you can specifically target activities that you may not have even anticipated yet. For example, what if you have several subscribers who have signed up for your list and who have also contacted you through the website asking various questions about your organization – if you have that historical data you can send an email campaign to all those subscribers who have had one or more communications with you outside of email campaigns and offer them a special membership deal. Whatever percentage you convert is a good data point that your organization can learn from and adapt its techniques over time.

    With this in mind, I’d recommend that you keep only one list in MailChimp and pipe everyone through PauPress to it. Segment the list ahead of time based on criteria like:

    a) Members = everyone who has made a donation/payment in the last 365 days (for example)
    b) Subscribers = everyone who as NOT made a donation/payment in the last 365 days

    You can always hide elements of your database through your queries if you only want to focus on a certain subset (like members) and as long as they are in your database you can more easily get them into other things you do.

    As far as getting these people onto your list:

    Subscribers: you can create any number of email signup forms at PauPress Options > E-mail Options > Forms (tab) and the default is just an email address (point of fact, actually, you can create people in PauPress without a single datapoint – not that you would, but you could).

    Members: you can offer the subscribe option at signup or checkout or, turn on auto-synchronization and acquire them at any point and default to having them login to opt-out. With MailChimp’s webhooks automatically integrated in, you can simply go ahead and subscribe members and let them unsubscribe at the point that they don’t find your communications useful anymore if that indeed ever happens.

    So, sorry again for the delay and for the long response – I hope it’s helpful. Above all, try and keep things simple and in one place – it takes far, far less time to think through and create/remove segments of a single database than it takes to remember who is in what place at any given time across multiple properties.

Leave a Reply

Verification of an email address

Oct 30 2013 @ Yulia 8 Comments
Type: Label: Status:

is there a way to verify an email address in paupress?
Thanks
Yulia

8 thoughts on “Verification of an email address”

  1. Frank Neville-Hamilton Frank Neville-Hamilton says:
    November 7, 2013 at 10:59 am

    hi Yulia!

    thanks for getting back to me on this. We didn’t get this into the 1.4.3 release but it will be included as an option by the 1.5 release (if not sooner). That said, there are two other thoughts I’d like to share:

    1) because PauPress registration goes through the panel system, it has some intrinsic spam protection and logic built in so, that is one line of defense.

    2) In a coming release, we are also planning to provide an additional security layer that will let you wall off everything outside of PauPress to better insulate your site as well as deepen the logic to ensure all of your data is qualified.

    But that said, I’m going to leave this ticket open for the moment and will close it out when we deploy this enhancement. If it becomes a pressing need, please update me via this ticket, ok?

    thanks!

  2. Frank Neville-Hamilton Frank Neville-Hamilton says:
    October 30, 2013 at 5:44 pm

    hi Yulia,

    there is but can you give me some more detail as to what you’re wanting to do?

    thank you!

    1. Yulia Yulia says:
      October 31, 2013 at 6:21 am

      Hi Frank,
      I would like to have a possibility to verify the user account after registration. I mean before they are able to login they should go to their email and click the verification link.

      Thanks in advance for the reply
      Yulia

      1. Frank Neville-Hamilton Frank Neville-Hamilton says:
        November 6, 2013 at 9:37 am

        hi Yulia,

        we actually might be able to get this into the pending 1.4 release. have you tested the PauPress recover password functionality? if so and if you think that process might be appropriate for you, I can create an option to include a link back to the site in the welcome email that gets sent after registration.

        so, if someone registers (and is not presented with the option of creating a password) an email can be sent with a link back that will ask them to create a password – after which they could login.

        let me know if that is an acceptable use case to start from!

        1. Marra Apgar Marra Apgar says:
          December 26, 2013 at 5:52 am

          I’d like to see verification too. Not so much for fake e-mails, but honest typo’s would mean I may not be able to contact someone when I need to send them details on their purchase! 😮

          1. Frank Neville-Hamilton Frank Neville-Hamilton says:
            December 30, 2013 at 5:07 am

            I think this is slightly different but we are updating our verification for emails in the next release!

        2. Yulia Yulia says:
          November 7, 2013 at 3:11 am

          Hi Frank,
          sorry for the late response.
          I don’t really know if the users should get a second email with a verification link, as a user I always got only one mail. I think that helps to have at least a minimal defense against fake accounts (I expect that in our case – Russianpet – we will have a lot of the fake registrations).

          Yes, I tested PawPress password recovery and I think your idea about adjusting this functionality for verification purposes is just great! I am looking forward to it.

          Best
          Yulia

      2. Frank Neville-Hamilton Frank Neville-Hamilton says:
        November 1, 2013 at 2:02 pm

        hi Yulia,

        thank you for providing the clarification – it’s really helpful.

        this is interesting. I would assume that you would also need to have a mechanism for them to resend their verification link if they didn’t get the first email or deleted it by accident?

        I think this is all a good idea and in the 1.4 release that’s coming, we’re providing additional options to customize registration, login, profile management and logout. I don’t think we’ll be able to get this in the 1.4 release but it does seem like a good idea that could be fairly easy to implement in either 1.5 or 1.6, both of which are slated before the end of the year.

Leave a Reply

In checkboxes taxonomy, parent terms should be check if one of the children terms is enabled

Oct 16 2013 @ Alexandre Leroux 2 Comments
Type: Label: Status:

That one lies between a bug report and an enhancement request.

In the fields, for taxonomy (checkboxes), it’s great to have parent categories with children in it, but currently, if we check a child, the parent remains unchecked. What about checking the parent if any child is checked?

Example (don’t we like car analogies?):
Parent category is “Car”
Child terms are: “Toyota”, “Nissan”, “Saturn”, etc.
If I check / enable a child term such as “Toyota”, currently, the parent term, “Car”, remains disabled. I believe it should be checked when the child term is checked. Otherwise, the parent/child paradigm is used only for displaying purposes and inheritance is not considered, which does not make sense in my opinion. This has impacts on searches too: I can search for “Car” but results will not include items with Toyota checked but not Cars.

What do you think Frank? Thanks! — Alex

2 thoughts on “In checkboxes taxonomy, parent terms should be check if one of the children terms is enabled”

  1. Frank Neville-Hamilton Frank Neville-Hamilton says:
    November 7, 2013 at 10:51 am

    hi Alex,

    this didn’t make it into the 1.4.3 release but it will be in the 1.5 release for sure – possibly earlier since we may get in some incremental updates in the next couple of weeks.

  2. Frank Neville-Hamilton Frank Neville-Hamilton says:
    October 17, 2013 at 10:02 am

    I think that’s a good idea, Alex. Let me see if we can include that in the next release. If we can save a step in any workflow, that’s a win!

    thanks, as always!

Leave a Reply

Weird user logins for users added via PauPress

Oct 05 2013 @ Alexandre Leroux 3 Comments
Type: Label: Status:

Hi Franck,

Any idea why all users created via PauPress have a really bizarre user logins? Example, for a user named ‘Isabelle Vallee’, PauPress created the following entry in my wp_users table:

18 isabelle_JXZWU26_1380395197 $P$Br4CdWBAwcxB2i9bsbCl/851P.2XtM/ isabelle_jxzwu26_1380395197 isabelle.vallee@example.com 2013-09-28 19:06:37 0 Isabelle Vallée

The second column is the user_login, which is ‘isabelle_JXZWU26_1380395197’ … which doesn’t make any sense. The user_nicename isn’t better, it’s isabelle_jxzwu26_1380395197. The display_name is fine though (last column).

Thanks for any clarification! 🙂 — Alex

3 thoughts on “Weird user logins for users added via PauPress”

  1. Alexandre Leroux Alexandre Leroux says:
    October 9, 2013 at 8:25 am

    Hi Frank 🙂 My understanding of the WP usename requirements is low, but here’s some feedback ;

    (1) – If email address must be unique, why not simply use it as username directly? It would certainly make more sense than the random chars. If no email is provided, see (2).

    (2) – If (1) doesn’t work for some reason, why not use the firstname+lastname +timestamp as username? Timestamp of the user creation time in the form of YYYYMMDD.HHMMSS. That will make it unique and would be comprehensible and even have value (you know when that user was created directly in its username).

    Editing usernames feature? Certainly… we would clean those random chars right away 🙂

    Thanks Frank and take care — Alex

    1. Frank Neville-Hamilton Frank Neville-Hamilton says:
      October 10, 2013 at 4:30 pm

      hey Alex,

      always appreciate the input!

      We decided against #1 just so that we could enable editing of usernames down the line and for those who are actually using usernames the logic got complicated and needed a couple of preferences. On top of that, bi-directional synchronization with MailChimp necessitated additional preferences to control the internal synchronization. The application is complicated enough so, we try and defer to simplicity. 🙂

      #2 that you propose is a bit more refined than the current implementation which includes the first name, random characters and the timestamp but we ultimately went for the less-refined version because if you’re mass importing users via the API and you happen to have someone with the same first name/last name combination next to each other in your file you could get a conflict/overwrite that we’d have to write a lot of exceptions for since the processing happens on the millisecond level. So, we introduced the random characters to ensure that no matter what, you’d have a unique record even though, admittedly, it’s not the prettiest presentation.

      So, we came to the end solution honestly after a lot of testing and debugging. What we may want to finally do is allow editing of usernames and providing people the option to craft their own username structures with the caveats that “if you’re doing this, you might want to consider setting it to the extreme default” (which is where we’re at now).

      Welcome any more feedback on this!

  2. Frank Neville-Hamilton Frank Neville-Hamilton says:
    October 6, 2013 at 2:16 pm

    hey Alex,

    yep – those bizarre logins is a “feature” of PauPress. WordPress requires that all users have both a unique email and username – and the username is considered to be the default means of differentiating users. This assumes the social nature of blogs and other social media-like functionality but not much good for CRMs where users are acquired in many different ways where usernames are not very useful.

    So, PauPress defers to email address as the preferred unique identifier and therefore auto-generates usernames when one isn’t given at registration. You can opt to have people choose their usernames by adding that field in to any forms you use. And, we’re considering allowing the functionality to edit usernames in the near future.

    thoughts?

Leave a Reply

Support for importing & exporting contacts in the vCard standard

Sep 24 2013 @ Alexandre Leroux 1 Comment
Type: Label: Status:

Feature request: support for importing and exporting contact information from the vCard standard.

Reference: https://en.wikipedia.org/wiki/VCard

Thanks — Alex

One thought on “Support for importing & exporting contacts in the vCard standard”

  1. Frank Neville-Hamilton Frank Neville-Hamilton says:
    September 25, 2013 at 12:26 pm

    Got it, Alex!

Leave a Reply

‘User Reports’ search: bug when “Interactions >= 0” not showing >0

Sep 11 2013 @ Alexandre Leroux 10 Comments
Type: Label: Status:

Hi, first time with PauPro and my contact list is almost empty, so I may not well describe the bug’s behavior, but there’s a bug for sure! 🙂 PauPro 1.0.9. In ‘User Reports’, the Search tab.

The filter which has a problem is ‘Interactions’ when it’s set to >= 0. The result does show contacts with 0 interactions, but does not show contacts with >0 interactions. It should of course.

When I set that filter to >=1, it seems to work as expected. Let me know if you need more details to hammer to one out. Cheers — Alex
(by the way, I filled another bug report on WordPress.org, just before I purchased the Pro version)

10 thoughts on “‘User Reports’ search: bug when “Interactions >= 0” not showing >0”

  1. Alexandre Leroux Alexandre Leroux says:
    September 18, 2013 at 3:42 am

    Thanks. Update done 🙂 No rush on that minor bug – what matters is you’re aware of it and want to fix it eventually.

    The support you provide is stellar… this will clearly help PauPress succeed. Cheers — Alex

    1. Frank Neville-Hamilton Frank Neville-Hamilton says:
      September 19, 2013 at 11:41 am

      thanks, Alex – appreciate that! 🙂

      I’ll keep updating this ticket as we go.

  2. Alexandre Leroux Alexandre Leroux says:
    September 15, 2013 at 3:18 pm

    Hi Frank!

    When something say > = X and that’s not the results users get, no matter how you want to spin it, it’s a bug 🙂 Or at least confusing to users.

    For our use case, >=0 is useful to us. Example; my wife logs all her CRM contacts in PauPro. Say she wants to list all her users tagged as “Providers” in a list that shows the date of last interaction if any. Currently, there’s no way to do this correctly in PauPro because of that bug. PauPro will let me build the query, but I will not see all “Providers” contacts, only those which whom I had interactions before. That’s not what my query requested.

    That’s just an example of a use case where >=0 should actually provide the >=0 result and has value to the user (me ! :-)). You could also imagine a user wanting to find out which Contact-Type-Y (say Media contacts) never had more than 2 interactions. The query would be <=2. But PauPro would fail to show me Media contacts I have in my DB with whom I had no contact yet. That's confusing for the users – I asked <=2 and that's not what I got.

    Anyway, it's a relatively minor bug. It does not break the site or delete data inadvertedly 🙂 Hope this helps! — Alex

    1. Frank Neville-Hamilton Frank Neville-Hamilton says:
      September 16, 2013 at 11:01 am

      hey Alex!

      thanks for the additional detail – that’s really helpful. just to clarify, I’m not trying to spin it – my reference was how to solve the bug. What we’ve been considering is offering additional options beyond the simple >= or <=. Let's keep this thread open while we're working on a solution. thanks!

      1. Frank Neville-Hamilton Frank Neville-Hamilton says:
        September 18, 2013 at 2:47 am

        hey Alex!

        we just pushed the 1.1 update for both the basic and Pro plugins. I didn’t get your fix in on this update – I’m still actively working on it. however, your other bugs were dealt with.

        again, thanks for taking the time to explain your use cases. I think we’ll probably work to fix the bug as it stands and then add additional UI options down the line as they’re warranted.

        glad it’s a minor bug for you (though a bug nonetheless).

  3. Alexandre Leroux Alexandre Leroux says:
    September 12, 2013 at 6:27 pm

    Hi Frank,

    By the way, for the same filter, if I use <= 5, it does not show =0… which is <=5!

    Take care — Alex

    1. Frank Neville-Hamilton Frank Neville-Hamilton says:
      September 13, 2013 at 4:52 pm

      hey Alex,

      we’ve been talking about this and it may be just a UI problem to solve. you are correct that <= 5 should grab those users with 0 actions mathematically but, is it practically useful? It seems that the most common use scenario would be correct – show all users who have actually made an action <= 5. In scenarios where you're dealing with actions like purchases or donations where you might have "hyper" buyers/donors above a threshold (like 5 actions) and you want to convert users upwards, you may have too many "non-active" users if your user base is in the tens of thousands and that 0 actions group inflates the opportunity unrealistically. Similarly, >= 0 to include 0 “active” users is essentially everyone in the database by default, which isn’t terribly helpful is it, again, if you’re dealing with a large user base?

      That said, do you mind sharing what you’re wanting to do here in a bit more detail? I’d really like to understand a bit better. If you’d prefer to discuss that via email, let me know and I’ll reach out that way.

      Thanks!

  4. Alexandre Leroux Alexandre Leroux says:
    September 12, 2013 at 3:44 am

    Thanks. You can be certain (as you probably already found out), that you’ll hear me if I find bugs and/or have pertinent (from my point of view) suggestions.

    Quick minor question and out of curiosity: why is this support request of mine not listed in your list of support requests? (according to the links top-right of this page)

    Very minor unrelated bug: in mobile Safari (yeah, you know those numerous iPhones/iPads out there ;-)), the theme’s css you use on paupress.com fails to show the top of your site properly. We can’t see the “Support Forums” text in its entirety. Very minor bug, no need to actually fix this (spending time on the plugin is more important ;-))

    Take care — Alex

    1. Frank Neville-Hamilton Frank Neville-Hamilton says:
      September 12, 2013 at 1:28 pm

      hi Alex,

      the support plugin for PauPress is in use here but still very much in beta. all requests have to be manually categorized at the moment to show up in the taxonomy. oversight on my part – apologies!

  5. Frank Neville-Hamilton Frank Neville-Hamilton says:
    September 11, 2013 at 10:05 pm

    welcome aboard, Alex!

    and, let me say upfront the detail in the bug reports is awesome – thank you!

    so, yes, I can confirm this bug and if I recall, we debated on how to handle the operators on this. if you have any suggestions, feel free to throw those in now and this will be fixed in the next release of the Pro plugin.

    Generally updates to both plugins happen at the same time and that looks like this will happen in the next day or so. Maybe a two as we’re still testing the 3.6.1 update.

    thanks!

Leave a Reply

« ‹ page 11 of 11 › »
Cancel