Combining Drupal Commons with an existing Drupal website

If you’ve been trying to set up a social networking site using Drupal, then you may have been overwhelmed by the work involved, depending upon your level of expertise. Drupal for me, will always be the CMS (content management system) of choice, and I use it exclusively for every website that I design and develop. The modular nature of Drupal suits my way of working, and gives the web developer the greatest level of creativity and flexible when designing and implementing a website project. You can find numerous articles on the Drupal website or elsewhere giving insight and guidance into putting together a social networking site powered by Drupal, which in summary involves selecting from a large number of available modules and putting the site together. But this can be extremely time consuming, and even difficult to implement depending upon the exact nature of what you are trying to achieve. The learning curve can be too steep on this, especially if documentation for using any particular module is not particularly helpful. This has been my own experience, and though I have had some success in implementing my own social network through Drupal, I am not convinced that I took the right approach from the beginning.

In the last week, I have had to revisit a site which I set up a couple of years ago, which has a couple of hundred users from around the world, and numerous content, and content types, customised pages, views row theming, you get the idea – this is a project highly customised and difficult to migrate. My objective for the website was to improve its social interaction and online community aspect to foster relationships and involvement between users globally. Initially I had explored using the growing in popularity platform of Ning, which is well worth a look, but the problem with integration between Ning and Drupal is that there is no migration of users from Ning to Drupal, and so it would involve a lot of work, and contacting each user to re-register, which was not really an option. And so after some further research and deliberation, I decided to use Drupal Commons from Acquia, which is basically an out of the box social network platform using Drupal together with a whole host of modules. Drupal Commons is a distribution (a packaged version of Drupal that upon installation provides a website or application built for a specific purpose.)

Because of the highly configured and customised existing website, the prospect of having to re-do the work again with Drupal Commons to replace the legacy site was not particularly appealing, and to be honest one of high risk, in that I could have spent many hours developing, only to come across a problem further down the development line that could be unsolvable, and therefore I’d have to change my plan anyway. In short, it seemed the best way forward was to leave the existing site as it was, and to create a subdomain, and install Drupal Commons here.

This is what I did. And so now it is a matter of integrating the two Drupal installations together. For any project this will be different, depending upon the particular objectives for the website. In my case what was important was sharing the same users for both Drupal sites, together with profiles, user pictures, and also I use the GMap and Location modules for geolocation details, so these would all need to be shared.

Challenge

Implement social networking functionality into existing Drupal website

Share users, user pictures, login, profiles and geolocation details

Solution

Leave existing Drupal website the same

Install Drupal Commons into a subdomain off the main domain

Use the same MySQL database for both sites

Share the relevant tables in MySQL for users and associated data by modifying the settings.php file in both the master and slave

Install the Global Avatar module in both master and slave sites (for synchronisation of user pictures)

When installing Drupal Commons into the subdomain, I specified a table prefix (advance options) when entering the Database Setup screen, and I also installed initially into a separate database other than the one used by the master site. In theory I could have installed straight into the same database, but I was a little uneasy to do this straight away, and wanted a separate database to check a few things, and then once I was happy, I would export from the slave and import into the master.

At this stage I had Drupal Commons installed but both instances were using two different sets of users, pictures, profiles, and geolocation details. So the next step was to configure things to share the same users etc. This took some time to work out and experiment with, but when I got it right – you can imagine my joy and confidence that this was going to work.

I exported all the tables from the slave database and imported into the master database. That’s why it was important to add a table prefix during the installation procedure, otherwise I would have overwritten the existing tables, which would have been reversible, because I always take a backup of any MySQL database when I’m making changes – just in case.

Next I needed to the settings.php files for the slave instance. As follows:

$db_url = 'mysqli://username:password@localhost/masterdatabasename';

$db_prefix = 'connect';

$db_prefix = array(

"default" => "connect", // the prefix for tables that are not shared.

"users" => "",

"sessions" => "",

"authmap" => "",

"sequences" => "",

"profile_fields" => "",

"profile_values" => "",

"location" => "",

"location_instance" => "",

"location_phone" => "",

"location_search_work" => "",

"global_avatar" => "",

);

This code informs Drupal which table to reference when being called, as you will see, the default I called “connect” but for the other tables I wanted to use the master records and so specified the prefix, which in this case was blank. You’ll notice the global_avatar mapping also, this is part of the module installation process, as well as having the module installed on both master and slave sites.

I then checked both master and slave websites, and was delighted to see that the Drupal Commons instance was now using the users from the original website. Everything was complete apart from one last detail. The user pictures (avatars) at this stage were not showing. I believe the Global Avatar module works to synchronise this for accounts created or modified after and not before, and so I needed to copy all the pictures from one directory into another. For this I used SSH, as I have my own dedicated server, and copied all the files from the <mastersite>/all/default/files/pictures directory into the <slavesite>/all/default/files/pictures directory

Another check to the Drupal Commons website, and bingo, all the user profile pictures were now displayed also. This was stage one finished. The second stage will be the theming and design elements to blend the two websites together.