modules

(in progress)

As of April 15, reports are that the latest dev of of Webform Block works with the latest dev of Webform 3.x, and based on dates, Beta5 should also work.

Webform Block is reported to work with 3.x with a patch and some workarounds.

Salesforce Webform integration may be the sticking point for 3.x.

for file in mysql dbname -e "SELECT filename FROM system" | sed "1d"; do [ ! -f $file ] && echo $file; done

This lists all the files from the system table that do not exist in the actual file system anymore.

In our experience, this more often mean modules with bad uninstall practices, rather than modules deleted without uninstalling.

See also Enabled Modules

This is for a module where the current version's code is in HEAD and we aren't going to do any branching.

(agc is an agaric-specific helper script.)

agc entreztest NEW
cd drupal/
cd sites/all/modules/
mkdir entrez
export CVSROOT=:pserver:agaric@cvs.drupal.org:/cvs/drupal-contrib
cvs login
cvs co -d entrez contributions/modules/entrez
cd entrez/

Prep

Note: A couple things are specific to my local development environment, the location of the site code of course but also that development modules are maintained in their own directory and symlinked into local checkouts of sites (this keeps development-oriented modules out of code that is deployed to production).

Thus, prepping the module builder code looked like this for me, including symlinking the dev code in, which is usually already done for me by the checkout script:

A cool thing about hook_enable is that Drupal can find it in your .install file, even when the module has already been installed and you are just enabling it.

(As evidenced by implementation of hook_enable in comment.install and all over contrib dot install files.)

So you can keep it out of your main .module file and throw it in your .install file.

Drupal's hook_enable can be in .install.