- 2013-09-25: Presenting the history of the Drupal block system at DrupalCon Prague.
- 2013-09-20 to 29: Working on Drupal 8 EntityAPI at the extended code sprints during and around DrupalCon Prague
- 2012-08-19: Working on Drupal 8 EntityAPI at Drupalcon Munich
- 2012-06-15: Working on Drupal 8 EntityAPI at DrupalDevDays Barcelona
- 2012-03-23: Working on the future Drupal Document Oriented Storage at DrupalCon Denver. D8 or later ?
Bets are onLater
- 2009-11-29: mongodb_watchdog module created by dereine, ported to D7 by me in about half an hour, and migrated in a larger MongoDB project by damz before the hour ended. Wow...
Wouldn't you like a diagram of Drupal 4.7 with complete data types and referential integrity constraints ? Here's one.
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
zeitgeist's eponym table.
Logging through a unified API has the potential to reduce the code volume somehow, as all logging functions could be made one, and could also potentially be simplified to automatically record some information so that modules invoking the function don't have to write in some parameters, that could be recorded automatically.
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_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.
A few days ago, the designer working on our sites asked me stats about the browsers visiting the sites. She already had the general data available, but this time what she wanted was the info about the "other" browsers.
Which is quite true: once a site has been designed to standards and the quirks of the two or three major choices, work has to be spent on the non-standard non-mainstream ones. But to what extent ? Here are the data.
As I've been working with Drupal since last august, a recent discussion with the designer for our new sites made me wonder how the cost of time was distributed during a project like this one. What portion of the time has been spent getting up to speed on Drupal itself, on developing/maintaining Open Source modules, on creating the value-added private code, on miscellaneous tools and integration tasks, and eventually on the content itself. Here are the results:
Zend Studio is a convenient environment to code in PHP, which is why many Drupal developers are using it. But some settings are necessary to ease its use, due to the specific extensions Drupal uses.
Ofttimes, when developing a site, you can be led to create or import a large number of custom nodes, for instance flexinodes, only to have to delete them later on. Doing it by hand in admin/content is inconvenient when the number of nodes is large, and for custom nodes like flexinodes, the exact entries to delete in the various Drupal tables may not be obvious. Time for a workaround.