DRUPAL-5

So DrupalCon Prague is almost over, and I can now share with you the video of my session about the history of the Drupal block system, from drop.org to Drupal 8, just as recorded on wednesday.

The session page is available on https://prague2013.drupal.org/session/blocks-drop.org-drupal-8-and-beyo… where you can also rate it. Please to it over there, or add your comments here: it is very useful for me to see what needs to be adjusted for upcoming presentations. Based on the overall feedback, it seems that:

So the scenario is this: you notice that you are no longer able to login on your Drupal site:

• the {users} table entry for your account looks just fine
• the login and access timestamps on your account are just a few seconds old, matching your latest attempt to login
• you reset your password in the DB, just in case, and it still does not work
• the telltale is that Drupal will not even tell you your login failed: it actually works, as the {users} table shows, but yet you are not logged in

Can you guess what can have been going wrong and fix it ?

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:

<?php// lazy version for simple casesfunction foo_bar($x, $y, $z) {  dsm(func_get_args());  // [...]// less lazy version for more hairy casesfunction foo_baz($x, $y, $z) {  dsm(array('in foo_baz, x' => $x, 'y' => $y, 'z' => $z));  // ...?>

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 ?

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.