The problem : Drupal awfully slow on Vista with Wampserver

For some time now, I'd been severiously annoyed by the (utter lack of) performance of Drupal 6 and 7 on my home PC, which happens to be running Microsoft Vista: considering I was used to getting page times around 200ms on a fractional Celeron with Apache 2.2 on a Linux server hosted comparatively far across the net from that same machine, I felt the 5 to 15 seconds response time per page on this local machine with a quad core and 3 GB RAM were really making me lose my time.

The solution

After some time spend googling around, I stumbled upon an incredibly simple tip, which made the 5 to 15 seconds per page drop down to around 1 second when logged in, and well below 500 ms when not logged in. It's incredible what ONE single character in a plain text file gets you under Vista :-)

So at long last, GW8 is becoming reality :

See the GW8 announcement on Novell communities.

As a long time developer on GroupWise (hey, I did this even before I started on Drupal !), I'm glad to see the product evolve. And already a planned upgrade for a customer :-)

Now, if I could find a project merging both... to this day, I've only used Delphi, both with OLE and SOAP, to communicate with GW.

Having to use Trac instead of our usual Drupal Project* setup for a new Drupal project, I just found out a problem which perplexed me for a moment: after following the instructions from the Trac site for a very basic setup, without SVN integration, all seems to work well, up to the point where I started the server.

# tracd --port 8000 /var/www/trac/proj1

The problem

... and went to my browser to http://www.example.com:8000/ only to receive an almost empty page, just saying "Available Projects" and nothing else. No error during trac-admin initenv. And the page was well-formed, showing it was likely not an actual bug.

Googling around the problem showed the issue to be already known, but offered no hint about the solution. What could be wrong ?

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.

Roughly two years ago, I prepared a diagram of the dependencies in the then-current version of Drupal e-Commerce (eC) for Drupal 4.6.

Now, with other eC projects looming ahead, a possible session about eC at Szeged, and eC 4 being in alpha, I figured it was time to update the model. Boy, has it changed ! Click the thumbnail for the full-size view.

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.