Want to get Lullabot article, videocast, and podcast announcements delivered right to your in-box?
Let us know your email address (we won't share it) and we'll let you know when anything exciting happens.
Theming Best Practices (Garland Gets a Cleanup)
April 28, 2008
Yesterday Garland got a long-overdue update: The page.tpl.php file was updated to use best practices. Now we can finally open up Garland in a workshop scenario and not have to use it as example of the bad practices within a .tpl.php file. This article applies to Drupal 6 and higher, though the theming principles apply to all versions of Drupal.
What's this about best practices? Let's compare the before and after of a few of the improvements. Each of the items below are extremely common things you can do to keep your .tpl.php files clean.
Modifying Forms in Drupal 5 and 6
March 17, 2008
Drupal has a lot of forms to fill out and not all of them may be just the way you want or need them to be. Modifying forms is a topic that is often met with groans but once you understand the two methods to accomplish the task and the basic, underlying concepts, it really isn't that hard to do at all. You'll be a form-modifying, input-customizing wiz in no time. This article will briefly discuss what's going on and then mainly focus on showing working examples for both methods in Drupal 5 and 6. You should be comfortable creating a new function, looking at arrays and a having at least a passing understanding of the Forms API is real handy. Also note that in the examples below I have them wrapped in php tags but you should not include those if you copy/paste. That is just so it looks nice and clear for the article.
Deciding to make the change in the theme or a module
So there are two methods for altering form output in Drupal, one at the theme layer and the other through a custom module. Changes to the HTML can be accomplished with either method so most people will use the method they are more comfortable with already; themers use the theme and developers use a module. There are two situations however where you will want to use a module rather than a theme:
- Changing functionality of a form (e.g. adding new validation rules or submission actions) can only happen in a module.
Replace any string in Drupal (5/6), without Locale module
February 2, 2008
During a recent Lullboat podcast we mentioned a new feature in Drupal 6 that allows you replace any string in Drupal without using Locale module (thanks Moshe!). Faithful podcast listener Rob Loach took it upon himself to write the String Overrides module that lets you accomplish this task with ease in Drupal 6.
While Lullabots were lamenting the fact that this feature was never in Drupal 5, we realized that it actually could be accomplished. An hour after undertaking the project, the patch was submitted to the String Overrides queue and committed shortly afterwards.
String Overrides accomplishes this in Drupal 5 by imitating the Locale module, and without hitting the database (since variables are cached and pulled up on every request anyway). Since this essentially a hack for Drupal 5, you cannot combine it with Locale module or languages other than English. Here's the key code that makes this possible:
Setup a Memcached-Enabled MAMP Sandbox Environment
January 25, 2008
Memcached is a service that allows entire database tables to be stored in memory, drastically speeding up queries to those tables and alleviating database load. In Drupal, the Memcached module allows you to store all cache tables in memory.
This article will guide you through installing memcache on your Mac OS X sandbox machine, allowing you to test memcache deployments locally. For in-depth instructions on installing memcache on a production server, read the companion article on How to install Memcache on Debian Etch. This was installed on Mac OS 10.5.1 and MAMP 1.7 with PHP 5.2.5.
Using Lighttpd as a static file server for Drupal
January 2, 2008
This article discusses Drupal 5.5 and Lighttpd 1.4, with special consideration for the imagecache module 5.x-1.3.
Building websites that can handle high amounts of traffic involves finding points of scalability in the network architecture. There is a lot of discussion about database replication and redundant web servers, but very little discussion has taken place about serving static files from a different server than the one which executes PHP. This article shows how you can configure Drupal to serve static files from a separate server, potentially on a separate machine. There is even a solution for those of you who are using the imagecache module.
Static vs Dynamic content
A webpage in your browser usually consists of HTML plus Javascript, images, CSS, and perhaps some Flash. The typical order of events is that the browser requests the HTML, parses it, and then begins to request the additional .js, .css, .png, .gif, and .flv files. This sequence is well diagrammed on the Yahoo! Developer Network. For Drupal sites, the initial request that returns the HTML is a dynamic request, meaning PHP code and a database are required to generate the HTML. The rest of the requests, however, reference static files. These files require neither PHP nor a database and can be returned to the browser by the simplest and most lightweight web servers available. This is the fundamental difference between a dynamic request (one that requires a script language like PHP) and a static request (one which returns an simple file from the file system).
For a web server like Apache to serve a dynamic Drupal page, it must load extra software (mod_php) in order to be able to execute PHP. This extra software increases the memory footprint of the server and reduces the total number of requests that it can handle before the machine's physical memory is exhausted. Even more memory intensive is the act of executing PHP. A Drupal site with lots of modules installed that handles a lot of data from the database can easily require 64M of memory per thread. This is a huge expenditure of memory compared to the 1-2M it takes to serve a static file. Since Apache recycles its worker threads, you end up in a situation where the same 64M monster that created the Drupal HTML is also used for serving a .jpg file. This is a huge waste of resources.
Adding a static file server to your network thus brings the following advantages:
- Static files are served from a server optimized for the task
- Better utilization of "heavy" PHP server resources
- A new point for scalability; you can add more machines to run static file servers if needed using typical load balancing techniques
A Drupal Module Developer's Guide to SimpleTest
January 1, 2008
Introduction
Have you ever experienced any of the following symptoms?
- You have changed code at one place in your module that broke things in another place and you spent way too long trying to track down the problem (or worse, didn't find it at all until your users started yelling?).
- You frequently (or not frequently enough ;)) waste dozens of minutes clicking around on all kinds of forms in order to test your module.
- Your module doesn't have enough users to act as a QA team, so basically you're it.
- You are paranoid to change anything in your code once it's working since there are ooky edge cases, and you can't ever remember what they all are.
- Thinking about developing your module gives you nausea and/or shortness of breath. ;)
If so, this article describes a cure: creating unit test coverage for your module using SimpleTest.
Revision Moderation is a module I wrote about a year ago to accomplish one "simple" task: leave the existing copy of a node there when new revisions are created, so that later revisions are not immediately visible until they're approved. People are depending on this module to protect their sites from vandalism, so it's vitally important that the module is working as expected at all times.
I was therefore experiencing all of the above, and finally got sick of it and decided to do something about it. Here's how I created unit test coverage for Revision Moderation module, and how you can do the same for your module.
Drupal 6: The Mashup Toolbox
December 17, 2007
If there's one geeky web catch phrase that's defined 2007, it's probably the much-abused mashup. If you haven't been trend-watching, a mashup is a web site that wires together data from other well-connected web sites to provide a unique and useful (or at least amusing) service. Take the Twitter.com feeds from all your project's developers, your Unfuddle.com checkin history, and slap it on top of a Google Map projection: voila! Developer productivity by zip code. That, friends, is a mashup.
True, many examples of the trend are novelties rather than killer apps. The number of people who really, really need to watch eBay auctions appear on a 3D globe in realtime, with gasoline prices in the latest bidder's home town, is pretty small. Underneath the hood, though, the technologies that make mashups possible are a profound change in how web sites manage and expose their data. More and more sites are exposing their data using simple RESTful APIs and XML feeds, and the new tools in Drupal 6 will make integrating that data into your sites a lot easier.
Three changes in particular may not sound very impressive compared to some of the other flashy features in the new version, but I've found them extremely useful. In writing the new Amazon module, Tumblr module, and an upgrade Twitter module for Drupal 6, these three features have saved me man-days of time.
Hiding content from Drupal's search system
November 26, 2007
Drupal offers a variety of ways to integrate with the built-in search system, from connecting with third-party search systems to adding information to standard node content. In addition, Drupal's search system respects the access permissions on each piece of content -- users who can't access a particular node will never see it in the results of their searches.
What happens, though, if you want users to be able to access some content (user bio nodes, for example) if they navigate to it directly, but don't want that content to appear in search results? Drupal doesn't offer any way to do that by default, but your custom module can use the same behind-the-scenes hooks used by the security system to control exactly what search results are presented to users.
An Introduction to Unit Testing in Drupal
November 26, 2007
This article applies to Drupal 5.3, the Simpletest module version 5.x-1.0, and the Simpletest project from Sourceforge.net, version simpletest_1.0.1beta2.
What is unit testing
Unit testing is the art and practice of taking a small portion of code, a unit, and subjecting it to programmatic tests to prove its correctness. The smallest units in PHP code are usually functions, and the unit tests will run the functions with sets of controlled parameters, and then make assertions about the return values of the function, or about the state of the application before and after the function has run. For example, if the function is designed to validate email addresses, the unit tests would pass in known valid email addresses and assert that they validate correctly. The tests would also pass in a number of invalid email addresses as well and assert that they do not validate.
Why is unit testing useful?
Writing unit tests helps produce higher quality code on many levels.
- The availability of tests helps detect the introduction of bugs whenever the programmer adds new features or refactors the code. This is called regression testing.
- Tests also serve as a source of documentation about what code is really expected to do.
Moving CCK Field Changes from Dev to Live
October 31, 2007
This article applies to Drupal 5 and higher.
If you're the maintainer of a even a small site using CCK for managing your information, eventually you'll run into a problem synchronzing your local install with your live site (or Dev and QA servers). While setting up CCK fields is a breeze and you have SVN to manage your PHP code, many Drupal developers haven't found a way to easily migrate changes in the CCK data schema or content type fields. However, using the handy macro module and a few (very important) lines of custom code, you can be moving your field changes from Dev to live in seconds.
