Drupal 6 multi-site single sign-on

I've just spent the last two days looking into setting up single sign-on across multiple sites under a shared domain. I looked at both the Multisite Login and Single sign on modules but in the end the solution was achieved without either of these modules. Multisite Login correctly notes in the README : "if you are using several sites on the same domain then you do not need this module. The multisite functionality in Drupal core has the ability to share logins for sites like these without additional modules." The problem was there doesn't seem to be much documentation about achieving this. In the end the solution was on Eric's Drupal Blog but it was sort of lost in the detail so I want to note the key elements here.

For this example we have three sites http://www.example.com/master, http://www.example.com/slave1, http://www.example.com/slave2. I want to be able to sign on to one site and to be signed in to all.

Start by setting up the master site as you normally would (if you haven't set up a multisite before this earlier post may help). The only additional thing to do is to set the cookie_domain variable in the sites settings.php:

$cookie_domain = 'master';

Now go ahead and setup slave1. Once again add the cookie_domian (using the same value as the master site) but this time also define the db_prefix array. You use this to tell this site to use the database from the master site for some of the tables. Lets say that the master site uses a database called masterdb. To tell slave1 to use this database for the users table add 'users' => 'masterdb.' to the db_prefix array. The exact list of tables you'll need to add will depend on how much functionality needs to be shared across your sites. Eric's post adds users, sessions and authmap. I've also added filters, filter_formats and role :

$db_prefix = array(
'default' => '',
'access' => 'masterdb.',
'authmap' => 'masterdb.',
'filters' => 'masterdb.',
'filter_formats' => 'masterdb.',
'role' => 'masterdb.',
'sessions' => 'masterdb.',
'users' => 'masterdb.'
);

Now you are ready to install slave1. When that's done you should be able to log out of and into either site and stay logged in across both. Repeat the steps used for slave1 on the slave2 site. That's all there is to it. In essence all that's required is to share some core tables and the cookie domain across all sites. The only problem I struck was if the cookie_domain isn't an actual domain.

GeekGlue Site Update

Over the last couple of years my GeekGlue website has become increasingly out of step with my current interests. I've been thinking more and more about how I should use that space. In the last year I've become very interested in casual gaming and have (as noted on this blog) published a couple of games. Therefore I started to think that I would like to use the GeekGlue site to support my game publishing and perhaps focus my own research into casual gaming. I was also keen to use Drupal (which we've been using extensively) to make the site more flexible. Hence the new GeekGlue is born with new games added daily, a blog posting a daily review of the best new game of the day, walkthroughs of my games (and probably a few others) as well as casual gaming news. The site is very much in a formative state and I expect to regularly add new features in the coming months.

Web Developer IDE's

Like a very large percentage of the worlds web developers I've been using Dreamweaver as my main Developer IDE for many years. Recently I've started to do some of my web development in Eclipse due to some handy Javascript and PHP plugins. But I still go back to Dreamweaver for CSS and FTP ( there is a plugin for enabling FTP in Eclipse but it needs more time and patience than I have to install all the dependancies). Really I'd prefer to have one application open rather than two so I'm always on the look out for alternative. Consequently, my radar went up when I saw a post comparing Komoda Vs Coda. I'd never heard of either so I started hunting around :

• Coda
• Komoda
• Komodo IDE and Drupal/PHP development
• Komodo IDE take two
• Debugging Drupal with Activestate Komodo 3.5

Drupal Services & Flex

A current project at work is integrating Drupal & Flex together. There are a number of benefits to using these systems together. For me the main one is that you can offer the usability richness that Flex allows and the accessibility that standards based CMS's like Drupal offer without a lot of extra work.

The Drupal modules that make this possible are Services and AMFPHP. With these two modules enabled you get login and node access/saving functionality as a RemoteObject service in Flex. The other nice thing is that any Views (essentially UI developed queries for Drupal newbies) you define are also available as a Service. You can also develop additional Services utilising all the functionality Drupal has to offer. Finally, all these Services can be tested in the Drupal interface.

From that you can probably guess that I'm pretty enthusiastic about Drupal/Flex integration. But I have a caveat. We actually had a problem getting the Node and View Services to work. We kept getting a RangeError fault when trying to access these services. We finally found a workaround but we haven't had time to find the source of the problem. The workaround involves defining the fields you want returned as an array and passing it to these Services. Within the Drupal interface the fields parameter is optional and you get all the results you'd expect with or without it. But as soon as you add Flex to the equation you get an error. I assume it has something to do with the AMFPHP module as the Drupal Services page doesn't require AMFPHP but Flex does. I've posted this in the AMFPHP module issues and if you find a better solution that's probably a good place to post your discoveries.

I first heard about Services from a Friends of Ed book "Advanced Flex Application Development". My response to the book was mixed but it definitively got me thinking about Drupal Flex integration. Below are some links that proved useful getting this up and running:

• Flash Drupal Services and AMPPHP | my blog
• Example: Flex Recipe App MXML | drupal.org
• Reading And Writing Drupal With Flex
• Adobe - Developer Center : Retrieving Drupal nodes with Flex 2
• Services Tutorials and Examples | drupal.org

Dreamweaver Drupal API extension

For the last few months we've been using the Eclipse PDT plugin for PHP development.  During this time most the PHP work we've been doing is around the Drupal CMS.  Due to the number and range of Modules a typical Drupal site uses PDT has proved a real time saver.  I know PDT isn't for everyone...  Well if you are a Drupal developer and you use Dreamweaver you may be interested in the Drupal API extension that is being developed by xtnd.us.  The extension provides Drupal API code hints (and snippets?).  It is currently in beta but they plan to have a full release later in the year.  They also have a jQuery API extension that looks very useful.

AdvancedED Flex Application Development : Book Review

AdvancedED Flex Application Development offers a well written extended case study on the details of developing the Rich Media Exchange (RMX). The RMX was built using Adobe Flex and numerous OpenSource tools (i.e. Drupal, OpenAds).

Now straight off any book that talks about Drupal and Flex is going to get my attention. At work we are currently looking into the best way to use Flex and Drupal together for a range of projects. From my perspective having Drupal provide accessible access to content for all users while using Flex to provide rich usability for most users is a great solution. It also means less time spent with CRUD and more time spent on the user experience. Consequently I approached this book with great interest.

The first few chapters did nothing to quell my interest. They provided an engaging perspective on web 2.0, the Flash platform, their planning process and the OpenSource technologies used.

Unfortunately my interest abruptly stalled in chapter 5 (Flex styling) and only intermittently recovered throughout the rest of the book. The problem for me is that this book tries to do too much. If you’re ready to start developing applications on the scale of the RMX there is a good chance you’ve already spent quite a few hours on the Flex learning curve. You don’t need chapter after chapter of detailed code examples and their explanations.

Essentially I think the RMX is almost two good books. The first book is for developers who are relatively new to Flex and are interested in a cookbook style book of common problems and techniques for solving them. The RMX case study would make these examples more real and therefore engaging for that audience. Add a few chapters to introduce Flex basics and you would have an excellent intermediate level book. The second book is for developers who are familiar with Flex and would be interested in the processes and thinking behind building a larger Flex application and integrating it with OpenSource tools.

This is a well written book and if the individual chapters were available online as articles you would read and cherish some of those articles. Unfortunately, I feel the concept gets in the way of, and ultimately lets down, the writing. There will be developers who are at the right point in the curve to appreciate the whole book. Less experienced developers might eventually grow into the whole book. Experienced developers should borrow the book from a friend and cherry pick the bits they need.

Blogged with the Flock Browser

Book Review : Pro Drupal Development

Last year at work we spent some time reviewing available Content Management Systems. Our aim was to streamline some of our more basic web development work to allow more time for the interesting bits. After quite a bit of testing we settled on Drupal. We all recognised that Drupal was a complex system and that we had a lot to learn. We also recognised that it had the flexibility to deliver the more challenging aspects of our project specs while keeping editing simple for our clients. We accepted that a steep learning curve came with the package. That learning curve has two distinct areas :

• Interface driven configuration
• Scripting based configuration

Using the UI in Drupal to configure your site involves remembering where all the bits are and which ones are relevant to what you are trying to do. This is most obvious when installing a new module. As the Module needs to be enabled (and if there are any dependancies they need to be enabled, configured ... first). You then need to set permissions and then to configure the Module. That's before you start working out how to implement the thing you wanted in the first place. You find yourself coming back to the site a few months on and wondering how the hell did we do that? We have made a lot of progress but we still have a long way to go in becoming comfortable with the Drupal admin UI. Scripting based configuration offers an even steeper slope to climb and in the end we turned to the books; or at least one book : Pro Drupal Development (John K. VanDyk & Matt Westgate, Apress, 2007). It is hard to imagine doing any serious Drupal development without having read this book. It's not that the information isn't available from other sources. The Drupal site is chock full of information if you have the patience to find it and make sense of it. That's the problem with community driven resources they can grow a little wild. Pro Drupal Development offers the information you need for Drupal development in a logical sequence with clear and simple examples. It is written from a place of deep Drupal knowledge and it seemed to me that every page dripped with powerful gems that would transform your Drupal development experience. Perhaps that sounds a bit over the top. But I did pick up a lot of tidbits that I'm using daily. From my perspective the book can be roughly broken into three sections. The first section, Chapters 1 - 10, is what you have to know. It looks at Modules, Blocks, Themes, Nodes and the Form API. You can't build anything in Drupal without a good understanding of these concepts. The second section, Chapters 11 - 23, are things you should know. It looks at filtering, searching, caching, localization, security. You shouldn't build anything in Drupal without an understanding of these concepts. The final section is the Appendices and specifically Appendix A which has the Database Table Reference. Having this handy reference at hand is going to save you a lot of time if you need to write an queries (and considering the patchy selection of Methods most Modules offer you will probably need to write a few queries). I don't buy many programming books and consequently I'm very selective about what books I do buy. I think you need to buy this book because Drupal's support material is a rambling thicket. I guess you may feel a touch put out buying a book for that reason (I did). This book is good compensation for the inconvenience of Drupal's documentation and in the end this book makes it clear that Drupal itself is worth the effort.

Drupal multisite setup

High on my list of priorities as we move towards our first real Drupal site was understanding how to setup multiple Drupal sites using the same core files. A lot of users have written on this subject and in the last couple of days I've read most of them. The alarming thing is that no two seem to be the same. The sad news is that I want to add to that growing list of multisite setups instructions.

The reason most of the posts proved unhelpful is that they assume you are creating different sites under different domains. For example, www.examplesite1.com and www.examplesite2.com will point to the same ip. But that wasn't what we were after. All our sites are under one domain. So we will create www.ourdomain.com/examplesite1/ and www.ourdomain.com/examplesite2/. The following instructions assume that you have already created a new alias in your Apache configuration file that points to your Drupal install.

In your Drupal 5 folder you will find a sites folder containing two folders ; "all" and "default". The "all" folder is for shared modules and themes that aren't part of the core but will be used with all your sites. The "default" folder contains a settings.php. If no other sites are found, based on your url, then the default folder is used. To create new sites using the same core you create new folders with their own settings.php file within the sites folder. The first important thing you need to know is that the folder name of your new sites need to reflect the address of the site with "." replacing "/" in the folder name. For example, if your site's url is http://localhost/test1/ then Drupal will look for a folder named localhost.test1. There are a few possible variations on this and they are described in settings.php. But what proved crucial for us was that you need to uncomment and change the $base_url variable to hold your full url without the trailing slash. Ours looked like this :

$base_url = 'http://localhost/test1';

This variable is optional in settings.php and for the senario of multiple domains for a single ip then it's probably doesn't need changing. But if you've done everything else and keep seeing the default site then you probably need to change this setting. We definitely did. Now to create a new site at this url you need to create a new empty database and assign priviledges. Add this information to settings.php as shown in the examples provided (in settings.php). Then navigate to install.php at the new sites url (e.g http://localhost/test1/install.php) and follow the usual install procedure. The result should be a shiny new Drupal website.

Drupal : Themed Taxonomy

As discussed in my last post we've been looking at CMS's at work. In particular we did some tests with Drupal and TextPattern. We seem to have settled on Drupal. Mostly because of an existing (and stable) LDAP module. For our tests we looked at an existing project that was built as a static site with editors using Contribute. In the next iteration of this site we need to look at adding search functionality as well as making the structure more flexible without loosing the strengths of the current site. Those strengths offer some very real challenges to any CMS. Specifically the site uses over 20 distinct templates because each themed area has it's own look. In researching Drupal I eventually came across the Taxonomy Theme module which may offer the best way to handle this. I've installed it twice now ; once on our development server and once on my laptop. Both times I initially assumed that enabling the Taxonomy module would make it magically appear (it doesn't). Both times I thought that installing and enabling the module would make it appear (it doesn't). In fact like most Drupal modules you need to find the modules settings page (Administer > By Module > Taxonomy Theme > Taxonomy Theme) after enabling it. Enabling the module in the Global settings allows you to then select a different theme for each Taxonomy term (available from the Taxonomy tab in the Taxonomy Theme area). Obviously you'll need to define a taxonomy and create a list of terms first.

The thing that surprises me is that enabling any module in Drupal requires a very similar process and yet despite this we still intend to move forward with Drupal. We move forward in the full knowledge that we as developers have much to learn so that our users will have little to learn.