There’s been a lot of talk lately about how Drupal designers shouldn’t have to learn CVS. Nothing new to see here, really — just the same tired, self-fulfilling arguments about how much CVS sucks, how developers also hate using it, and how designers shouldn’t be expected to learn something so… technical.
In early August, David, Todd, and I took a road trip to Dallas, TX to attend the first ever DrupalCamp Dallas. It was a two-day event organized by several Dallas-based Drupal shops: LevelTen Interactive, Koine Media, and Tarakan Design. We had a lot of fun meeting fellow Texas Drupalers and saw some excellent presentations as well.
Independent benchmarks by Josh Koenig from Chapter Three show a 3000x throughput increase and a 40x load reduction moving from plain Drupal to Pressflow + Varnish. His testing was performed on a small Amazon EC2 instance, demonstrating how Pressflow can deliver internet-scale performance on modest, inexpensive hardware. Pressflow is able to deliver this class of performance because it’s optimized to support Varnish and other enterprise-grade web infrastructure tools in ways that standard Drupal cannot.
With Pressflow’s API compatibility with Drupal, Josh’s move from Drupal to Pressflow on his project didn’t require any coding or extensive testing. He just replaced Drupal core with Pressflow. (It’s no harder than a minor Drupal update.)
For single-server setups in the Amazon EC2 cloud, Josh’s Project Mercury AMI provides a click-and-run, configured setup with the Pressflow + Varnish stack. For more complex setups, Four Kitchens provides infrastructure consulting services on the Pressflow system.
Josh Koenig from Chapter Three has made pre-release EC2 AMIs (pre-packaged virtual machine images) for Mercury, a project to combine Four Kitchens’ Drupal-derived, high-performance Pressflow with Varnish, Cache Router, and memcached. Initial results show it easily saturating the EC2’s pipe. Mercury instances directly update their Pressflow releases from the Four Kitchens Bazaar server.
Mercury is an exciting project for anyone who needs to run a high-traffic, Drupal-based site without having to configure a bunch of caching systems.
For modern applications, the word “schema” has become synonymous with the tables, columns, constraints, indexes, and foreign keys in a relational database management system. A typical relational schema affects physical concerns (like record layout on disk) and logical concerns (like the cascading deletion of records in related tables).
Schemas have gotten a bad name because current RDBMS tools give them these rotten attributes:
For quite some time, Four Kitchens has provided Pressflow releases to its large-scale clients and anyone interested enough to request a copy. We provided limited access to copies so that we could understand what organizations expected of Pressflow, how they wanted to use it, and so that we could keep all users updated with the latest security, bug-fix, and feature releases.
Jake Strawn of Drupal Dynamics and I are teaming up to propose a Accelerated grid theming using NineSixty session for DrupalCon Paris. (To be fair, he beat me to it and was gracious enough to add me as a co-presenter.)
Our session will cover the following basics of the 960 grid system:
- What is 960.gs?
- Using the NineSixty theme as your starting point / parent theme
- Understanding the
- Why a grid-based system can help speed up theme development
- How to break the 960-pixel limit
In the last month, I have presented sessions on 960.gs and the NineSixty theme at DrupalCamps in Copenhagen, Helsinki, and Stockholm. Most recently, I co-presented a session at Drupal Design Camp Boston with Nathan Smith, creator of the 960 grid system. You can download the slide decks on our “Presentations” page.
The Materialized View API (related posts) provides resources for pre-aggregation and indexing of data for use in complex queries. It does this by managing denormalized tables based on data living elsewhere in the database (and possibly elsewhere). As such, materialized views (MVs) must be populated and updated using large amounts of data. As users change data on the site, MVs must be intelligently updated to avoid complete (read: very slow) rebuilds. Part of performing these intelligent updates is calculating how user changes to data affect MVs in use. Until now, these updates had limitations in scalability and capability.
Note: This HOWTO covers Drupal 6.x.
By default, Drupal adds an
.error class to the form element itself:
input, and so on. Sometimes, that’s not good enough. Maybe a client needs the
label’s color changed — or a big, red border encompassing both the
label and input elements.
This can be achieved by overriding
theme_form_element() to add an error class to
div that wraps all elements in a form.
Our website has been featured on 960.gs, home of the 960 grid system! This is quite an honor, as we’re big fans of grid-based design — especially 960.gs — and have begun implementing its principles and techniques in virtually every project.