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.

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');

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.

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

I need a user hook that sends password reset events.

I created a very simple module to do this - but it doesn't work.

I think this is because user_pass_reset() calls drupal_goto() after a login link is used - and that this bypasses my extra form handler.

and according to

http://www.advomatic.com/blogs/marco-carbone/drupal-privacy-configuring-...

form_alter on 'user_pass_reset' doesn't work reliably, due to how the one-time login form is implemented

<?php

I've long been puzzled by the official advice on upgrading Drupal

It basically says you should delete everything, unpack a new Drupal version, and replace your customisations.

I like to use version control to manage my site.

My current project uses the pressflow fork of Drupal, I downloaded the current and new versions of this, added them to my repository and then upgrading my working copy is as easy as

Here's a basic Drupal Module that pulls CKAN data into Drupal.

It provides a simple search interface - when the user views a CKAN package for the first time a corresponding node is created.

When this node is then viewed Drupal loads the package details - I'm only displaying notes and title here as I've run out of time tonight - but the rest of the data is there.

You can then have user comments, voting, etc on these pages.