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.
DrupalCamp Stockholm 2009
- Is Drupal secure: the Drupal project’s responses to the web’s most common software vulnerabilities
- Scalable Drupal infrastructure: a guide to planning, deploying, and scaling big websites
Drupalcon DC 2009
We’re co-hosting a party and you’re invited!
On Wednesday, May 20th at 6:30pm, Four Kitchens is teaming up with GeekAustin to spread Drupal love in Austin. This free event is a chance for local Drupal professionals to share their passion with the curious and uninitiated masses of our fair city.
A discussion recently arose on the Bazaar mailing list asking, “Why isn’t rebase support in core?” Rebase support is currently packaged as a plugin. This plugin is widely distributed, even in the standard Mac OS X installation bundle.
There are boring reasons that rebase support isn’t in core, like the lack of strong test coverage. More interesting are questions about the necessity of rebasing in typical workflows.
What is rebasing, and why should I care?
In large projects, there’s a mainline branch representing the current, global, coordinated development. In Drupal’s case, this is CVS HEAD. This mainline might not always be in perfect condition, but there’s a general sense that the mainline is not a sandbox for untested changes. Many changes are small enough that the developers simply work on and test a patch, but this workflow is inadequate for larger development projects like Fields in Core. Such large features require their own branch for development, a feature branch.
Despite being held on a Saturday, more than 15 dedicated Drupalers showed up for Day 4 of the San Francisco Drupal.org redesign sprint. Here’s what was achieved.
I’ve been tweeting back and forth with Alex Limi, one of the founders of Plone, about the validity of the security analysis from a CMS comparison report that includes Plone and Drupal. He’s proud of Plone’s infrequent vulnerability notices; it had two in the last year. Drupal had 26. Alex also cited a related IBM report on security in a later tweet.
While both reports above seem to identify Drupal (and Joomla! and WordPress, to be fair) as having notably bad security, they’re also both based on one superficial metric: self-reported vulnerabilities. Neither severity nor response time nor history of actual exploitation factored in.