After a massive user import to a customer's site, said customer noticed that, while he could see any user profile when logged, he could only see some of them when he was not logged in, receiving an "access denied" on the other accounts.

Now, with the administer users permission, a user can see any profile, so this didn't come into consideration, but since anonymous users could see some profiles and not others, the permissions granting anonymous access to the profiles were obviously set up correctly. So what could be wrong ?

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.

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:

2007-08-23: site updated to Newsflash 0.12 : the Helvetica selector is gone, which means some of the content of this post no longer applies.

I've just given this blog a facelist using the Roople NewsFlash theme, and I'm somehow dubitative about it:

• on the plus side
  • the 3 "user" blocks above content and the 3 other ones below content are a neat feature
  • the color balance feels good to me, in either of the 3 predefined colors
  • overall, it works way better than my "nested" theme a few months ago
• on the minus side
  • although I tried various content layouts using the 3 user blocks, I couldn't get anything fit properly in them: it seems these will be specifically useful when a site has snippets of equivalent size to fill in them. This could probably be news (the theme isn't called Newsflash for nothing) or ads
  • on my screen at least, the text appears blurry, especially in Firefox
  • generally speaking, it seems bold font is used too much, with essentially the same character sizes for title, tags, and various links. I think some more gradation in font effects would be welcome
  • the site slogan is incorrectly positioned in MSIE
  • in Opera and Firefox, the site slogan ascenders collides with the site name descenders
  • the logo display code is wrong (relative URLs); I had to tweak it in page.tpl.php to accomodate the site folder structure
  • the logo setting doesn't apply properly