Quick function to delete a view.

This is basically what the UI form submit does.

I've found altering CCK node types as part of a fully scripted deployment phase to be quite challenging.

The best I've come up with is to use features for the main config changes and adding fields, but this won't remove any fields - but CCK provides functions for this.

Oddly installing the features module doesn't make the database schema changes until after caches are cleared.

The following code updates my CCK type, with new fields and settings.

If you've ever tried to debug your update hooks via drush you may (like me) have been puzzled as to why your breakpoints don't seem to work.

It seems that proc_open() is used to avoid memory issues http://drupal.org/node/687724 (effectively resetting all the Drupal static variables??) and this separate process isn't available to the debugger.

After stepping though the drush update process I found where this happens and have a bypass that is basically functional (drush reporting seems broken - but I can step through my code).

This patch is the change I've made.

I've been looking into git for a while, the core toolset has been mature for ages but it just didn't seem to have the wider support I wanted.

Now I look again and the egit plugin for eclipse has improved massively with full eclipse integration http://wiki.eclipse.org/EGit/User_Guide

There is a git plugin for trac http://trac-hacks.org/wiki/GitPlugin

It looks like it's time for me to dive into git properly :-)

Drupal update hooks can return info about queries run - and this is well documented.

If you want to return other informative messages about updates - just use the same format as returned by http://api.drupal.org/api/function/update_sql/6

So you might have an update hook that looks like.

<?php
/**
* Drush picks up notes from here
* Will update myvar to new val because...
*/
function mymodule_update_6101(){
$items = array();
$myval = "foo":
variable_set('myvar', $myval');

I've just spent too long being very confused as to why varnish wasn't working

I'd forgotten that  the Debian version doesn't read the default.vcl config file by default!

You have to edit /etc/default/varnish and specify the config type you want.

I was getting the error message

In order to make releases repeatable, to be able to test updates and share work will colleagues it is really useful to install new modules (and disable old ones) in update hooks.

This way one just has to update the code, then run update.php and you have the latest version of the site.

It also makes it easy to pull in a copy of the live database and check that the update still works (because it's easy you actually find yourself doing it).

Well that's the logic, but it wasn't entirely obvious to me how to do this.

I'm using varnish to cache a REST service that's slow enough to cause me grief in development.

Out of the box it assumes you are caching your own server and that the client is already using the right host header.

To specify that it should use a host header to match the backend I'm using a config like

To make a Drupal module that provides triggers you need to

1. Use module_invoke_all at the point your code triggers an event.
   <?php
module_invoke_all('mymodule', $op, $arg1, $arg2, ....);
?>

   This basically defines a hook that your module provides - it has to be called after the name of your module because of a bug

When I installed my system I wasn't quite happy with the way the installer divided my hard disk - but at the time I was in a hurry...

I have since found that repeated loading of databases during development used up all available space in /var and debug files were filling /tmp

So I had to figure out how to resize them.

Thanks to 

http://blog.dhampir.no/content/resizing-an-ext3-filesystem-on-an-lvm