Hi,<br /><br />Some questions if I may...<br /><br />(Not certain if this is the right forum, btw. If it isn't my apologies)<br /><br />Our site consists of 2 distinct areas, a memberarea and a message board, both of these unfortunately use their own database. People need to pay for memberarea access and we would like to know on the message board which members have and which have not paid. This info will allow us to give more features to paying members.<br /><br />In order to realize this we need to combine the registration processes.<br /><br />JoshPet was already nice enough to point us in the right direction a bit in that we need a seperate group on the board to identify paying members. I assume I then need to have the registration process add a user to this group if he has paid.<br /><br />And this is where I begin to run into problems <img src="/forum/images/graemlins/smile.gif" alt="" /><br /><br />To be honest I am a bit stuck at how to best handle this. Preferably I think I would like to use the UBBT registration and add additional fields for our account options (free, 1-month trial, 1-year, etc.).<br />Alternatively we could use the info on our registration page to create a useraccount on the board.<br /><br />My partner has had a look at this a bit and has the following questions:<br />* How can we see if a user exists?<br />I assume this could be done by a query on Username and / or email address, right?<br /><br />* How can we create a new user in UBBT?<br />I think this is done in adduser.php, but could we do this with an SQL query as well? Or do we need to use this script?<br /><br />An added complication, I think, is that the databases run on different machines, so a solution using only SQL queries would be great since the account creation could then be done remotely from the billing server.<br /><br />Anyway, I hope this is clear and that someone could provide us with some pointers.<br /><br />Sanuk!<br />

Well if the two database tables where combined to one database there would be a way to mesh things together and do it. While they are on separate machines and separate databases it makes it extremely hard. Basically what needs to happen is you would need to set up the threads group function that you would want. You would need to add the tables from the one database into the threads database. From there it is a process of meshing the two registration scripts and placing the new variables for selection into the UBBT template for the user to select. <br /> <br /> Now of course combining these two scripts could be as easy as adding an if and else statement. You need to specify and let the user select yes or no to be paying member. If no they get normal registration screen. If yes then they get the combined template. <br /> <br /> So in summary <br /> <br /> if yes (runscript) <br /> <br /> grab newuser2.tmpl <br /> <br />else <br /> <br /> if no <br /> <br /> grab newuser1.tmpl <br /> <br /> One of the Guru's around here may be able to put another spin on this idea and understand what I am saying. I am a bit pressed for time but I will look further into the exact syntax of my idea when I return from work if no one else has thrown in any ideas.

[]Our site consists of 2 distinct areas, a memberarea and a message board, both of these unfortunately use their own database. People need to pay for memberarea access and we would like to know on the message board which members have and which have not paid. This info will allow us to give more features to paying members.<br /><br />In order to realize this we need to combine the registration processes. [/]<br /><br />You don't need to combine the registration process if you only want to know if the forum user has also access to your member area. That should be doable with some sql queries within the forum code that queries the user-db of the members-area.<br /><br />Combining the registration process is also possible, but is far more complicated. You'll have to synchronize the two databases in both ways.<br /><br />Scenario 1: A user wants to change is email address. Without synchronizing, he'll have to change it in the forum and in your member-area.<br /><br />Scenario 2: A user should be deleted, banned in the forum. Shouldn't this be done in the forum also?<br /><br />Scenario 3: The access to the member area expired, this info needs to be transfered to the forum db, so that the group can be changed...<br /><br />So'll have to decide if you only want to display some additional info on your board or if you want to acchieve an intregration/synchronisation of the board and members area.<br /><br /> <br /><br /><br /><br />

Hi,<br /><br />"You don't need to combine the registration process if you only want to know if the forum user has also access to your member area."<br />This would in principle be enough, but since we are getting quite a few people who are getting confused with two seperate logins combining it into one registration process would be preferable.<br /><br />Having said that, just knowing would already solve a lot of our problems.<br /><br />Sanuk!<br />

Hi,<br /><br />"While they are on separate machines and separate databases it makes it extremely hard."<br />As we have noticed <img src="/forum/images/graemlins/frown.gif" alt="" /><br />My partner has been looking into this for quite a while already. So far, no luck.<br /><br />Thanks for the breakdown, had not thought of using two different templates. I was thinking about having it on one template.<br /><br />Sanuk!<br />

[]This would in principle be enough, but since we are getting quite a few people who are getting confused with two seperate logins combining it into one registration process would be preferable.<br /> [/] <br /><br />As i said before, it won't be done with one registration process. Making a registration page that writes the data in the ubb.threads database and in your members area database isn't difficult. The difficult part is the interacting of the two databases. You need to update your members database also, when someone changes his email address within threads and vice versa.<br /><br />So you'll have to enhance several threads scripts aswell as your scripts of your member area. I don't recommend doing that. Maintaing the same data in two databases always produces inconstiences and errors.<br />Using the same usertable for threads and your members area would be the better way, in my opinion.<br />Depending the scripts that you use in your member area, it would be less work and a cleaner solution.

Astaran brings up another great idea here. You could in essence us the script base code and change it to use the Threads database tables then your golden. At any rate you are looking at quite a job either semi time consuming to a vast project. Either way you decide to go like stated you would either need to code the other program to use Threads tables or combine the two.

Hi,<br /><br />"You need to update your members database also, when someone changes his email address within threads and vice versa."<br />Yes, but this should not be that difficult since we do not store much info in the members database, and with the exception of the password none of this can be changed by a user.<br /><br />So, we could use all the UBBT scripts only, and make them update both databases. While this is obviously risky and not good practice, it would work and should be fairly transparent to the users.<br /><br />"Using the same usertable for threads and your members area would be the better way, in my opinion.<br />Depending the scripts that you use in your member area, it would be less work and a cleaner solution."<br />You do have a very good point here. I have no idea about these scripts, but will ask my partner for a copy.<br /><br />The suggestion one of my friends had was to do this:<br /> - let the memberarea registration page update the UBBT database (U_groups)<br /> - run a script daily that checks the memberarea database and updates the U_groups table in the UBBT database (removing expired accounts)<br /><br />I think this may be a decent temporary solution while we work on combining everything. The thing is that we believe we could make a substantial increase in revenue by combining these and offering more features to paying members. The board has ~5 times as many active users as the memberarea.<br />So, obviously we would like to do this quickly.<br /><br />Sanuk!<br />

Hi,<br /><br />"You could in essence us the script base code and change it to use the Threads database tables then your golden."<br />Yes, this does seem like a good option and I will have a closer look at it as well.<br /><br />Sanuk!<br />