Progress in Integrating Indexu3.1 & vBulletin 3.0...
Hello, I've been spending part-time for a couple of months now installing, cleaning up, customizing and integrating my copy of Indexu31 with vBulletin v3 (now RC3). I'm actually very close to having it all working but have encountered a problem I thought someone here might be able to assist with.
So far, I've managed to accomplish the following things:
First, I made a few minor changes to msg.php to convince it to call Jelsoft's new vbulletin/login.php utility rather than the Indexu one. This worked fine and I'm now able to invoke the vB3.0 login from IndexU and log-in successfully from either indexu or vB3.0. In short, logins work reliably from either program.
Next, I modified vBulletin's new vbulletin/login.php utility (this new vB program replaced the login/logout functions in the old vbulletin/members.php) and added calls to Dody's program vbulletin/idx_functions.php to set the indexu cookies on login and to reset them on logout. Once I did that, I was able to login from either program's main screen and still be logged in in the other program when I transfered control to it. In most (but not all) cases, I could also logout reliably too.
So far, so good!
As I've said, logout works much the same. Most of the time I can successfully logout from either indexu or vBulletin and it will log me out in both applications. But there are cases where this does not work correctly from the indexu side and I suspect they may related to my other problem (see below). In some cases (I haven't figured out exactly which ones) the logout function gets called from indexu and the vBulletin logout is successful; but when control is returned to indexu, the program doesn't seem to realize a vbulletin logout has occurred. Often when this happens if I just end the browser session and start a new one, indexu suddenly "realizes" a logout has taken place and everything is fine again. In other cases Indexu stubbornly refuses to recognize that logout took place and the only way I can solve that is to delete my cookies and force things back to normal again. This seems to be an issue in the way I.E. handles cookies in some situations; but I haven't figured out yet exactly what combination of circumstances causes logout to fail.
The other problem I'm having is more fundamental...
Once I had the login and logout working correctly most of the time, I went on to try to implement the rest of the patches Dody developed to integrate indexu with vb 2.3.0 last year.
First, I installed his new version of indexu/login.php and was able to configure it (together with his new vb_config.php). Later, I verified step-by-step that when a user clicks the "My Account" link on the Indexu main menu, control is passed to indexu/cp/index.php which in turn invokes Dody's new indexu/login.php. After that, indexu/login.php successfully passes control to Dody's new vbulletin/idx_login.php module. This module is designed to verify that the user is still logged in. I was even able to create a test version of vbulletin/idx_login.php to confirm this program works well enough to successfully return control to either indexu/hot.php or indexu/new.php once it verifies the user is still active. I made those changes and conducted my tests because what I found is the attempt by vbulletin/idx_login.php to pass control back to indexu/cp/index.php after it verifies the user is logged-in fails every time.
The error I get when vbulletin/idx_login.php tries to pass control back to indexu/cp/index.php varies slightly (but ominously). The first time I try clicking on "My Account" in a fresh browser session, it gives me a 404-error that reads:
But after that, every time I try to do the same thing in the same browser session, I receive a different error:http://domainname.com/indexu31/cp/?PHPSESSID=f0b65cfb8d4afacac55bb10415664ac3
The page cannot be found
The page you are looking for might have been removed, had its name changed, or is temporarily unavailable.
etc...
Notice here that in subsequent invocations the PHP session-id vanishes! I suspect this is because something on the vB3 side of things kills the PHP session. However, it could just be the 404 error that does that.http://domainname.com/indexu31/cp/
The page cannot be found
The page you are looking for might have been removed, had its name changed, or is temporarily unavailable.
etc...
I've examined this problem carefully and I even compared the vb3.0 version of vbulletin/globals.php with the earlier vb2.3.4 version of the same program and concluded the most likely cause of this failure to return control to indexu/cp/index.php is the changes Jelsoft made to the vbulletin/globals.php program for vb3.0. However, I'm at a loss as to what to do about that and was hoping someone here might be able to help me.
The bottom line is I've managed to get 95% of the linkage between indexu and vbulletin 3.0 working but I've hit a wall with this problem and have nowhere else to turn. If anyone here is willing to look into this, I'd be grateful for your help! I've wasted many hours on this but am unable to make further progress. And I simply cannot convert my links database to indexu or roll indexu out to my users until I know it works successfully sharing vb3's member database.
You can see this problem and my hack in its current state right NOW on my site. [CONTENT WARNING: It's an ADULT site; but no offensive materials appear on the two pages you'll need to visit.] If you go to http://sissyland.com/indexu31 you can use the registration link there to register and it will use the vB3 registration program as it should. Because the integration between vB3 and Indexu is not yet fully working, I haven't yet linked the two programs from their home pages. So, to access my forums, go to: http://sissyland.com/forums and confirm that once you've logged in from indexu31's home page you are automatically logged-in under vBulletin and vice versa. The changes work the same way for log out. You should be able to login or logout from either program and the other program will automatically "know" you are logged in. But right now, if you click on the [MY ACCOUNT] link, you'll get indexu's HOT LINKS page instead of the 404 error page I described above. That is intentional. I deliberately modified idx_login.php to call the hotlinks page RATHER than calling indexu31/cp/index.php to prove that program control is actually GETTING that far! Otherwise, it looks like the [MY ACCOUNT] is failing as soon as you click on it.
It's worth pointing out that Dody used a recursive call to make this all work. In this case program A (indexu31/cp/index.php) calls program B (indexu31/login.php) which calls program C (vb3_forums/idx_login.php) to verify that the user is logged in. Then program C calls program A again (indexu31/cp/index.php). It's that LAST call that is failing. The fact that you receive indexu's hot links screen is positive proof of that.
If anyone here is willing to help with this, I'd be happy to pay for your time if the cost is reasonable. I'm so close I can almost taste success. But without the login verification working as it should, there seems to be nothing else I can do.
Thanks for listening! I look forward to hearing from you.
