On the Development Seed blog today there's a new post by Alex Barth about integrating OpenID support into your Drupal installation. You can check out an example of it in this github project.

After a survey of available single sign-on solutions [for a client], we decided to go with an OpenID based approach since we needed to support different domains, wanted to avoid sharing user tables and did not want to add complex system requirements for browser clients or the server. [...] The great advantage of this scenario is that we know which five sites need to play nicely together and all of them are Drupal sites under the client's control. This premise allows us to add an additional site as a designated OpenID provider that we call "Hub" and make all five sites point to the Hub as their default identity provider.

They use two modules to make everything work together - OpenID SSO and OpenID Provider SSO and a PubSubHubbub model for keeping the user information up to date.

On the Lullabot.com blog there's a recent post from Nate Haug showing how you can set up a single sign on with Drupal even if your user crosses multiple sub-domains on your site. The technique is particularly handy in that it doesn't require any extra modules to be installed to make it work.

With the multitude of single sign-on modules out there for Drupal, it's easy to miss the fact that Drupal has a built-in single sign on mechanism already. No modules, no configuration, just 20 easy lines of PHP in your site's settings.php file. This solution works for a lot of clients, but the set of requirements is pretty specific as to when you can use this approach.

To make it work all sites must be on the same domain (just sub-domains of it), be using MySQL as your backend database and, if you're using clustered hardware, they need to be on the same cluster to be able to make the cross-database queries. Since Drupal can prefix tables so the settings for each site are split out, you can create a "shared table" by making a few changes in your master and slave configuration.

On the PHP Zone today (part of the DZone network) there's a new article that asks "Can learning Drupal get you a job?". They look at some of the trends and popularity of CMS systems and wonder how they could help your job seeking potential.

The question is… should you bother to learn it? Learning new skills is always helpful to your career prospects and Drupal is gaining more recognition, but an experienced developer with expertise in a specific area like Java or .NET probably doesn't need Drupal skills to get a job. Large website developers and less experienced developers however, would see a lot more benefits from learning Drupal.

According to this other source and a graph of job posting matches from Indeed.com for both Drupal and Joomla show a huge climb in demand over the past two years.

If you're new to the world of Drupal and want to get started quickly, consider reading up on these ten tips from Chris Free for a "Drupal 101" on using the highly popular content management system.

You often hear people say that the learning curve for Drupal is steep. They aren't kidding - it is. I remember when I first started Drupaling, I had so many questions [...] diving in to Drupal can be a bit daunting. In an effort to help remedy this, I've thrown together some quick-tips to steer all you beginners in the right direction.

The tips cover simple reminders like "don't forget to ask for help" or "Google it" and more detailed things like a list of basic modules it's usually good to use and to attend Drupal-related events to get out there and get to know fellow Drupal-ers.

New from OurBlogLog.com there's a new post that compares Joomla and Drupal based on their features, ease of use and extensibility.

I've had more than a few conversations recently about which CMS is better. From the Joomla camp I hear, "Joomla is easier. Joomla has a great user interface." From its competitor I hear, "Drupal is more flexible and it has tagging." It's the Pepsi versus Coke debate for open source CMSes.

For the two CMSes there's a list of the good and bad things about each - good on Joomla's side was the easy deployment and versioning of content, good for Drupal was its flexibility and the high profile sites that use it. On the bad side, Joomla has a limitation for one-site-one-install and limited permissions handling. Overall, though, the author found that they both had their strengths and weaknesses and that, if you're shopping around for a CMS, find what fits best for you and your organization.

New on the Blue Parabola blog today, there's an article from Keith Casey trying to set the record straight on some recent benchmarks put together by Zend and Acquia showing the performance of Drupal.

While I have not attempted to duplicate or validate any of their individual numbers or conclusion as a whole, I have been a Drupal user for well over five years and have launched 30+ sites on it.

With this experience to back him up, he points out a few things about the report that either needed work or were misleading in their results. This includes a limitation on the web server configurations they covered, the statistics on Windows performance (might turn people off to using it on this platform) and the emphasis being put in some of the wrong places - optimizing PHP versus Drupal.

He recommends that, like all studies and whitepapers like this, you take the results as only guidelines and examples, not as absolute facts. There's always going to be differences in hardware, software and configuration so what gave the big numbers and results for them might not work for you.

Instead of comparing the software itself, the GnomeOnTheRun.com blog takes a look at the project homepages of three major PHP CMS/blogging tools - Joomla!, Drupal and WordPress - to see when they might tell us about the project itself. (Some of the homepages are actually built using the software too).

I found some interesting things that might shed some light onto the different projects. This is all based on January 11th, and 28th homepages, so by the time you read this a lot may have changed. Rather than go into great detail, I'll provide short lists of interesting things I noticed.

He looks at three different sides of the sites - how the markup is structured and if they conformed to an HTML standard, the overall performance of the sites and the actual content of the site (how useful it is, the organization, etc). You'll have to read the post to see what his conclusions were, though.

In this new post to Symbiotix.net they take a look at a migration they made taking their site and content over from a WordPress installation into a new Drupal site.

We've been running a small educational non-profit - Edulogos - for over three years now. Until recently edulogos.org has been little more than a Wordpress blog with a few extra pages and an off the shelf theme. [...] We decided it was high time to redesign the site and move it over to Drupal to give it room to grow. Like repotting a plant. "Liefde en substral", as they used to say in our home country.

They talk about the planning stages of the move - what version control they were going to use, which Drupal modules they were going to install - and walk you through the installation and configuration process step by step. They used git and github as their chosen method for deploying the site.

In response to a blog post about a Google ad from Microsoft (seen here) by a member of the Drupal community, Mark Brown of the Web Platform group at Microsoft has posted an apology for the "Forget Drupal..." tagline the ad sported.

First, I want to offer my sincerest apology for this. I have contacted Google and we are working on having this ad pulled as soon as possible. In addition we are working internally to ensure this doesn't happen again. Second, I want the Drupal Community to know that Microsoft and the Drupal Community have been working together for some time now to make Drupal better on Windows.

Mark also points out that there's a lot of marketing Microsoft is doing all around the world to help promote the Drupal project (especially with it being one of the initial PHP packages in their Web Platform Installer). The ad was found and has been removed from circulation.

On the Proof Group's blog there's a recent post about a "gotcha" Andy Chase found when using the Drush command line tool for Drupal installations and a system that has MAMP installed.

Recently, however, I installed MAMP to debug some older, PHP4-specific code. [...] I also use Drush, which is an indispensable Drupal command line tool, and I began getting the following error on some sites: Drush command could not be completed.

This only caused a problem when he went back to his previous PHP5-based installation. He finally found the culprit - a section of the Drush script that looked for MAMP installs and tried to use those binaries and configuration files (the PHP4 ones) instead of his more correct PHP5 ones. A quick commenting later everything worked fine.