One feature I used to find missing in Drupal was the builtin ability to have themes include their own settings, like modules do.

For instance, a theme might allow switching renderings on the fly, without needing activation of specific stylesheets, or CSS or code tweaking, just by choosing parameters in an administration UI. But it was impossible. That is, until tonight.

Since a direct implementation in core seemed unlikely to see the day before 4.8/5.0, I created a proof-of-concept module just for this, called "themesettings".

The details and full source are available as a small demo which adds a "background" setting to a variant of the box_grey PHP theme, to define the background color of all nodes on the fly, just by choosing it from admin/themes/settings2/<chosen theme>. To read and download the code involved... :

The project module is at the heart of drupal.org. Here is a UML model of how it stores its data:

As of Drupal 4.7.3, project.module uses a set of tables in addition to core tables node and users. This UML diagram shows how they are logically related together.

Well, someone had to notice HTML pages were trees and do something visual about it, instead of the same usual "computer science" views of DOM trees. Here is the blog entry that implemented the idea and was overloaded by its success two months ago:

Web sites as graphs, on Aharef

And now for some samples of what hints it can give us about Drupal themes.

Highly anticipated concert on Sunday: this is our "big" concert for the year, in a private festival of multiple musical styles.

Beautiful uncommon setup for an outdoors concert, with a stage set on a tiny island, with some stage art :

Wouldn't you like a diagram of Drupal 4.7 with complete data types and referential integrity constraints ? Here's one.

The suggestion

Currently, various modules within core and contrib use various tables to store historical (i.e. "write once, read sometimes, never update") data. The most obvious is the watchdog table, but others exist, including accesslog, and zeitgeist's eponym table.

Would you like your non-english Drupal site to be more responsive ? I just found two-minute hack to speed it up, by a factor of four on the new Riff hosting. Here's how.

While revising devel.module in order to update the french translation, I noticed the queries performed by locale() took on the order of 20ms to be performed, and there are a whole lot of them on most pages when locale.module is enabled.

Since this seemed abnormally slow, I looked at the structure, and saw why. The current MySQL code goes:

In the recently introduced Drupal RC2, a pair of new functions have appeared: theme_search_block_form() and theme_search_theme_form(). They replace the ephemeral (some said "Easter Egg") theme_search_box() appeared and disappeared between RC1 and RC2, and raise important issues for themers.

The recent removal of the quasi-official node_validate_title() function from 4.7 causing various errors with contrib modules, I wondered whether there wouldn't be a way to trap such errors in a way that would be helpful to newbies, instead of the current situation where all they get from their newly haphazard drupal install is a PHP fatal error.

The idea, then, is to register obsolete functions in some form of legacy maintenance module, to generate a useful help page pointing the user to a doc page on drupal explaining why there is an error in his configuration and what he should do. In node_validate_title()'s case, the help is a bit succinct: http://drupal.org/node/22218#node_validate_title.

Find the shiny new release candidate on http://drupal.org/drupal-4.7.0-rc1

Why am I mentioning it here ? Well, much like many others, I contributed bug reports, some patches, and it's great to see the project actually nearing its 4.7 landmark.

Maybe it will even allow the new version of Riff News to go online in time.