Today, I am working on integrating an Elgg social network installation with a custom-built PHP/JS/jQuery/MySQL site for a continent-wide, and potentially worldwide, research project.
Step 1 is to get the main site to check the user's login status in the Elgg site. Being logged into Elgg will open access to multiple tools not available to the public.
Based on example code provided by Steve Clay, I have been able to access the Elgg session data for a user and return a string to tell the user they are logged in.
<?php
/*require a PHP PDO database instance here */
$elggstatus=$_COOKIE["Elgg"]; //capture the session ID
if($elggstatus)
{
$user_id = 0;
$sql = ("SELECT `data` FROM `elgg_users_sessions` WHERE `session` = :sessVal");
$params=array("sessVal"=>$elggstatus);
$elggUser=$thePDO->thePDOselectfunction($sql,$params);
$userData=$elggUser[(dissect your PDO data structure here)];
$userData=explode('attributes";', $userData); //split the user object after the attributes segment
$userData=unserialize($userData[1]); //use PHP's unserialize() function to convert the data back to a PHP value
$userDisplayName=$userData["name"]; //capture the user's "display name"
Update 12:00print "You are logged in as $displayName";//provide the feedback to the user.
}
?>
I sure enjoy these rare occasions when everything falls into place. Since my original posting I have been able to create a PHP class to communicate with Elgg and return user status and data. By using this method I'll be able to extend the communication between Elgg and the main site as needed in the future.
It took a little while to get past some bumps in establishing a new PHP PDO MySQL class separate from the primary instance used for the other database, but once that was fixed it works fine. The next step is to make sure this works regardless of which URL option the user chooses to access the site. (There is a subdomain that goes directly to it, or they can use a long URL including the primary domain + directory tree)
Update 14:25
No real surprise, what I thought was working earlier failed upon testing by a user. Evidently Elgg returned the user object in a different order for different users, so the code I had posted earlier did not work. I revisited Steve's example, found where I had taken a wrong turn, and revised my code. Now it accurately converts the stored value into a standard PHP array for easy and consistent parsing. The code above has been edited to show my corrections.
Next goal: make Elgg write its session cookies so that it can be read from other subdomains.
Update 15:35
Since the last update, I have been working on trying to make the session cookie visible regardless of subdomain. No success.
I tried creating a new php.ini file in the Elgg root directory with this line:
session.cookie_domain=.mydomain.org
and logged in. My browser's cookie library showed that Elgg did properly set the cookie to be owned by .mydomain.com instead of mydomain.com as previously.
However, login now fails totally. When I try to log in, Elgg shows a red bar in the upper right corner saying 'you have to be logged in to see this file.' I had to disable my php.ini file to get my site back.
Back to researching...
Update 17:30
The joys of software architecture... nothing to show for the past 3 hours of work. I detailed my work to get a solution for cookie visibility across subdomains in a post on the Elgg community. With an immovable deadline looming and having lost 3 hours to fruitless research on the problem, I am considering changing the entire installation configuration to minimize the chance of problems. I had hoped to build Elgg into a multisite-capable system, since we have at least 5 different projects that could utilize its social networking functionality. Given that development of the multisite plugin appears to be inactive, I'll probably have to reconfigure my system to reside completely within a single subdomain to avoid these cookie issues. Maybe in the future a multi-site version of Elgg will be viable and I will reconfigure at that point in time.
