If all of a sudden you notice that the SELECT elements in your Drupal forms increases to 4 and any smaller size is ignored...

... maybe you've already forgotten you were using Chrome, and it is not a Drupal bug : this is a "usability" feature of WebKit. See http://trac.webkit.org/browser/trunk/WebCore/rendering/RenderListBox.cpp#L67.

Safari users are probably used to it, but for users of other browsers, this is a bit disconcerting.

Using a graphics library, be GD, ImageMagick or anything else, is convenient, but carries a price to pay: unlike most Drupal parts, which are generally database-bound, image generation is typically CPU-bound: generating many images on the fly can significantly increase the CPU load on a system, while Drupal setups are typically not optimized for this, and could result in problems if you are using Drupal on a shared hosting account. So what ?

In the previous post, we saw how to create a XHTML progress bar widget for Forms API, using theme_progress_bar. The next logical step is now to create a graphical equivalent to that progress bar, as an example for far more advanced fully graphical widgets made possible using a similar mechanism.

As a Drupal user, you certainly noticed that update.php displays a nice progress bar to make you wait during its batch operations. And maybe you also noticed theme_progress_bar in the API reference.

The question

Wouldn't it be nice to have that progress bar available as an extended version of markup that would graphically display a value in your forms without stuffing it in a markup element ?

For some reason or another, I've noticed several new Drupal developers these last few days sweating on Forms API, and thought it would be nice to have a smallish example to complement the unavoidable FAPI reference and Guick start guide, for a typical non-basic form: one including set of checkboxes in a table, with a customized display, like the core user, content or modules administration forms. So follow me while we build this example.

If you are [considering] working on an e-Commerce site, and are coming to the Szeged Drupalcon, you may be interested in several sessions around the theme. In order for your session(s) of choice to stand a chance of being actually part of the conference program, you should vote for the sessions you would like to attend.

Subjet to approval by the conference board, I will be animating/presenting a session about the internals of the e-Commerce suite: see http://szeged2008.drupalcon.org/program/sessions/developing-e-commerce for more details. If this is of interest to you, vote on the session to make sure it will indeed be included in the conference program.

In summer 2006, I created the img_relocator module, which was published to my sandbox, and apparently picked up by some Drupal admins, although it was never promoted to full-fledged project status.

I was working on an existing site today, and after installing the e-commerce 3.4 suite (EC), noticed something was very weird: product type modules were enabled, all basic EC modules were there too, and yet, when I created products by hand, the "Anonymous purchase" fieldset appeared, but nothing else from EC.

Worse, when saving the new products, they were properly created in the {node} table, but never appeared in the {ec_product} table, which caused them never to appear as products in the admin products list of the product view available to users. What could be going on ?

Having recently merged a number of separately configured sites into a single consolidated multisite, I found myself with URLs like:

http://www.site1.com/sites/www.site1.com/files/somefile.png

...on all except the main site of the multisite configuration.

Although img_relocator allows me to just type things like:

<img src="somefile.png" />

... and still have these URLs be automagically generated, they still appear to those users who actually look at the URLs.

Enter mod_rewrite

Abandon all hope, ye who enter here

With these sites running over Apache 2.x, mod_rewrite offers a simple way to rewrite the files URLs: in the Apache site definition file for the vhost describing the site, we can use:

At long last, I've moved the OSInet sites from shared hosting to a VDS over the 4-day Xmas period, and overall it went well.

However, with new users (dare I say bots ?) eager to refresh the site after a few hours offline, I soon had to stand about 20 hits/sec, which proved to be a bit too much on this small VDS. So I enlisted the help of APC, just like the drupal.org sysops do, and like I do on the group's intranet servers and it went really faster.