Embedding wordpress blog s/w with existing site

[Maithili]

I have one site,which contain on module of blogs.

I have used wordpress blog s/w for it,and i need to embed this with site,but when user goes to blog section he loses the flow of site as he need to make another log-in,and first login of site is not maintained,i.e two session are started.

Is there any way to embed this s/w with same sesson of site?,i chked session in wordpress blog codding,but it is really impossible to understand their flow and syncronize with existing site..

Any one has solution? ..Please tell me

[eelixduppy]

It will be crucial to understanding how wordpress works in order to combine the two systems together. I myself have not pulled it apart but that's where you are going to have to go. Instead of changing the wordpress code, though, it might be worth it to have the original part of the site model how wordpress works and use the same user table in the database for authentication. Hopefully someone here has worked with wordpress at the code level, otherwise, you are going to have to do some studying yourself.

[miruka]

Creating a single signon between wordpress and anything else isn't all that hard. The best approach is, of course, to use one table for the usernames and passwords (it would be simplest to use the wordpress wp_users table if every user of the site is required to be a user of the blog)

You can start the wordpress session as follows:

First, be sure to include the wp-load.php file as it contains the includes to functions required to start the session i.e. "require ('<some path>/wp-load.php' );

Next, you'll need to call the wp_signon function. This function expects the following parameters ( $credentials, $secure_cookie) for example $wordpressuser=wp_signon ($wp_creds, false); where $wp_creds is the credentials array described below.

$credentials['user_login'] contains the username
$credentials['user_password'] contains the password
$credentials['remember'] contains the "remember me" flag for the wordpress login page, leaving it out of the array is the same as setting it to false.

Alternatively, you may use the POST variables "log", "pwd", and "rememberme" instead of passing the array, though I would personally consider passing the array to be a better approach

if $secure_cookie='', it will require an SSL login. Set secure_cookie=false unless you are using SSL for your login/authentication page, or the login will fail.

The function will return a WP_Error object which contains an array of error strings ($errors) if the user credentials are incomplete or incorrect. I would parse these error strings for displaying failed login feedback, or if the authentication was sucessful, wp_signon will return a WP_User which will contain the user ID. You could also check wp_get_current_user() to see if the wordpress authentication was successful and base your other authentication off of this. You can share the session generated here with your other webapp so long as you don't step on any of the wordpress session variables.

wp_signon calls wp_authenticate to do the meat of the authentication, so alternatively you can use this class (and potentially wp_set_auth_cookie) instead. It does not deal with the cookies that wp_signon uses. The best approach depends on how you want to handle session expiration, etc.

All of the classes for authentication live in the classes.php file. If you search the file for "function wp_signon", "function WP_Error" you'll likely be able to understand how WordPress authentication works quite easily.

I hope this helps, and good luck with your project.

[Maithili]

Yes I have tried for this..but i already integrated vBulletin forum s/w also with it and it has a "user" table also....and user is logging through this table.

So i can't syncronize such all stuff.

[miruka]

There is a "cheating" approach to synchronizing the passwords:

WordPress will happily authenticate the user from a simple MD5 hashed password. You can also use a similar approach to insert new users into the wp_users table (be sure to insert the appropriate data into wp_usermeta for the new user_id you create)

When your user has successfully authenticated off of your vBulletin database, update the WordPress users table with an MD5 hash of the password they entered. Building the query would look something like:

$query_pwdsync="UPDATE `wp_users` SET `user_pass` = MD5( '" .$users_password."' ) WHERE upper (`user_nicename`) LIKE '%".strtoupper( $users_username )."%'";

where $users_password and $users_username are replaced with variables containing the real username and password. The SQL above is case insensitive for username matching. If you want it to be case sensitive, take out the upper() and the PHP strtoupper() You should also consider taking the same approach when the user changes their password. If using MySQL 5, a trigger on the vBulletin database would be a better approach, however it would be quite an undertaking since vBulletin will be inserting into/updating the table with a pre-hashed password.

It is of note that since version 2.5 of WordPress, the wp_check_password function, which gets called during the wordpress authentication, will check to see if the user's password is stored as a simple MD5 hash and then rehash it using PHPass (DES, Blowfish or MD5+Salt if nothing better is available - Salt is generated differently than in vBulletin) after the first authentication, though this should be of no concern unless you want to use the password stored in the WordPress users table to perform some other authentication.

If that doesn't do the job for you, it seems like the next approach to look into is to modify the wp_authenticate function (inside wp-includes/pluggable.php) to either not authenticate at all or to authenticate off of the vBulletin users table.

If you modify the function to simply skip the password authentication, about all you'll need left in it is:

$user = get_userdatabylogin($username);

if ( $user->user_login = $username) ) {
return new WP_User($user->ID);
}

You might want to return a wp_Error if it fails, but it's not absolutely necessary.

If you strip the password check, you'll want to remove the standard wordpress login page altogether as it would authenticate any existing user even if they don't enter a password. If you want to continue to use the wordpress login, simply add your password validation against the vBulletin database into the function in place of where the wp_check_password function is called in the unmodified function. Just make sure you don't return a WP_User unless the authentication is sucessful.

Alternatively, you could replace the wp_check_password function with a function that validates off of the vBulletin database.

Hopefully, one of these approaches does the trick for you.

[spkr099]

miruka! I could reallly user your help as you seem to know exactly what I want!

A little about my setup
I have two directories
/ **aka root
/blog

in my root folder I allow the user to register and login to my blog (using my own code). So if the user registers, it uses the wordpress database etc. If they login though my root page, navigate to the blog, it will say Howdy, LoginName. So. The registration/login works, however I cannot access the global variables defined by wordpress in my root directory. $current_user->ID will simply return 0.

I don't understand why the session is not been "shared" after loading the bootstrap.

Here is a sample of my header file in my root folder.
<?
/** Make sure that the WordPress bootstrap has ran before continuing. */
require('blog/wp-load.php');

global $current_user;
?>

and later I have
print "UserID ".$current_user->ID;

which returns 0 even though the user is logged in. Any help is greatly appreciated, thank you!

[miruka]

This is most likely because the cookie path is set to the path of the blog by default.

If you do an " echo COOKIEPATH " somewhere after you require "wp-load.php", or "wp-config.php" it probably contains the path to your wordpress install (likely "/blog"), which causes the cookies to be created with that path (in wp-login.php), and restricts the scope of the cookie to the /blog subdirectory and below. Normally, this is a good security precaution, but in your case, the cookie needs to be created with a path of "/" to make it accessible across the entire domain.

Assuming you are using an even remotely modern version of WordPress (1.2 or later) you can override the cookie path by defining COOKIEPATH in wp-config.php. Just add the following line to the wp-config.php file. (before it does a require_once of "wp-settings.php")

define('COOKIEPATH','/');

Personally, I throw all of my custom config up at the top before the DB defines, but anywhere will work!

Log your user out of WordPress, then back in again to set a new cookie, and you should be able to snatch your user data.

I'm almost certain this will solve your issue.

But, if you still can't get to the real $current_user object (WordPress was generating a new, unauthenticated one when it couldn't read the cookie), make sure the session isn't being stomped on, and take a look at what's in the session's cookies. A quick and dirty method for dumping the content of the cookies is to just run through the _COOKIE array and dump its contents, like:

foreach($GLOBALS[_COOKIE] as $key => $value){
echo $key.' - '.$value.'<br>';
}

You should always see "WP Cookie check" set in the cookie named by the value of TEST_COOKIE, which by default is "wordpress_test_cookie" even if no user is logged in. This cookie is created as a test of the browser's ability to set cookies. If there is a user logged in, there will be a cookie named by the value of LOGGED_IN_COOKIE (defaults to wordpress_logged_in) with a hash appended.

Hopefully, changing the cookie path solves your issue. Good luck with your integration.

[spkr099]

Thank you so much for your help miruka! The cookie path solved the issue.

One a second note, in case anyone is trying this aswell, the first login did not populate the $current_user variable.

So, in my header I wrote:

global $current_user;
if ( !$current_user->ID )
$current_user = wp_get_current_user();

So, if the current_user was not yet define, define it with the wordpress function and voila, I have access to what I need!