Document how to build custom filters

Backup & Migrate already provides a means to provide custom filters, it's reasonably straightforward to write your own filter which can take actions before/during/after backup and restore operations. So while not quite as easy as regular hooks, it's entirely doable to accomplish what you need without patching Backup and Migrate.

Here is a sample filter module (called "FOOBAR") with stubs for all the available filter operations:

FOOBAR.module:

// Implementation of hook_backup_migrate_filters(), provides filter definition(s) to Backup and Migrate module
function FOOBAR_backup_migrate_filters(){
  return array(
    'FOOBAR' => array(
      'file' => drupal_get_path('module', 'FOOBAR') .'/filters.FOOBAR.inc',
      'class' => 'FOOBAR_backup_migrate_filter'
    )
  );
}

class FOOBAR_backup_migrate_filter extends backup_migrate_filter {
  
  // executed after a failed Backup
  function backup_fail($settings, $message, $params){
    drupal_set_message( 'Backup failed!' );
  }

  // executed after a successful Backup
  function backup_succeed($settings, $message, $params){
    drupal_set_message( 'Backup succeeded!' );
  }

  // executed after a failed Restore
  function restore_fail($settings, $message, $params){
    drupal_set_message( 'Restore failed!' );
  }

  // executed after a successful Restore
  function restore_succeed($settings, $message, $params){
    drupal_set_message( 'Restore succeeded!' );
  }

  /**
   * This function is called on a backup file after the backup has been completed.
   */
  function backup($file, &$settings) {
    return $file;
  }

  /**
   * This function is called on a backup file before importing it.
   */
  function restore($file, &$settings) {
    return $file;
  }

  /**
   * This function is called immediately prior to backup.
   */
  function pre_backup($source, $file, $settings) {

  }

  /**
   * This function is called immediately post backup.
   */
  function post_backup($source, $file, $settings) {

  }

}

See backup_migrate.module and includes/filters.inc for more details.

I am using this approach to enable the Environment Modules module after a Restore has completed. In this way I can automatically enable whatever modules I like after I have overwritten my dev DB with a backup from Production.

For completeness sake, an updated patch with a backup_migrate.api.php file that lists the two hooks, and adds comments before the module_invoke() statements to indicate what's happening.

This version turns brian_c's example code into a note for the README.txt file.

A slight improvement to the example code.

This issue has been filed against the 2.x branch which according to @DamienMcKenna should be deprecated. See this issue: Verify 7.x-2.x -to- 7.x-3.x upgrade path, mark 7.x-2.x as unsupported

In order to reduce the maintenance burden the 7.x-2.x branch should be deprecated. In order to do this the upgrade path to 7.x-3.x has to be verified and any issues fixed.

Feature requests we can bump to the current branch.

The documentation needs to be updated to match the latest Drupal coding standards. Also, at this point it is a documentation request.

Just a reroll of the 7.x-2.x patch.

The tasks from #11 still need to be done.

Drupal 7 is EOL. This issue will be closed.