drupal

Something is overriding config in Drupal - you can see it by invoking drush with and without the flag to include overrides:

$ drush cget system.performance | grep -B1 preprocess
css:
  preprocess: false
--
js:
  preprocess: false

$ drush cget --include-overridden system.performance | grep -B1 preprocess
css:
  preprocess: true
--
js:
  preprocess: true

Perhaps we want to turn this config off, but these overrides won't let us.

Where are these config overrides coming from?

This is a simple trick which (unless my googlefu simply failed me) I didn't find described anywhere when I had a quick look:

$ drush ev '$file = file_load(21749); var_dump(file_delete($file, TRUE));'
bool(true)

Quite some time ago I wrote a post about how patching makes you feel good in which I talked about the motivations for, and benefits of submitting patches on drupal.org (d.o). I concluded by suggesting that project maintainers should be generous in recognising the efforts of those who submit patches.

I was using the brilliant context module in a project recently. The fact that it uses ctools means it has a few characteristics reminiscent of views (and panels). One of these is the import / export functionality, and the distinction between the different types of storage for the contexts you've set up - i.e.

In general I'm a happy vim user, but now and again I am asked why I'm using such an antiquated environment. Editor preference is of course a topic over which many long and pointless arguments have been waged - often from intractable dug-in positions of dogma. I think it's good to poke your head above the trench occasionally and see what else is available.

I recently found myself trying to use drush to set up a Drupal 6 install on a server where I did not have root access. I kept getting errors along the lines of this:

Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 1234 bytes)

I didn't have permission to edit the php.ini file for php_cli, so I had to find another workaround. The solution's pretty simple and comes courtesy of the drushrc.php file.

I was recently asked to add a simple twitter feed to a Drupal 5 site I built a few years ago. You know the sort of thing - a block in the sidebar with the 5 most recent tweets from the organisation's twitter account. Unfortunately, this turned out to be one of those requests that sounds like it's going to be really easy, but is not (especially on Drupal 5). I came up with a solution which does the job quite nicely, but it's a bit of a hack; I wouldn't do it like this on a new site - but then of course I wouldn't be using Drupal 5.

I came across a problem when working on a Drupal user registration form which had to include an accept terms and conditions checkbox. In fact, I came across a couple of problems, but I only had to fix one myself.

I recently undertook a migration from oscommerce to ubercart. The scope of this migration was limited to the transfer of products (and categories) - I didn't try and migrate customers and previous orders.

Here's an overview of the procedure I followed:

There are several different PHP accelerators to choose from, but according to wikipedia "APC is quickly becoming the de-facto standard PHP caching mechanism as it will be included built-in to the core of PHP starting with PHP 6".

I recently put together a new development webserver in a virtualbox virtual machine, and as I was setting it up I thought I'd take the opportunity to test how much difference APC actually makes to a simple Drupal site.