VBulletin + Amember: Users - Please share Info!

Okay, Alex! NOW Your solution makes total sense to me! I think I understand exactly what you've done and I completely agree with and understand your solution. In fact I totally agree with your decision NOT to replace the vBulletin login module too. As a software professional, it makes perfect sense to me not to try to replace such a large part of vBulletin's code! (On this one, I think you're wrong, VIP. There are dozens of enhancements, patches and hacks to vbulletin (including several custom ones I developed myself or paid to have developed) that DEPEND on making changes to vbulletin's registration module. If Amember were to replace that module, you'd never be able to apply ANY of those patches to vBulletin. That would clearly be a very undesirable thing to do.

The truth is, Alex, I was VERY concerned earlier this year when I understood you to say Amember was designed to completely replace vBulletin's registration module. Frankly, I thought that was a VERY bad idea for all the reasons I stated above and more. I still think that would be a bad idea.

In response to your question about "why I would want to import all vBulletin members into Amember", the truth is I do NOT want to do that. I merely assumed I would HAVE to do that if Amember was designed to replace vBulletin's Registration Module AND its Login Module. As I said, that's what I thought you told me in our earlier correspondence on this subject. If that is NOT necessary, I agree. There is NO need to convert all vBulletin members to AMember.

Yes, you are correct, Alex. I now have a free vBulletin site and my goal is to gradually make it a paying members site over time. However, before I require a user to pay, I STILL want him to have some period of FREE ACCESS to give him a taste of what he will get for his money. In my mind, this free membership is like a shareware software demo. It is designed to let the user see what he can do by giving him a taste of our capabilities but it only lasts for a short period and will NOT be free forever. After 10 days or so, the free membership would expire and payment would be required if the user wants to continue using the site.

As I understand it, this "free test drive" is easy to handle in vBulletin. All I need to do is create two user groups that I'll call them "TestDrive" and "LimitedAccess". After a user registers and confirms in vBulletin, he is placed in the "TestDrive" user group. During this phase, he will have access to most of our features for a period of say, 10 days. After that, I'd have vBulletin automatically move the "TestDrive" user to the "LimitedAccess" group, which has the effect of removing most of his access privileges. Once this happens, he will only be permitted to "window shop" (e.g. fewer forums, no forum postings, no chat, less image galleries, only thumbnail image access, no library download privileges, no video previews, no classified ads, no free email account, no search engine access, etc.)

The first time a user visits AFTER he has been moved from the "TestDrive" user group to the "LimitedAccess" user group, vBulletin would call Amember. In response, Amember would install a new durable "LimitedAccess" cookie on his PC. That cookie will be used to block his ability to log out in vBulletin and can be used to limit his access to other site software as well. This has the effect of preventing him from registering again. I would also patch my other software (ImageFolio, IndexU, Classifieds, etc.) to deny access to users who have the LimitedAccess cookie and send them to Amember's sign-up screen each time the user tries to use those programs.

After he registers, pays and logs-in through Amember, Amember would move him to a third vBulletin user group called "Members" ... or depending on what Membership Plan he chose, it might move him to one of several different vBulletin user groups (for example: FreeAreaMembers, LimitedSubscribers, FullSubscribers, VideoSubscribers, etc.). When he pays, Amember would also remove the LimitedAccess cookie from his PC. This would enable the user to login and logout through vBulletin again.

Members of the "Members" group will have full access in the same way they did during the TestDrive period. In fact, he might even get MORE capabilities as a member than he had during the TestDrive. He will remain in this group until his paid membership expires or is canceled. When that happens, Amember will change his vBulletin user group back to "LimitedAccess" and the next time he visits, vBulletin would call again call Amember. In response, Amember would again install the LimitedAccess cookie.

If a completely NEW user registers and pays through Amember the first time he visits, Amember would also need to add that user into vBulletin's member database as a member of the "Members" group.

The only other change I would make in what you are doing now, Alex, is I would never allow ANY user to register in Amember with a username that's identical to an existing vBulletin user UNLESS he also provides a password that matches vBulletin's existing encrypted password. It makes no sense to me to let a user to have the same username but two different passwords on the same site. This is guaranteed to produce great confusion for users!

This solution only requires the user to enter through Amember's login screen once -- the day he decides to pay. After that he never needs to see that screen again until after his membership expires. But it lets Amember totally control his vBulletin access and his access to other site features as well!

From what I can see, this approach requires only three small patches to vBulletin. They are:

1: Create a simple vBulletin patch that calls Amember whenever a LimitedAccess user visits. Amember's response will be to look for the LimitedAccess cookie. If it exists, Amember does nothing and returns control to vBulletin. If it does NOT exist, Amember creates that cookie first and then returns control to vBulletin.

2. Provide a patch to vBulletin's logout program that checks for the existence of the LimitedAccess cookie. If that cookie exists, the logout program does nothing and returns control to the module that called logout. If it does NOT exist, the logout program logs the user out.

3. Provide a patch that deletes a user from Amember whenever the Webmaster deletes him using vBulletin's Admin control panel.

I admit there might be several changes required to Amember. But even those changes would be small. For example, Amember would need to create and remove the "Limited Access" cookie. In addition, it would need to be changed to deny registration to any user who uses an existing vBulletin username but does NOT provide the correct password for that username. In short, Amember would need to enforce a rule that says it only allows one password per registered user.

Did you understand what I said, Alex? And did I get this right? Or have I overlooked something?

In case you cannot tell, I am a trained software systems analyst with over 36 years experience in the computer industry. It is my job to analyze software systems and figure out how to make changes to them with the least possible impact. For the Amember to vBulletin integration I have tried hard to keep the required changes to an absolute minimum!

Best Professional Regards,
WebSissy

No it does NOT "already work" exactly this way, Alex. You've said several times that a user CAN register again in Amember with the same username and a different password. I've said I think allowing the user to have two passwords is a VERY bad idea. Can that be changed?

Also, it's evident to me that you do not have the limited access cookie technique I described in place now either, Alex.

Yes, I know that is true... and so do YOU. But most USERS do NOT know that. Plus even if the user DOES know how cookies work, unless he's very smart, he's unlikely to think of that trick when he discovers he cannot logout. Furthermore, if he DOES use that trick, he will be forced to clear MANY (perhaps hundreds of) other cookies at the same time! So if he figures out he can force a logout by clearing his cookies, I suspect the pain he'll go through later will teach him to NEVER do that again!

I realize it's hard to make it IMPOSSIBLE for a user to register a second time in order to get another free test drive, Alex. I'm not asking you to do the impossible. I'm only asking you to make it very hard. Of course, you could make it even harder by crating a registration patch that compares the IP address of a new user with the IP addresses of all existing Users and refuses to create a new account if an account already exists for that same IP address; but I did not ask you to do that. I just want to make it as hard as we can for a LimitedAccess user to log out and re-register AND I want to make it damned painful if he does that too. Forcing him to clear ALL his cookies in order to get rid of one hidden cookie that's keeping him from logging out seems like an extremely painful penalty to me. ;-)

Tell me, Alex, how many times would YOU be willing to do that in order to force your way back into a free site for another few days? I might do it once... but after I realized the penalty I had paid, I would NEVER EVER do it again!

NOW, do you see my logic?

Best Professional Regards,
WebSissy

Okay... I'm not going to argue with you on that one, Alex. I certainly assume you SHOULD know how it works. So you're telling me that a user cannot register in Amember using an existing username UNLESS he also has the correct password? Does that mean if he tries to register as "websissy" and does not know my password he is forced to choose a different username?

What about my limited access cookie suggestion? Is that something you can (and would be willing to) implement? It seems like a very limited vBulletin hack and an easy change for you to make. In my mind once you've done that, Amember becomes a more useful tool for webmasters who want to use it to limit access and manage memberships on their vBulletin sites.

I'm not sure what can be defined as a "reasonable" price where the average cheaper-is-better internet user is concerned these days... but I've been thinking in terms of an annual membership fee of just under $20 or a quarterly fee of roughly $8. Personally, I think that's a very fair price.

One more thing for you to consider... I believe your price for Amember should be broken up a bit more. Although your competition in this market is fairly limited. Other vendors do offer similar membership management solutions at prices in the $100 - $125 range. But even if we ignore that, if one considers pricing-to-value, all of vBulletin sells for not much more than you are asking just for Amember. I've thought about this a lot and I honestly believe a license fee in the $100 - 125 range with 6 months of free support plus new-version upgrade fees of say $30 - $40 and a modest annual (email and forums) support fee of something like $35 would make your product MUCH more attractive for customers to buy. This is a market where as prices approach $150 they tend to limit sales rather than increase revenue. PLUS separating support and upgrades from your base price has the added advantage of helping you create a continuing revenue stream which would help support the product over the long term.

Thanks for listening, Alex. I hope my thoughts and suggestions have been helpful to you.

Best Professional Regards,
Thomas

Thanks for the Thread!

I would like more information concerning a sentence found at the very start of the thread: "To keep things simple, you should disable registrations in your Vbulletin, and redirect all new customers to aMember signup page."

I saw this in the user manual, but after searching Vbulletin's manual and forum I find no way to do this.

So, how do I turn off registrations for Vbulletin? Or better yet, how do I modify the link "register" to point to the Amember sign up form?

Love and light,

Michel

Turning off vB registration...

Dear Michel...

First, please realize the change you are considering is a "hack" to vB. vB does not advise you on hacks. That's why it's not in their manual. Remember, doing such things voids your vB support warranty. So, you are on your own when making it. Still, this is not a hard change to make even though you will need to make it in several places.

Although I still believe replacing vBulletin's registration module is a bad idea because it will prevent you from installing other registration hacks later, the thinking reflected in your last question is exactly the way I'd go if I wanted to "turn off" vBulletin's registration. Here's how to do that.

Go to vBulletin's Admin control panel and open up the Styles and Templates Manager submenu... then for each style you have installed use the "Search in Templates" feature to search for all occurences of "register.php". This will highlight all templates where "register.php is referenced. You'll find there are roughly a dozen places in vB's base templates where register.php is referenced.

Look carefully at this list and make special note of any templates that are listed in ORANGE. Templates listed in white or blue are "base modules" which have never been modified and reflect vB's base code. Those listed in orange already contain changes from the "base product". As a result these modules cannot be reverted back to base code without losing some functionality you may already be relying on!

Next, one-by-one open each module you're going to change by double clicking on its name and use the find button below the window to search for all occurrences of "register.php" in that module. You'll find all those references are contained within hyperlinks. I highly recommend starting with the NAVBAR template. It contains the primary menu link to registration.

Now, copy the line containing the register.php reference you want to change. Then comment out the replace original line by putting an "!" at the front of it followed by your initials and the date. This will make it easy to find your changes later.

Next, paste in the unmodified copy of the line you intend to change directly above or below the line you commented out and change that version to reference aMember's registration module instead. This should produce the results you want. To be certain your change works without doing any major damage, make the change in just one place to start with and TEST it first. Remember, the hyper-reference contains an implied path. So if it doesn't work as expected, make sure you verify that the aMember program is exactly where you said it should be. The NAVBAR is a good place to start because that's the main menu bar for vBulletin and it contains the reference to register.php that appears in vBulletin's main menu when a user visits who is not already logged-in. (Note: The Main Menu's [Register] link does NOT appear in the menu if you ARE logged in. If you go to the Forums home page and do not see it, log out!)

If you've never made a change like this before, be very careful and proceed slowly step-by-step. Remember to look for and change ALL templates where references to vB's register.php module occur And to do it in every style you have installed for your site. If you manage to BREAK something and the module was unchanged before you started, you can always return to the template editor and use the [RESET] button just below the editor window to revert the template back to the way it was in the base product before you started changing it. For modules that had been changed previously and were thus listed in orange in the original template list, you'll need to carefully remove your changes by hand rather than using the reset button.

Good luck. If you need more advice or help on this, come back here and post and I'll do what I can to help you.

Best Professional Regards,
WebSissy

I have vBulletin 3.5 (gold) installed. there is an option to disable registrations (don't know about other versions). Amember however can still perform its inserts into the database and bypass this.

*side note* that was the most long winded thread i've ever read!

Alex, What happend when a user change his password on vbulletin? knowing amember password and vbulletin password are encrypted different? wouldnt that
confuse the end-user by trying to log with his "new" password, and amember denied him access, thought is different that the one store on amember tables?

Does amember provides a custom user cp tool, and vbulletin admins need to take off vbulletin registration and user cp, to prevent confusion?

I am a vbulletin admin btw, i just concern about this, before i jump up into your subscription system.

This is exactly the technique I use and the one (IMHO) which will cause you the least amount of headaches and problems. Very easy to accomplish and it's "upgradable" with new VB releases. Just My 2 Cents.

-John