Most of the time, when working on some piece of code, I'll resort to the configured debugger in my current Zend Studio configuration. And you probably do too :-)

However, I often have to access debug-type information on live sites where installing a debugger is out of the question, and I find myself often resorting to parameter dumps like the following:

You've probably being using it too and, of course, after the first few dozen times, it becomes a bit used. So here's a tiny snippet that makes such dumps simpler to type and use :

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 ?

Drupal.org being unavailable quite frequently these days, some may find it hard to download the module of their choice.

Luckily, the downloads are static files served as public downloads outside Drupal itself: all it takes is knowing the proper URL, and they are all gathered on ftp://ftp.drupal.org/pub/drupal/files/projects, just waiting for your favorite FTP browser.

The "heavy" modules OSInet contributes to Drupal (G2, Helpdesk, Zeitgeist) have now been placed under the new release system.

Branches and releases have been created where applicable:

A few days ago, it was brought to my attention that something had been broken on the PHP-GTK community site during the 5.0 RC2 upgrade. The problem was easily identified as being codefilter.module having been removed during the upgrade and not reinstalled. Of course, not being at my office, I did not have access to the FTP passwords, but just to my admin account, and I did not want to leave the community members in the cold, so I used this small trick.

This table shows which operations are actually documented, used, and implemented, by the e-commerce ProductAPI, hook_productapi().

The new Garland / Minnelli theme (née Themetastic) from Drupal 5.0 is one of the main visible improvements over 4.7. However, not all sites are ready to make the jump to 5.0 as soon as it's ready, which should be very soon now, so why not use Garland on 4.7 ?

UPDATED for eC4 in new post

The Drupal ecommerce module suite is a rapidly evolving and quite massive part of Drupal, and newcoming developers may be overwhelmed by the sheer number of modules included in the suite. This UML dependency diagram chart should help understand how the modules fit together.

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.