DRUPAL-4-7

The Drupal Block system from drop.org to Drupal 8: video from DrupalCon Prague Frederic Marand Fri, 2013-09-27 09:31

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:

Debug vanilla

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 cases
function foo_bar($x, $y, $z) {
dsm(func_get_args());
// [...]

// less lazy version for more hairy cases
function 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 :

If non-admin users can see some user accounts but not others...

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 ?

Reducing system load for graphical widgets

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 ?

Downloading modules when drupal.org is offline

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.

Updating drupal without file access

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.