Post write hooks

MIK can run scripts after it has written an import package to disk. These scripts are called "post-write hooks" and are enabled in the .ini file's [WRITER] section like this:

[WRITER]
...
postwritehooks[] = "/usr/bin/php extras/scripts/postwritehooks/validate_mods.php"
postwritehooks[] = "/usr/bin/php extras/scripts/postwritehooks/generate_fits.php"
postwritehooks[] = "/usr/bin/php extras/scripts/postwritehooks/object_timer.php"
; postwritehooks[] = "/usr/bin/php extras/scripts/postwritehooks/sample.php"
; postwritehooks[] = "/usr/bin/python extras/scripts/postwritehooks/sample.py"

The five scripts listed above are included in the MIK Github repository as examples. The ones named 'sample' illustrate some basic ways of using post-write hooks. Three complete functional scripts, extras/scripts/postwritehooks/validate_mods.php, extras/scripts/postwritehooks/generate_fits.php, and extras/scripts/postwritehooks/object_timer.php do useful things, as suggested by their names. They also illustrate how to use some of the components included with MIK such as Monolog and Guzzle.

A good example of how a post-write hook script can be used is to produce FITS output for newspaper page objects. As soon as MIK finishes creating the package, the generate_fits.php script runs FITS against each of the child OBJ datastream files and writes out its output for each one to TECHMD.xml within the page folder. This file is then loaded by the Islandora Newspaper Batch module, ending up as the TECHMD datastream for each page object. Another very useful example is validate_mods.php, which validates each MODS.xml file produced by MIK and writes out the result of the validation to the MIK log file.

Post-write hook scripts are passed three arguments from within the main mik script:

1. the value of the current item's record_key,
2. a comma-separated list of children record keys, and
3. the absolute path to the current MIK .ini file.

Hook scripts can grab these parameters, split out the list of child record keys and load the configuration file. Post-write hook scripts can be written in any language that can parse a standard .ini file.

Every script in the postwritehooks[] list is executed as a background process at the end of the processing loop within MIK so that the scripts don't slow MIK down. Some important implications of this include:

• The scripts cannot send any data back to the main MIK script.
• If the scripts write output files or modify files created by other parts of MIK, the location of those files must be determined from data that is passed into the script as arguments or from within the .ini file.
• A post-write hook script should not assume that another post-write hook script has completed running. In practice this means that they should only use as input the files that are produced by other parts of MIK, and not files generated by another post-write hook script. This also means that performing actions like zipping up output packages or creating Bags from them using a post-write hook script risks not including all of the output generated by other post-write hooks scripts.

Logging in post-write hook scripts

MIK doesn't enforce any particular logging pattern or library within post-write-hook scripts. generate_fits.php and validate_mods.php provide examples of using Monolog, and object_timer.php illustrates how to log results using PHP's file_put_contents(). If you write your own post-write hooks scripts, you are free to log their results in any way you want.