In a site with ~33000 users, I found that about ~1900 sign-ups were never completed and essentially clutter up the user table. I am looking for opinions on the pros and cons, if any, of streamlining the default sign-up procedure to: a) Sign-up form only contains an e-mail field that the user fills in to confirm authenticity. b) The e-mail field is stored in a separate table along with the sign-up URL token. c) The sign-up e-mail contains nothing besides a sign-up URL which the user clicks as opposed to the current e-mail which contains a number of choices. d) The user is presented with a web page where he selects his username, password and assorted details (other than his e-mail for the first time) and is logged in immediately. e) Only after successfully completing step d) is the user account added into the user table. f) Perhaps an e-mail is sent upon successful completion of the procedure for future reference. Thanks, -K
I'm not trying to get get in the way of refactoring this registration procedure/tables in core, but I believe some contrib modules might help you get over these problems at the moment: http://drupal.org/project/email_verify http://drupal.org/project/inactive_user Cheers, - Amr Mostafa On 4/17/07, Karthik <narakasura@gmail.com> wrote:
In a site with ~33000 users, I found that about ~1900 sign-ups were never completed and essentially clutter up the user table. I am looking for opinions on the pros and cons, if any, of streamlining the default sign-up procedure to:
a) Sign-up form only contains an e-mail field that the user fills in to confirm authenticity. b) The e-mail field is stored in a separate table along with the sign-up URL token. c) The sign-up e-mail contains nothing besides a sign-up URL which the user clicks as opposed to the current e-mail which contains a number of choices. d) The user is presented with a web page where he selects his username, password and assorted details (other than his e-mail for the first time) and is logged in immediately. e) Only after successfully completing step d) is the user account added into the user table. f) Perhaps an e-mail is sent upon successful completion of the procedure for future reference.
Thanks, -K
On 4/17/07, Karthik <narakasura@gmail.com> wrote:
In a site with ~33000 users, I found that about ~1900 sign-ups were never completed and essentially clutter up the user table. I am looking for opinions on the pros and cons, if any, of streamlining the default sign-up procedure to:
a) Sign-up form only contains an e-mail field that the user fills in to confirm authenticity. b) The e-mail field is stored in a separate table along with the sign-up URL token. c) The sign-up e-mail contains nothing besides a sign-up URL which the user clicks as opposed to the current e-mail which contains a number of choices. d) The user is presented with a web page where he selects his username, password and assorted details (other than his e-mail for the first time) and is logged in immediately. e) Only after successfully completing step d) is the user account added into the user table. f) Perhaps an e-mail is sent upon successful completion of the procedure for future reference.
Thanks, -K
This proposal is nice. Not sure if it should be core though. I think that there are many ways to stream line the sign up process using contrib modules, such as logintoboggan, and others. Given that the default process can be overridden, I suggest that your proposal go to a contrib module, and users can pick and chose which way they want their site to be. -- 2bits.com http://2bits.com Drupal development, customization and consulting.
There are several contributed modules that deal with the situation you're describing Karthik. For instance, http://drupal.org/project/advuser http://drupal.org/project/account_reminder Either of these would be a great starting point to filtering out the unwanted users. On 4/17/07, Karthik <narakasura@gmail.com> wrote:
In a site with ~33000 users, I found that about ~1900 sign-ups were never completed and essentially clutter up the user table. I am looking for opinions on the pros and cons, if any, of streamlining the default sign-up procedure to:
a) Sign-up form only contains an e-mail field that the user fills in to confirm authenticity. b) The e-mail field is stored in a separate table along with the sign-up URL token. c) The sign-up e-mail contains nothing besides a sign-up URL which the user clicks as opposed to the current e-mail which contains a number of choices. d) The user is presented with a web page where he selects his username, password and assorted details (other than his e-mail for the first time) and is logged in immediately. e) Only after successfully completing step d) is the user account added into the user table. f) Perhaps an e-mail is sent upon successful completion of the procedure for future reference.
Thanks, -K
On 17/04/07, Lyal Avery <lyal.avery@gmail.com> wrote:
There are several contributed modules that deal with the situation you're describing Karthik.
Thanks Lyal and everybody else. I'm aware of solutions to contain these issues (or override the existing system via a contrib module). I'm looking for constructive feedback as to why this might be good/bad as the default implementation for core. IMO, this makes things simpler, quicker, cheaper and more usable on the whole. Cheers, -K
The reason this isn't included in core is that the a lossy model is more restrictive. Some sites want to streamline the user registration process so that there's no email validation (because they don't care if the user is validated or not). Others, like yours, want to have a completely regimented system. Going with the widest net makes the most sense for being universally usable. On 4/17/07, Karthik <narakasura@gmail.com> wrote:
On 17/04/07, Lyal Avery <lyal.avery@gmail.com> wrote:
There are several contributed modules that deal with the situation you're describing Karthik.
Thanks Lyal and everybody else. I'm aware of solutions to contain these issues (or override the existing system via a contrib module). I'm looking for constructive feedback as to why this might be good/bad as the default implementation for core. IMO, this makes things simpler, quicker, cheaper and more usable on the whole.
Cheers,
On Apr 17, 2007, at 12:15 PM, Karthik wrote:
I'm looking for constructive feedback as to why this might be good/bad as the default implementation for core.
because it makes it harder for sites that require admin approval (which all of mine do). for example, i added some required profile fields when people request a new account, and i use the additional info to decide if they should be approved or not. it's not clear to me how that would fit in to your proposal. seems like admin approval isn't considered at all, but IMHO, this is critical functionality for Drupal to continue supporting. so, if you're serious about moving this into core, please post a new version of your workflow that shows how and where admin approval fits in. thanks, -derek
Unless I missed something your proposal does not allow for the case where I want to allow people to register and login in at the same time but with restricted privilages (determined by role initially assigned) and then when they verify there email (using the link in the email) granting them complete privilages. Currently with core plus logintobaggon I can implement registration in a number of ways. Your proposal seems to narrow down the set of choices and I do not feel it belongs in core Steve Ringwood
Quoting Steve Ringwood <nevets@mailbag.com>:
Unless I missed something your proposal does not allow for the case where I want to allow people to register and login in at the same time but with restricted privilages (determined by role initially assigned) and then when they verify there email (using the link in the email) granting them complete privilages.
Currently with core plus logintobaggon I can implement registration in a number of ways. Your proposal seems to narrow down the set of choices and I do not feel it belongs in core
Perhaps a method where the email address becomes the password and you limit the privilages by determining if md5(user.email) == db.user.passwd? Sorry, I'm not at my normal dev computer and can't look up the formal fields. Earnie
Shooting from the hip here: IMO, there are 4 primary steps to registration: a) Verify b) Register c) Moderate d) Complete The current default implementation: b, a, b, c, d. Proposed implementation: a, b, c, d. In other words, all that I am proposing is that registration involve verification as a discrete first step (rather than the present hybrid version). All other permutations and combinations currently possible will remain so, as outlined below. Admin approval: a) Verify e-mail. b) Registration : User created. c) Moderation: tell user to await approval e-mail. d) Complete registration. The above will also ensure that admins only moderate verified users, which, I believe, is not the case currently. Restricted mode: b) Registration (with e-mail field): User created. c) Moderation: user is in restricted role. E-mail verification will complete registration. a) Verify e-mail. d) Complete registration. No approval required: b) Registration: User created. d) Complete registration process. ----- Step b) - registration will just be the default user edit form. There will be (by default) no question of auto-generated passwords and the like. The widest net is "prior e-mail verification" and this is an attempt at streamlining this process. There is no question of this becoming the only implementation.. just the default one. Logintoboggan etc. will still be around. Cheers, -K
Nice, clear explanation, Karthik. And I agree the process should be improved in the manner that you describe. You are correct that moderation does include non-verified accounts, which of course can mean wasted time on the part of the admins doing the moderation. +1 ..chris
Quoting Lyal Avery <lyal.avery@gmail.com>:
There are several contributed modules that deal with the situation you're describing Karthik.
For instance, http://drupal.org/project/advuser http://drupal.org/project/account_reminder
Either of these would be a great starting point to filtering out the unwanted users.
On 4/17/07, Karthik <narakasura@gmail.com> wrote:
In a site with ~33000 users, I found that about ~1900 sign-ups were never completed and essentially clutter up the user table. I am looking for opinions on the pros and cons, if any, of streamlining the default sign-up procedure to:
What do you mean never completed?
a) Sign-up form only contains an e-mail field that the user fills in to confirm authenticity. b) The e-mail field is stored in a separate table along with the sign-up URL token. c) The sign-up e-mail contains nothing besides a sign-up URL which the user clicks as opposed to the current e-mail which contains a number of choices. d) The user is presented with a web page where he selects his username, password and assorted details (other than his e-mail for the first time) and is logged in immediately. e) Only after successfully completing step d) is the user account added into the user table. f) Perhaps an e-mail is sent upon successful completion of the procedure for future reference.
I like the way Drupal does it. Really, if people want to remember your site they sign up. They may never login that is OK. You give them reminders in email and give sales promotion to the site. I.E.: In the email to the users give them a reason to login. In the registration instructions be sure you tell them that a computer generated password is given by email. Make sure that they understand that an invalid or bounced email address will only cause the account to be deleted. This helps reduce the amount of stupid accounts. I use the legal module on my sites which allows you to add fields to the registration form. Earnie -- http://for-my-kids.com
participants (8)
-
Amr Mostafa -
Chris Johnson -
Derek Wright -
Earnie Boyd -
Karthik -
Khalid Baheyeldin -
Lyal Avery -
Steve Ringwood