Having non-HTML-skilled contributors input content on a Drupal site seems to often lead to invalid HTML tag soup being input. And even with seasoned coders, a HTML input error happens sometimes, which can be a problem until someone fixes the post.
So I figured I'd force valid HTML from user input, and here is the proof-of-concept valid_node module: it will force any node to be saved as a XHTML fragment.
Some months ago, I noticed Arnab's blog note about the importance of the sequence table, albeit in a multisite context.
This table also needs special care when copying a drupal site: logically enough, its rows contain the name of the prefixed tables for which a sequence is maintained. For instance, this means that, if you defined the source site as using, say, oldsite_ as a prefix, the name field on the row for the next nid will look like: oldsite_node_nid.
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... :
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.
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.
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.