Drupal

Woke up this morning to find a message in my inbox from the PostgreSQL pgsql-announce listserv with the subject "PostgreSQL 8.0, 8.1 on Windows End-of-Life."  Pretty self-explanatory.

According to the announcement, no more updates for those versions on the Windows platform will be released once version 8.3 hits the shelves later this year.  They recommend that anybody using one of those versions start thinking about upgrading as soon as possible.

Normally, we don't like to just parrot news readily available from other sources, but I didn't see this particular blurb on the PostgreSQL website (http://www.postgres.org) as of this morning.  And considering that I doubt most of you subscribe to that same listserv, well, I thought I'd raise up and get my Walter Cronkite on.

Of course, I doubt many Drupalers (Drupalites?  Drupalians?) will be affected by this.  After all, seems that the people who run it on Windows are in the minority anyway...  And how many of those do you think are using PostgreSQL on Windows, too?  I'm guessing this affects about 3 people... Total.

Anyway, here's the message.  Enjoy:

Following the release of PostgreSQL 8.3 later this year, PostgreSQL
8.1.x and 8.0.x will cease to be officially supported on Windows. This
means that no further binary releases will be produced, and no Windows
specific bug fixes will be applied. Users of PostgreSQL 8.0 and 8.1 on
Windows should begin planning an upgrade to version 8.2 or 8.3 soon.

The PostgreSQL Global Development Group regrets the necessity of
dropping support for these releases. PostgreSQL 8.0 was the first
release to natively support Windows, and since then a number of
potentially serious issues have been fixed in later releases that are
simply not technically practical to back port. PostgreSQL 8.2 and above
are considered mature and will enjoy the same lifetime on Windows as on
all other platforms.

--
Dave Page
PostgreSQL Core Team

Yesterday, that1guy asked if we had played around with Facebook authentication in Drupal in a thread over on Drupal.org. We hadn't yet at the time, but not being the kinds of nerds to back down from a challenge, we started to look into it.

Thankfully, we didn't have to do much. Halkeye's already submitted a dev version of a Facebook authentication module for Drupal called, strangely enough, facebook_auth.

If you've used Drupal for more than a few days, you've probably noticed that installing new modules is generally pretty simple. You download the module, decompress it in your modules directory, activate it in your site's admin page, and fiddle with any settings as appropriate. If you have any questions, there's typically a good README file in the package that breaks them down for you. Piece of cake.

Unfortunately, facebook_auth installation wasn't quite that easy. Had to jump through a few extra hoops to get it to play nice. Chalk it up to the fact that it's still in the early dev phases of the dance competition, but the README file included in the package left a bit to be desired... Still, though, after playing around with it for a little while, we got it working on our development site.

Installation

First thing's first... Uses Drupal 5.2 with PHP 5.1.6 and MySQL 5.0.27. Halkeye says he's "fairly certain head will work for both 5 and 4.7," but we only tested with 5.2. Seems to work.

Ok, so first thing you need is the facebook_auth module, available over at http://drupal.org/project/facebook_auth. Download that and decompress it in your /modules directory just like you normally would. That should create a directory within /modules called /facebook_auth.

Before you get all click happy and start trying to activate it in Drupal, though, you also need to download the Facebook platform. Like the README says, you can currently find that at http://developers.facebook.com/clientlibs/facebook-platform.tar.gz.

And here's one of those places where the current README falls a little short. It tells you to extract the files from that tarball, but it doesn't say where. Not helpful. You'll want to extract the contents of that file into the facebook_auth directory. After you've done so, your directory structure should look something like this:

/modules/facebook_auth/LICENSE.txt
/modules/facebook_auth/README
/modules/facebook_auth/facebook_auth.info
/modules/facebook_auth/facebook_auth.module
/modules/facebook_auth/img/
/modules/facebook_auth/facebook-platform/

and within the facebook-platform directory:

/modules/facebook_auth/facebook-platform/README
/modules/facebook_auth/facebook-platform/client/
/modules/facebook_auth/facebook-platform/footprints/
/modules/facebook_auth/facebook-platform/php4client/

Obviously, there are files in the client, footprints, and php4client directories, too.

Ok, for this all to work, you also need to get yourself a Facebook API Key. Assuming you don't have any apps registered...

1. Browse to http://www.facebook.com/developers/apps.php and logon with your Facebook account info.
2. Click "Apply for a key."
3. Give a descriptive application name. Your users will see this when they try to use Facebook authentication, so you probably won't want to call it "Shiny Baboon Ass" (unless, of course, that's your domain name...). I'd suggest your site's title, but that's just me.
4. Click Optional Fields to expand it.

1. Customize the Support Email address field, unless, of course, you want your visitors sending their complaints to the email address you use for Facebook.
2. Enter http://<yourdomainname>/facebook/ for the Callback Url. For instance, ours would be http://www.nerdliness.com/facebook/.
3. Make sure Application Type is Website.
4. Fiddle with any other settings you want, but be careful if you enter any IP Address of Servers Making Requests. Obviously, if you enter the wrong info, your app won't work.
5. Click Submit.

You should now see an API Key and a Secret. Keep those handy as you'll need them in the facebook_auth configuration. There's a config.php file in the /modules/facebook_auth/facebook-platform/footprints directory that asks for them, but you don't need to worry about that. All you need to do is configure the module properly inside Drupal.

Those are the hard parts. From here on out, everything else is like you'd expect for a new module:

1. Log on to your Drupal install as an account that can activate modules.
2. Activate the newly installed module in Adminster->Site Building->Modules.
3. Enter your API Key and Secret in Adminster->Site Configuration->Configure Facebook settings (and probably check the "Show button in login block" box, but that's up to you).

And that's it. If everything went according to Hoyle, your site should now allow users to logon using their Facebook creds.

How it Works

Ok, so now you have a Facebook button on your /user page. So what? Let's say a new user comes along and clicks that button. That user will be redirected to the Facebook site temporarily to enter their Facebook credentials. They'll also have the option to check a couple of boxes allowing your app to access their Facebook info (this is the screen where that Shiny Baboon Ass will appear...). Soon as they click that button, the facebook_auth module will create a new local Drupal account on your site associated with that Facebook account.

Couple of caveats. First, the facebook_auth module doesn't seem to pull much info from their Facebook account. After creating a test user in our sandbox, the new account didn't have an email address, etc. entered into our users table. That might be an issue for some, but seems like one that can be fixed in the module. I haven't investigated the Facebook API enough to know for sure yet, though. Still, though, if you have mandatory profile fields you expect everyone to fill out, you might be a little disappointed to find new users missing that data.

Second, this is a quick way to accidentally create multiple local Drupal accounts for the same user. For instance, I obviously have a local Drupal account on my box already. I also have a separate Facebook account. If I were to click the Facebook button and attempt to authenticate with my Facebook name/password, I'd end up creating a second Drupal account instead of logging in with my original.

You can get around that a bit by making sure your existing users know about the Facebook Identities tab the module adds to your user profiles. If you log in to Drupal as an existing user, you can associate your existing Drupal account with your existing Facebook account ahead of time, thus avoiding the duplicate user problem.

The Rest

If you click our Log In link in the upper-right, you might notice, well, nothing new. No Facebook button. Yep. Like I mentioned, that there module's still in development and we'll need to do some more testing before we dare push it to our live site.

There are a few things we'd like to see added to the module, too. For instance, it would be nice if the module could prevent those duplicate accounts somehow... maybe by simply throwing up a warning to people letting them know what they should do if they already have a local Drupal account. Of course, that once can be nipped by throwing a warning on the site itself.

All in all, though, it definitely looks promising. We'll be keeping an eye on it.

After working with Drupal for over a year now I have learned many different ways to go about creating a custom Drupal theme. I have tried taking existing Drupal themes such as Garland and Blue Marine and hacking them to pieces while inserting my DIVs and classes trying to get things to work and look right. That just creates a huge mess of code and often contains unneeded elements (code bloat = not a good thing).

I've found that the best method for me to create custom Drupal themes is to first code up the site using static HTML/CSS, as in create an index.html file and go to town. I always code my sites using Notepad2 and then view/test them in FireFox. I also use the WebDev Toolbar so I can see how everything looks on-the-fly as I code my CSS. This really helps as I can code a LOT faster and see my CSS changes immediately.

Once I get everything looking decent (doesn't have to be perfect yet) in FireFox I then open the index.html file in IE7 and begin making IE7 specific changes to my CSS so everything looks decent there as well. I then load the index.html file in IE6 and do the same. Once things look the same across FireFox and IE7/IE6 I load it in Safari to see how it looks there. For this site I kinda ignored some issues with IE6 as it's a pain to work with and I'll get around to fixing them eventually.

So once the site looks the same in FireFox, IE6/IE7 and Safari it's time to add Drupal code to our static HTML file. This is much easier than it used to seem to me so if you follow these code snippets you should be all set...

Doctype to

*I included my CSS files for screen and print viewing (screen.css and print.css)

" lang="<?php print $language ?>"> <?php print $styles ?>


Search Box

<?php print $search_box ?>

Logo

<?php if ($logo) { ?>" title="<?php print t('Home') ?>">" alt="<?php print t('Home') ?>" /><?php } ?>

Main Navigation

<?php if (isset($primary_links)) { ?><?php print theme('links', $primary_links) ?><?php } ?>

Header Content

<?php print $header ?>

Left Sidebar

<?php print $sidebar_left ?>

Right Sidebar

<?php print $sidebar_right ?>

Main Content

<?php print $title ?>

<?php print $help ?> <?php print $messages ?> <?php print $content; ?>

Footer

<?php print $footer_message ?>

Closing HTML (Don't forget this!)

<?php print $closure ?>

Once these snippets of code have been added in place of your existing HTML code in the index.html file, save the newly edited file as "page.tpl.php". This is your theme page and every page on your site will have the same layout as this one.

Different Home Page Layout

Say you want to have a custom home page that looks different than all of the other pages. To create a custom home page you need to copy the code from the "page.tpl.php" file and create a new file named "page-front.tpl.php" and paste that code in there.

Now you can edit the code for the "page-front.tpl.php" file to make it look however you'd like. Drupal will automatically detect and load the "page-front.tpl.php" file if it is present in your theme directory.

What that does is tell Drupal that if the user is on the home page to go ahead and load the file named "page-front.tpl.php" rather than the "page.tpl.php" file. Now you can go back to the "page-front.tpl.php" file and edit it as you see fit. This gives you the option to have a different layout for the home page and sub pages.

Now that you have a "page-front.tpl.php" and page.tpl.php" file it's time to copy over the images and CSS from your static HTML site to the newly created Drupal theme directory. So pretty much your directory structure should now look something like:

Drupal Theme Dir:
    page-front.tpl.php
    page.tpl.php
    images/
    css/

Now you need to copy the other files in which Drupal relies on to your theme directory. Be sure to copy these files over from the Blue Marine theme (that's just what theme I grab them from).

Blue Marine Theme:
    block.tpl.php
    comment.tpl.php
    node.tpl.php
    template.tpl.php
    screenshot.png

So now you should have a fully working Drupal theme. You can copy the files over to the server and place them in the "/themes/newtheme" and then log in to your Drupal site through your browser and select your newly created theme. As you can tell immediately there is quite a bit of editing needed to be done to get your theme to work perfectly in Drupal. This is where the Web Dev Toolbar comes in handy again.

So now it's time to edit/tweak your "*.tpl.php" files as well as your CSS. This is a quick and dirty way to get a custom theme up and running but hopefully you get the idea.

Anyone else have an ideas on what I can improve on here or what I didn't really cover much of? I have created somewhere around 10 custom themes in Drupal so I'm sure I overlooked something here. Leave a comment or question and I'll do my best to help you out.

Belorussian translation

Last time I blabbed about Drupal modules, I talked about how you better download and install Pathauto if you want to hang with the cool kids.  If you were paying attention, you noticed that I also promised/threatened to talk about a few other modules we don't think a proper Drupal site can go without.  Prepare yourself for...

CCK

The Drupal Content Construction Kit (CCK) module is an absolute must-have.  Like the name implies, the module allows you to create your own brand spankin' new content types in Drupal, allowing you to further customize you Drupalin' experience.

Probably doesn't make much sense if you aren't a Drupal person and already familiar with the Drupal vocab, but it's pretty simple.  In Drupal, "content" essentially refers to the various articles, etc. you see around a site.  For example, the post you're reading right now is "content."  A static page, like our Contact form is also "content." 

In the basic Drupal install with no new modules added, you'll have a few different default content types.  "Page" and "Story," for example.  Those are pretty well covered already in the Drupal handbooks, but the jist is that a Page is a single, static HTML page, while a Story is generally like an article (has a title and a body).

But what if you want more from your content?  Like you want to have additional fields that just aren't included in your normal Story?  Well, then you need CCK.

In our case, we wanted to have a content type that had a second heading, not just the normal Title field.  We also wanted to be able to include referenced websites in a handy list at the end of each post.  Yeah, we could have just added those into the body of an existing story each time, but that would have meant styling them properly every time (or at least including them in a new DIV with a specific class). 

But we're lazy, and we like to separate our content from our presentation as much as possible, so we installed CCK (and a couple additional field types), created a Nerdly Article content type, and voila!  Reading this article, you see the results.

CCK does have a couple of little gotchas, though.  For instance, you might need to modify your theme a little to get the output the way you want.  In our case, that meant modifying our node-article.tpl.php file to only show the heading for the References section of a particular article if that article included references.  Otherwise, when we used the plain ol' tag, that heading would appear regardless. Looks bad to see a heading when there's nothing under it, eh?

I briefly mentioned above that we installed some additional field types...  For instance, this main content area is a Text field, one of those included with the core CCK module.  The links in the references section, however, are created using the Link field type.  That one we had to download and install separately.  When we add content, we see fields that allow us to just enter the title for the link and the URL:

Now when you view this, you'll see those links at the bottom.  What's more, someone like me (who has the design skills of a paraplegic ape) doesn't have to worry about making them pretty.  Instead, Jeremy can raise up and get his CSS on, making the rest of us look good.

Other cool thing about CCK is that the newest version is totally compatible with another necessary Drupal module, Views.  With just those two modules, you can do some pretty extensive customization without know a lick of PHP. 

So what about you?  You use CCK?  Which additional fields do you like? 

One of the best things about Drupal is the number of 3rd party modules available. Just browse over to http://drupal.org/project/Modules and you'll find literally hundreds of modules you can install right now to expand the functionality of the popular CMS. True, the core Drupal install does give you everything you need to start posting content right out of the gate, but it's this outside support that really makes Drupal worth considering.

No matter how you're using Drupal, there are a few modules you'll want to download right away. Over the next few days, we'll talk about three such modules that are so useful and popular I'm constantly surprised they haven't simply been added to the core. Who knows? Maybe there are plans to add their functionality to a future release. One can always hope. In the meantime, considering downloading and activating these three modules a permanent part of your new Drupal installation process.

Pathauto

After installing Drupal, the first step we always do is to enable Clean URLs (http://drupal.org/node/15365). In a nutshell, the out-of-the-box Drupal install uses URLs that look something like "http://www.example.com/?q=node/15". Ugly, and the search engines don't like them. Enabling Clean URLs takes that and turns it into something friendlier: "http://www.example.com/node/15."

Now, if you're like me, you're looking at that and thinking "hokey religions and Clean URLs are no match for a good blaster at your side, kid."

Ok, maybe that's just me... Still, though, Clean URLs only get you half way there. The "/node/15" URL might look better and be more search engine friendly than the "?q=node/15" version, but there's still a lot of room for improvement, both from a search engine and user standpoint. Enter Pathauto (http://drupal.org/project/pathauto).

With Pathauto installed and configured, you can tell Drupal to automatically create URLs for new content that fit whatever pattern you decide. Yeah, you can always manually change the URLs while editing your posts by typing something in the URL path settings field, but why would you want to do something by hand when you can have it done automatically for you?

Take a look at the URL for this page. Should look something like http://www.nerdliness.com/article/2007/08/23/drupal-modules-you-need. Much easier on the eyes than http://www.nerdliness.com/node/30, isn't it? Google likes it a hell of a lot more, too, and what use is writing your wonderful content if nobody can find it?

Don't like the pattern we used (type/year/month/day/title)? No problem. Pathauto lets you easily change it to fit your taste and needs. Even better, you can specify a different pattern for every different content type you have, if you like. You can even specify which words in a title Pathauto will strip out of your URL (like common articles: a, the, of, etc.).

Before you do anything with Pathauto, though, take some time to figure out exactly how you'd like your URLs to appear. Do some research on SEO, etc. and implement the best strategy possible from the beginning. Pathauto does make it easy to change your patterns in the future (and automatically update existing URLs, if you like), but doing so can have a negative effect on the ability for potential visitors to find your content.

Happened to us recently. We initially started out using a pattern that looked like "/article/title," but after a couple of weeks decided that it would be better to use our current "/article/year/month/date/title" structure. Pathauto handled the change instantly. Google? Not so quick.

The first several times Google indexed our site, we were using the old patterns. And because it can take some time for Google to reindex a particular site, a lot of would-be visitors are hitting our custom 404 error page rather than the content they were looking for. Sure, they could use the search box or our archives to find what they were looking for, but how many do you think actually try that? Yeah.

So Pathauto is essentially, but use it wisely. Download it now, but put the time in up front to come up with a URL strategy that will last for the life of you site. Either that, or get ready to see your 404 page become the most popular thing on your site.