Storage and retrieval of Drupal node content as plain HTML files
Every time a Drupal node is saved, a corresponding pure-XHTML file is updated. This means that content can be retained even if the database is unavailable.
It can be used to serve legacy content, create backups, or provide alternate renderings of the pages via XSL or similar.
It's also handy for testing the metadata and microformat retention as pages get round-tripped in and out the importer.
The static HTML dump attempts to be as 'vanilla' as possible, retaining only the semantic content of a node. At the same time, it serializes a bunch of 'metadata' extracted from Drupal (creator, date, taxonomy keywords), and saves is as Dublin- Core- style 'meta' tags in the file.
The files will be saved as annotated XHTML in a designated directory (configurable via admin/settings/static) with a filename corresponding to its Drupal path - either the url alias+"htm" or "node/{n}.htm" depending on whether the node has a "path" set.
NOT every bit of information will be saved this way, it is up to additional modules to provide a way to save their custom data. None of the non-core modules (or node types) are supported in this way yet.
Also, for the purposes of archiving, the proprietary Drupal 'input filters' may not survive the read/write round-trip process. The HTML that is saved is 'cooked' and has had the appropriate filters already applied. This means that reading them in again will retrieve the already-filtered source, which will be valid, but no longer as dynamic. token.module, reptag.module, image_assist.module or other markdown filters will now be pure HTML. If you make extensive use of such filters, you should not run static.module in read- write mode, only as write-only.
When retrieval is set to aggressive (always read) or intelligent
(read if newer than node-modified date), the flat file will be read back
and displayed. This allows for HTML to be updated directly from outside
of Drupal.
If left 'passive', Drupal node management continues as normal and the
static files are write-only, used for backup but not read back in again.
Maintaining relationships between [drupal nodes]-[drupal nodes], and [static files]-[static files] at the same time is problematic. The true solution is probably to use something like Apache content-negotiation, but as we are intending to create a workable flat file archive, that's not going to help.
If your nodes refer to each other, the links will need to be re-made.
This setup can be used to serve externally maintained HTML files through a Drupal front-end. If, for instance you have a process that writes to static HTML, this HTML can be forwarded through Drupal as a node. If you wish to use a third party HTML editor and maintain your content that way, static HTML will just work, although creating new pages may be tricky.
In all cases, however, the input must be valid XHTML, and be of a format compatable to the normal static HTML output. If it's not, then each page read needs to pass through the reasonably intensive import_html import template process. To enable this, check the 'advanced import' in the settings.
Note that choosing to run the import_html process again will run it with allem> the current configurations set, such as taxonomy classification, user ownership etc.