Quote:
Originally Posted by Kiopa_Matt
Because it's a simple job. User joins, gets e-mail saying "click this link", user clicks link, and is allowed to access member's area. Regardless of software he's using, it should be quite easy, unless it's encoded with IonCube or something.
|
You are making some assumptions there.
I agree completely that an email confirmation/activation module is a fairly simple task for the most part.
However, that said, without a clue to the infrastructure involved, that is an assumption. As with any assumption, it may be right and it may be wrong.
This script would have to interact with an existing user database. The output of it, from what the op has said, is a double optin compliant email list, in addition to the user activation functionality.
A double opt in database requires 5 pieces of data minimally:
email address
ip of original opt in
date time of original opt in
ip of opt in confirmation
date time of opt in confirmation
Mod 1:
The first task is making the program send an email at sign up time. In that email would be whatever text the owner wants plus a link to the confirmation page. This could be a link to a static page where the user enters information or it could be to a unique link that when clicked will do the confirmation/activation automatically.
To do this we have to know where to hook in to the sign up routine (probably right after the user table write) and we need to send them to a page telling them that they will get a confirmation email. We also need to make sure that the user record is not activated yet. We also might have to create a unique link generator of some sort.
Mod 2. We need a script to capture the confirmation. This script needs to analyze data passed in from the link that was clicked to pull in the appropruate user data or have a screen for the user to enter their username and password OR email address to pull up the record. Whether the record is pulled up automatically or we pull it up from data that the user enters we then need to wrte the confirmation data somewhere and then mark the user as active so that they can now access the member area.
Database considerations:
Do we modify the existing users table or create a separate ancillary table to hold the new information? If we modify the existing user table then we might create a snowball effect down the line. Are there hard coded queries that additional fields will interrupt? Are there hardcoded backup/restore routines that will lose the fields, etc, etc.
If we go to an ancillary table then we need to modify the sign up routine to write the intial record to our ancillary table or we can create a database trigger so whenever a new user for a free trial is added a record is automatically created in our additional table. Again, there are database considerations to take into acount if we go with a trigger.
Site considerations:
Is the site templated or not ? Do we have to interact with smarty or another template system in some fashion? Is there a designer that will take our code snippets and integrate them properly with the existing layout or are we going to have to do that integration?
The answers to all of these questions affects how much time is involved in this quite simple project.
Just in my ever so humble opinion, of course.