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:
The problem: IMG elements and relative SRC paths
Since the designer is still on holiday, I created a fake logo for the upcoming OSInet 5.0 site, due this winter, and tried to give it a Web 2.0 look.
Did it work ? Any suggestions to increase the connotations ?
UPDATE 2006-08-28: for Audean.
For quite a long time I'd been wishing this blog had an original theme. Not that I dislike Marvin, but I felt it was time to create my own theme, especially after doing work on adding settings to drupal themes.
Since today was bank holiday for the Assumption day, I decided I'd use it to create a theme after one of my pet peeves: white space on web pages.
For some months now, I've been noticing that the Audean wiki, which I use as a live documentation site for various aspects of my sites, appeared comparatively rarely in Google search results, although it was referenced in various places and Google cache info (
cache:-prefixed queries) showed the site was indexed.
Now, the Audean Wiki is based on Splitbrain's Dokuwiki very convenient Open Source wiki, which often appears in relation with Drupal for documentation purposes, and it appears there are three problems with a default Dokuwiki installation, which prevent effective search engine optimization:
Here's how to overturn these hurdles.
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
UML diagram shows how they are logically related together.