Feature Request: SSO Integration without account creation

[raamdev]

Some sites may want to use the Comment Mail SSO Integration feature to make it easier for commenters to fill in the comment form fields, however they may not want an associated WordPress account created on their site. (A whole WordPress account just for leaving a comment is a bit extreme for some sites.)

It would be nice to have an option that allowed you to enable and configure SSO, but prevent an actual account from being created, i.e., the SSO integration simply fills in the comment form fields and that's it.

[RealDavidoff]

This is a great idea, Raam, as always! You may want to take a look how the plugin "Super Socializer" does it, they have that feature. Experience tells me: Yours will work much better. ;-)

[RealDavidoff]

Raam, Jason, there is no "Improvement suggestions here please" link visible in CM login area, so I trust you won't beat me hard that I leave it here for you:

Observations - URGENT improvement suggestions marked *

1. Return to "website name" - Why the " " ?? Leave out, makes no sense, you are not quoting us. Same here: You'll be notified about all comments/replies to: "German Shepherd Dog Training" - it's linked, quotes are needless if not irritating (quotes are used to, well, QUOTE someone!)

2. The "Subscribe without commenting" and "Manage my subscriptions" links open in a new window/tab. This doesn't make sense, and is needless: If user doesn't comment then he doesn't click the send-comment button at the end of the article that he has just finished reading. So keep him in the same window/tab.

Sidenote tip, because I noticed the same issue with s2m:
Most sensible is: Always open a NEW window/tab for EXTERNAL links, and whenever the user wants/needs to continue reading (or filling in data) on the current page but shall be able to see additional information on another internal page. Links before the end of an article likely meet this criterion (if the article is good enough!), but if the linked NEW article is standalone (not just helping to understand the current page) then keeping the reader in the SAME window/tab is least annoying. - And obviously, links that open a new window/tab should be marked as such. This is brilliantly done in s2m, but not in cm.

3. * Add new subscription, Post (required) - we already disabled that users can choose from all post titles, because that's ... I am lost for words, who had that idea?
   Think: There are tons of websites that do NOT want that users can subscribe to anything other than the page they are on (they've been sent a link to, potentially!). Heck, that's the key benefit of your major product s2m! To route users through your content the way you want.
   Eg, our subscribers get programmatically a weekly email with a link to a certain page of their booked curriculum (which obviously is based off their subscribe date, as well as their communicated interest). The content is our ASSET, so NO ONE shall get to see a drop-down of all pages! And without this new plugin, no one did. This is the ONE, worst, unbaked feature, by far. I hope my words are clear?

So, my simple (obvious!) suggestion: Let us choose between your present dropdown, and offering only the PRESENT page/article they are on (are coming from). Surely they shall be able to manage existing (=past!) article subscriptions. But they must NOT be able to select any (future!) pages/articles outside their curriculum, outside what they've read yet (in our case, the links they've been sent yet).

Your dropdown doesn't even make sense: Why show someone hundreds of pages/articles he can subscribe to (or 2,000! - your suggested max) which they haven't even read yet!!?! You wanna kill them with information overload?
So again, "Add new subscription" must allow to ONLY add that one page they are coming from. Prepopulate the field, or better, make it without question that they will subscribe to the CURRENT page only. Frankly, no one right in their mind would even WANT to be offered to subscribe to something they haven't read yet!! - And no, for such basic functionality we do not want to have to create our own template, if you thought to suggest that.

4. * Subscribe to what? "All comments/replies", yes! The dropdown to individual comments is impressive, but that's about it! Because even with enabled nested comments, how BIG/much-commented must an article/a site be(!!), to make it likely that readers want to get notified about replies to a SPECIFIC comment only?!? It appears that if a user selects from your dropdown, he will ONLY get notified if that PARTICULAR comment receives a reply, right? That makes little sense: When a user LIKES an article, and so is interested in further information about that topic (through comments), then in 99.9 of a hundred cases you can bet the user wants to know just that: when the next comment is made on that topic! He does NOT want to be limited to a particular comment (let's leave the odd people out of the equation).
   So: BIN the dropdown here as well. It's more confusing and off-putting(!), than helpful.

5. And yes, they should certainly not need to fill in their details (and AGAIN!?!) if they have and want to use a SM account. You have created a github on this, you said. - But, number 3 above is FAR more important/urgent, that's a MUST-have. This point 5 here is a nice-to-have.

6)"Last name" - why? The first name with the associated email identifies a person and allows to address the person in a friendly way. If you thought of cultures where you address people with the surname, still no point: then just make one field as well, call it "Name"). But I would certainly support one field, and called "First Name".

7. "Delivery option" - once you say "asap", then you say "instantaneous". Why use different words for the same thing?

8. Why write there "If empty, you'll be subscribed to all comments/replies; i.e. NOT to a specific comment." - You can't even make the field empty. Try it! Don't warn the user of useless stuff. And you don't need to anyway if you offer them to subscribe to (any) comment to the article they have just read and LIKE. That's enough. They don't need to know the id, they wouldn't even need to read the post title again - though this would be nice.

9. The footer has smaller width than the rest, and so "Privacy Policy" needlessly brakes into a new line.

10. The text in Statistics, under Exclude, is not legible. Likewise, the standard form has infinitesimal small text (obviously a css overwrite from some other plugin). I suggest to define your own text-size, to be sure it's legible.

11. "You are receiving this email because asked to be notified about all comments/replies to:" - because YOU asked

To be continued when I have time to waste more time (?) :-)
Hey, I am trying to help here!

[raamdev]

@RealDavidoff Thank you SO much for all of your feedback. :-)

---

quotes are needless

I agree. I opened an issue to fix this. See #201

---

external links should open in new tab/window, internal links should not

I agree. I opened an issue to fix this. See #202

---

3. * Add new subscription, Post (required) - we already disabled that users can choose from all post titles, because that's ... I am lost for words, who had that idea?
   Think: There are tons of websites that do NOT want that users can subscribe to anything other than the page they are on (they've been sent a link to, potentially!). Heck, that's the key benefit of your major product s2m! To route users through your content the way you want.
   Eg, our subscribers get programmatically a weekly email with a link to a certain page of their booked curriculum (which obviously is based off their subscribe date, as well as their communicated interest). The content is our ASSET, so NO ONE shall get to see a drop-down of all pages! And without this new plugin, no one did. This is the ONE, worst, unbaked feature, by far. I hope my words are clear?

So, my simple (obvious!) suggestion: Let us choose between your present dropdown, and offering only the PRESENT page/article they are on (are coming from). Surely they shall be able to manage existing (=past!) article subscriptions. But they must NOT be able to select any (future!) pages/articles outside their curriculum, outside what they've read yet (in our case, the links they've been sent yet).

Your dropdown doesn't even make sense: Why show someone hundreds of pages/articles he can subscribe to (or 2,000! - your suggested max) which they haven't even read yet!!?! You wanna kill them with information overload?
So again, "Add new subscription" must allow to ONLY add that one page they are coming from. Prepopulate the field, or better, make it without question that they will subscribe to the CURRENT page only. Frankly, no one right in their mind would even WANT to be offered to subscribe to something they haven't read yet!! - And no, for such basic functionality we do not want to have to create our own template, if you thought to suggest that.

Yes, I fully and completely agree with you (@jaswsinc, on the other hand doesn't feel as strongly about this as I do). There's a bunch of discussion about this here, which I recommend reading for background if you're interested.

In any case, we intentionally hid links to the Add New Subscription form in the last release (see #108 (comment)), however it looks like we overlooked the fact that "Subscribe Without Commenting" uses the Add New Subscription page too.

I've opened an issue to fix this. See: #203

---

4. * Subscribe to what? "All comments/replies", yes! The dropdown to individual comments is impressive, but that's about it! Because even with enabled nested comments, how BIG/much-commented must an article/a site be(!!), to make it likely that readers want to get notified about replies to a SPECIFIC comment only?!? It appears that if a user selects from your dropdown, he will ONLY get notified if that PARTICULAR comment receives a reply, right? That makes little sense: When a user LIKES an article, and so is interested in further information about that topic (through comments), then in 99.9 of a hundred cases you can bet the user wants to know just that: when the next comment is made on that topic! He does NOT want to be limited to a particular comment (let's leave the odd people out of the equation).
   So: BIN the dropdown here as well. It's more confusing and off-putting(!), than helpful.

I strongly disagree with you here. The ability to subscribe to Comment Replies Only is one of the most popular and most-requested features of a comment subscription plugin! I know from having worked on Subscribe to Comments Reloaded (which has over 30,000 active installs) and from using comment subscription plugins on several sites.

Most readers subscribe to comments for one reason: To be notified when someone replies to a comment they left! Otherwise, if they leave a comment and someone replies, they have to come back to the site every day to see if anyone replied to a comment they left on the site.

If they subscribe to all comments and the post has dozens or hundreds of comments, they're going to get a LOT of noise! But if they only receive notifications about replies to THEIR comment? Then the notifications are relevant.

It's true that some readers will want to receive ALL comments/replies, but 10+ years of blogging experience (and tens of thousands of comments) has taught me that's NOT the norm. (In fact, the reason that the Subscribe to Comments Reloaded plugin gained so much popularity over the past few years is specifically because of the Subscribe to Replies Only feature, which I worked quite a bit on.)

In any case, Comment Mail allows you to choose the default subscription option for your comment form in Comment Mail → Config. Options → Comment Form:

---

5. And yes, they should certainly not need to fill in their details (and AGAIN!?!) if they have and want to use a SM account. You have created a github on this, you said. - But, number 3 above is FAR more important/urgent, that's a MUST-have. This point 5 here is a nice-to-have.

Yes, I agree. If the Comment Form itself gets pre-populated by a cookie or from being logged in, the Add New Subscription form (when subscribing without commenting) should pre-populate the name and email address fields.

I've opened an issue for this. See #204

---

6)"Last name" - why? The first name with the associated email identifies a person and allows to address the person in a friendly way. If you thought of cultures where you address people with the surname, still no point: then just make one field as well, call it "Name"). But I would certainly support one field, and called "First Name".

Last Name exists to mirror the WordPress user account fields, and the Last Name field is optional so it can be left blank if desired:

That said, I agree it makes more sense to mirror the WordPress Comment Form fields (Name only, instead of First Name + Last Name). I've opened an issue for this. See #205.

---

7. "Delivery option" - once you say "asap", then you say "instantaneous". Why use different words for the same thing?

I agree. That should be fixed to improve consistency. I opened an issue for this. See #206

---

8. Why write there "If empty, you'll be subscribed to all comments/replies; i.e. NOT to a specific comment." - You can't even make the field empty.

Right. I agree. That shouldn't be there. I opened an issue for this. See #207.

---

9. The footer has smaller width than the rest, and so "Privacy Policy" needlessly brakes into a new line.

Where is this referring to? Can you provide a screenshot?

---

10. The text in Statistics, under Exclude, is not legible. Likewise, the standard form has infinitesimal small text (obviously a css overwrite from some other plugin). I suggest to define your own text-size, to be sure it's legible.

Can you provide a screenshot?

---

11. "You are receiving this email because asked to be notified about all comments/replies to:" - because YOU asked

Ah, good catch. Thank you. I opened an issue to fix this. See #208

[RealDavidoff]

4. You disagree is fine, but you misunderstood or I mis-explained then. That commenters want to subscribe to replies to their OWN comment is a given. No one will argue about that.

But from sifting through 300,000+ comments in my life I can summarize: Not one that I saw that a user wanted to know of replies to someone else's comment! Only their OWN. In fact, in most niches/websites these days visitors don't even glance over all prior comments, their sole focus is to post their OWN question - and hence they want to know when it's been answered. This will vary slightly with niche (and quality of the website), and you may happily keep your massive dropdown for THIS (comment selection), but the two most sensible options BY FAR should then be at the top.

1. Replies to my OWN comment
2. ANY reply to this article
   In fact, I would show a thick line under these to seperate from useless list items.
   Or better, a tickbox for 1) and a tickbox for 2), and if you insist because of your wider experience in different niches, an extra dropdown for the rest.

[RealDavidoff]

Oh, and as reminder, we can NOT turn on the plugin before earlier 3) is solved. :-(

[raamdev]

But from sifting through 300,000+ comments in my life I can summarize: Not one that I saw that a user wanted to know of replies to someone else's comment! Only their OWN.

Oh, right, and I agree. Yes, I did misunderstand what you were saying. You were specifically referring to the ability for readers to subscribe to replies to someone else's comment using the pre-populated dropdown box on the Add New Subscription form:

I've created an issue so that we can add an option to disable that behavior. See #210.

[RealDavidoff]

First of all, congratulations to the new commentmail updates, I have finally updated (scared because of template changes made) and after a bit of tweaking got it the way we needed it, thank you all!

Question: This thread "SSO Integration without account creation", has this feature request been implemented in the meantime?

We haven't turned on sso yet because it seems still to create wp accounts, correct?
I am curious as the feature would still be much much loved!

[raamdev]

@RealDavidoff This feature has not been added yet, no. But it's still in the pipeline. :-)