URL shorteners are the bane of the internet. However, for those of us who use Twitter on a regular basis, you know that 140 characters can be limiting. URLs can theoretically be 2,000 characters or more, but most are in the 40 to 80 character range. That's almost half your tweet! So we use URL shorteners to not only shorten the URLs, but (in the case of some services like Bit.ly) to track clicks and get statistics about who clicked on these short URLs.

The problem, however, with the popular URL services is that the more that they are used, the longer their URLs get. Both Bit.ly and Tiny.cc are up to 6 characters in their autogenerated URL paths. Add in the URL protocol (http://), the hostname (bit.ly) and the initial slash, and you've got minimum 20 character URLs.

So why use someone else's short URL service, when you can create your own, branded, shorter short URL service with URLs like lb.cm/a or jen.cm/j? A branded URL shortener can also be a sign of prestige or add a layer of trust. For instance, Flickr's URL shortener, flic.kr only links to Flickr photos. When you click on a flic.kr URL, you know what you're going to get. Google has a similar service with goo.gl and WordPress has recently launched wp.me. Even if you open it up for the public to use, as we have with lb.cm, there's just a certain geek prestige in having your own URL shortener.

Why Drupal?

So why use Drupal as a URL shortener? There are several single-purpose stand-alone Open Source URL shorteners out there already. And Drupal is sometimes criticized as being big and slow. URL shorteners need to be small and fast. On the other hand, we're not really expecting bit.ly-level traffic here, are we? Maybe we can consider Drupal. read more »

Managing the code on your servers is a very important part of the release process. Over the years we've tried many different ways and have found the below process as a tried and true starting point, but here we'll focus on revision control (Subversion or Git) and the use of tags in each for any given project. Since many of our clients are large traffic websites and need multiple web heads, we also have some standard practices and scripts that we like to use on our projects to help keep the web heads synchronized. So let's take a look.

As with many facets of Drupal, and coding in general, there are multiple ways to accomplish the same task. A good exmple of this was with the recent additions to the Lullabot team. The expanded team brought together three skilled developers and an amazing designer each with their own methods of site building. On one side we have Jerad Bitner and myself, who for the past few years have been building sites exclusively with Panels module. On the other side we have James Sansbury and Jared Ponchot who also build beautiful sites using the more recent Context module.

Our first collaboration was the redesign of Lullabot.com, since this project was initially designed and scoped by James and Jared, the decision to use Context module was already in place. I was in no rush to learn Context, when I knew the same result could be achieved with Panels. Lucky for me James and Jared are both excellent resources for answering questions and giving great examples. Now that the project is complete I have a better understanding of Context module. This article is intended to identify the similarities, differences, pros and cons of using each module to build a Drupal website. read more »

Angie Byron wrote a nice article on Drupal.org that explains something about how to form_alter CCK fields. At the very end it says:

No, you didn't read that wrong. Sometimes you need to set both ['value']['#value'] and ['#value']['value']. And other times you need to change the field value in $form_state['values']. It seems to be that one controls the value displayed on the form, and the other affects the value sent to the database. You need both to avoid NULL values and "Value is required for field blah blah blah" errors.

If anyone can shed some light on what the heck is going on here, that would be awesome. ;P

One of the things Drupal core does not do well at all is provide an easy way to switch on a WYSIWYG editor. There is no editor out of the box and setting it up requires some custom configuration of several Drupal core settings, installing and configuring several contributed modules, and also installing one or more external libraries, like the TinyMCE library. The Lullabot book, Using Drupal (O'Reilly), devotes a whole section to describing one way to configure a WYSIWYG editor.

The Problems

It's complicated because there are lots of inter-related parts:

1. You need to set up one or more roles that can edit content.
2. You need to create and configure 'Input formats' to create at least one format that allows users to add the html and css needed to create rich text content.
3. You need to select and install a WYSIWYG editor: install the editor, download an appropriate javascript library and move it to the right location (which varies depending on which editor you are using), and then configure the editor to use the library.

And all of that gets you only to the point where you can edit text. If you want to allow users to upload images and insert them into their text, you also need to identify which of several possible methods of image handling you want to use, and install and configure the modules needed to manage that. read more »

Almost a year ago now Development Seed had an article on some of the tools they were developing in order to address a very real, very important problem—that of the whole development to staging to live development process. Up until these tools were available, this process consisted of an archaic—and quite frankly, pain in the butt—method of either duplicating the clicks and changes you made through the Drupal UI in your various environments, or putting all of your changes that needed to be made to the database into update hooks that did very specialized queries, set variables, installed or uninstalled modules etc, etc. This came with a heavy price tag of testing your migration path over and over, resetting your database, and testing again. Oops! Small mistake there... change the code, reset the database, run it again, wash, rinse and repeat. These tools attempt to change all that and now that they're maturing, they've become a godsend for site builders and developers everywhere. Here is the workflow and process we are using at Lullabot and some of the finer points we've picked up along the way. read more »

Most of us have heard of Drush by this time. It's a cool command line tool to make it easier to set up and update Drupal. A really handy addition to Drush is Drush Make, a tool that makes it easy to identify all the files needed to create a new Drupal site and automatically retrieve and download them. Most Drupal sites have at least a few files that come from non-Drupal locations -- like javascript or flash libraries that need to be downloaded separately and moved to some specific location within your Drupal installation. Drush Make makes it easy to pull these files together.

All the examples I had seen for Drush Make used Drupal core, but I recently wanted to create a new site using PressFlow, an alternative to the regular Drupal core code that has lots of performance enhancements. The PressFlow files are not hosted on Drupal.org, they need to be retrieved from the PressFlow site. The site will also be using ApacheSolr and jQuery UI, both of which require grabbing code from external locations. I wanted to create a system to pull these files together automatically using Drush Make, but it took a bit of digging to figure out how to do it. read more »

We recently started serving our Drupal training video downloads from Amazon CloudFront, a web service for content delivery, through the Lullabot Store. Because of this change we are pleased to say that the download speeds have been drastically improved. The process of integrating CloudFront into your own Ubercart store is fairly simple. However, there is a requirement that your version of PHP is compiled with OpenSSL. If OpenSSL is not enabled you will get errors. We have posted the Ubercart CloudFront module on Drupal.org so that it can be further improved.

Amazon CloudFront

Amazon CloudFront is a web service for content delivery. It integrates with other Amazon Web Services to give developers and businesses an easy way to distribute content to end users with low latency, high data transfer speeds, and no commitments.

The dark days of Drupal theming are history. Today, it's pretty easy to find a slick design for your site, and if you need to build one from scratch there are great training tools to make the process painless. (Shameless plug: Lullabot's Theming Basics and Advanced Theming DVDs are a great resource!)

What's still relatively uncommon, though, is support for user-friendly customization by non-designers. Drupal 5 shipped with the re-colorable Garland theme, and a handful of themes support the same feature via Color module. The Nitobe theme offers a choice of header images; Development Seed's Singular theme lets administrators upload a custom background image for a site; and TopNotchThemes' Fusion theme allows administrators to choose fonts and switch from fixed-width to liquid layout using a settings screen.

Adding these kinds of customization options to a theme can make a huge difference in usability for end users and administrators. In this article, we'll learn how to add a "header image" setting to a theme, allowing a site manager to change the site's header from the administration screen! read more »

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. This includes:

• The sites sharing a single log-in must be on the same domain. For example:
• www.example.com
• forums.example.com
• subsite.example.com
• You must be using MySQL.
• Your sites must be on the same hardware cluster to be able to query each other's databases.

If your site fits within those requirements, you're on your way to simple, efficient, and easy Single Sign-on!

The concept for this single sign-on approach is based around Drupal's ability to prefix database tables. As you may know, you can run multiple Drupal sites on the same MySQL database. However, most sites are not configured this way, each site is given it's own dedicated database. Drupal's table prefixing can be combined with MySQL's ability to query across databases to make a simple "shared table" across multiple sites. Then you just need to set a cookie domain so that the two sites share session information and you're done! read more »