drupal

Performance: Block Cache Alter

I just submitted Block Cache Alter for Drupal 6 which lets you alter cache settings per block on the configuration screen. Cache settings per block are now set in code, but if you don't like the default - usually none, you can now easily change this. Install this to speed up block rendering for authenticated users.

There are also two patches in the D7 queue now that might interest you:

  • Currently block caching support in views 2 is disabled, probably until 235673 gets in and backported.
  • I submitted this module as a patch (imagine how small it is) as a feature request for D7, review it on #347350.

Off-topic, I'm still looking for another maintainer for PicLens. File an issue and I'd be happy to move it over.

Some simple debugging tips for Drupal

It was a funny week when it comes to squashing bugs in a few projects I'm involved with. Less is more and this is also true when it comes to debugging I guess, always look in common places if you encouter strange things. So here's a small list I'm really going to add on my checklist of debugging tips:

1: Always look in watchdog first. Almost everything within Drupal comes from the database and quite often when data is (partially) missing, it's because a query goes wrong. My use case: developer 1 defines some fields in the views ui and than implemented a views_query_alter hook in a module. Two days later, developer 2 decided to change the fields and poof, the query_alter completely freaked out, no content was shown and developer 1 didn't even knew about the views change. After 3 hours, he noticed the watchdog error and saw a field was missing.

2: Export your views to files and install journal. Exporting the views into a file gives you history if you use a code repository. You can easily switch back to a state where you were absolutely certain your site worked flawlessly. When someone else decides to override your default view, journal comes in handy since it adds a required textarea on the views UI (and also all other settings pages) where one has to fill in something about the changes. And even if he or she is very cryptic about it, you at least know who might have borked up your installation.

3: Never trust other people's commits. I learned that the hard way this week. I was confident my module worked fine, even the simple tests I wrote were passing and suddenly watchdog (remember rule 1) was growing with error messages. A colleague added some code which had absolutely nothing todo with my functionality so I figured something was still wrong with mine. A few hours of frustration later, I noticed a small word in an array was changed from 'field' to 'a' which caused the error messages appearing in the log. I had no idea where this came from, so I looked at the commit history (please, use a code repository) and I found the exact moment where this (desastrous) change occured - nobody knows why and how. Of course, these things happen and I'm pretty sure it probably happened to me too where I accidently changed some code without knowing so.

4: Only 16 chars! If you add your own watchdog messages, always remember the type is limited 16 characters. This is actually one I have to blame myself for. I decided to add a lot of watchdog messages for every action that happened into my module, so I could track down any errors that occured. However, all my types looked like modulename_action. The irony here lies in the fact that the name of the module was 16 chars long and when the errors started to popup, the action suffix was cut off when inserted into the database, so I had no idea where to look first. A quick look at the table structure of watchdog triggered a loud ironic laughter in the room and another hard lesson learned.

Nerd night IV

One of my tasks on the Nerd Night yesterday was importing a custom php written blog into a Drupal installation. A simple import script querying basic info like title, date & body from the custom tables and doing a node_save($node) was a piece of cake, so after one hour, a good 500 entries were imported into Drupal. There was one small thing I couldn't fix immediately: those damn MS Word single & double quotes. For some reason, trying to import those made the rest of the entry disappear, so we had to manually copy/paste some of them as I didn't found an immediate solution. If anyone has some tips to fix this, let me know.

Also Drupal related, I got a mail this morning from an (old new - don't ask) colleague for an invitation to a party. To my big suprise, the Druplicon is on the leaflet but I honestly have no freaking idea why they used it. Not sure if I'm going to attend too ..

And to end with: I'm looking for new maintainers for PicLens and User types, I simply don't have enough time and/or interest to keep maintaining them fully, so anyone interested, file an issue in the webmasters queue and it's yours!

Szeged and the future of MediaRSS

For the first time I gave a presentation at a Drupalcon. I was a bit nervous at first, but all ended up well with some nice reactions from other people. It also convinced me completely that I should separate all MediaRSS functions in the PicLens module into a separate contrib called MediaRSS API. Not sure when I'll get to this, but it's the most logical thing todo, but I first need to clean up my issue queue since I didn't had a lot of time this week to work on my existing projects.

On the contrary, I had a good time networking at Szeged Drupalcon meeting a lot of new people and catching up with the ones I knew. I also started working on Views UI Permissions after some brainstorming with old colleagues after the last session on thursday. The first version was online friday morning, so in a way I did my own code sprint. And I was one of the winners of the Testing Party, hurray! And a first little test ended up in MediaRSS support for Kris Vanderwater's Imagefield Gallery project.

Anyway, back in Belgium now, allready counting off to the next Drupalcon. Big thanks to the Drupal community, you guys so rock!

Getting more reviewers involved for Drupal 7: unofficial BOF

There has been some discussion on the mailing list previous week concerning lack of reviewers for drupal patches. One of the reasons that came up was the fact it takes some time to set up a new clean environment to test a new patch. Given: download latest head (or better checkout from cvs), create or empty (existing) database, setting permissions, apply patch, add content, test by hand, run all simpletests, do some benchmarks (with every possible caching in mind) .. it does involve some point and click.

While doing some benchmark tests this week for the DBTNG patch (congrats Crell!), I probably repeated this complete set of tasks a couple of times - however, I didn't mind, it's for the benefit of everyone: Drupal, patch writers and also myself. Wow, that really sounds terribly squishy right ?

Anyway, at DrupalCon Boston, Roel and I experimented at bit with DAST, got it working on command-line and also within an eclipse environment, but never really worked out a clean battle plan to make it perfect. Our plan for Szeged is to work again on this, make it completely perfect so anyone on a *nix environment should be able to setup a new head with only one command (or click in eclipse) in like only 30 seconds. We'll create a dast profile and come up with some other tricks - maybe one or two other small bash scripts and after that, following should be possible:

  • CVS checkout from HEAD
  • Install database
  • Generate content with devel/drush
  • Apply patch
  • Run all simpletests (optional)
  • Run benchmark tests (optional)
  • Generate reports from previous two actions

I know, this sounds ambitious, but it really isn't *that* hard to achieve. If you have other ideas or if you're interested in helping out, contact us, we are those guys carrying tons of chocolate for the Testing Party!

Spam *N

I'm not sure exactly what's going on, but since a few days, spam attempts on my site have almost increased by 700%. I've been using Mollom to protect this sort of things and wow, am I happy to be using this webservice since a few months. I can't imagine unpublishing N comments per day. So a big thank you to Benjamin and Dries, I'm just wondering if this amount of spam (ok it's not *that* many I think) will require me to start paying from september on :)

Imagecache javascript crop has a scaling option!

It took me some time to realize I would not find a decent solution with Jquery Interface to implement some sort of scaling function in my Imagecache javascript crop (formerly imagecrop) module. After some thinking, I found a solution which satisfies me enough to release this for drupal 5. It's now possible to create an imagecache preset with only the javascript action and use the original image to crop - instead of first adding a scaling function, which would result in frustration. On the crop page you can scale the image, just as the screenshot underneath shows.

It's a select box at this point, I might change it to a textfield if I get many request for this. For now, it does what I and some clients want. Submit a patch if you want otherwhise (think: a setting on the imagecrop settings page).

Anyway, there's an issue about this feature at http://drupal.org/node/281867. Use that page to report problems if you find them. Oh - and I can't stress this enough - *only* about the scaling problem in D5, thanks :) So, if you're interested, go to http://drupal.org/project/imagecrop and test out the development version. When the issue above is closed in two weeks, I'll roll out a new release containing some other small, but important fixes!

I'll start porting the project to D6 after the drupalcon and - good news - it will use JQuery UI instead of Interface which gives me the opportunity to actually scale the image easier with jquery instead of a page refresh.

Update Aug 3, 20:34: A cool patch by swortis now supports the thickbox module. Instead of a window popup, the thickbox overlay is used. Coolness!

Trivial stuff to mention:

  • I renamed the project to Imagecache javascript crop instead of imagecrop. Makes more sense, really.
  • Yhager, ping-pong me on irc next week, we really need to have that talk!