Digital.Grinnell employs a custom-built Drupal “view” we call the dg7 Collection View; it’s part of the code in our custom dg7 module where all of Digital.Grinnell‘s hook implementations are also defined. Experience leads me to beleive that keeping a complex Drupal view in code is prudent, but overriding that code with a database copy of the view helps tremendously in terms of system performance.
ISLE v1.3.0 has been running on my staging server, DGDockerX, for months now and it seems to be performing as-expected with one exception… when I try to import a batch of objects using IMI, the Islandora Multi-Importer, I get the following error:
Note: The abbreviation IMI is used frequently in this post to represent the Islandora Multi-Importer, a CSV-file-driven batch ingest tool used by numerous institutions in the Islandora community. Also, while updating this post I found this gem… Diagrams in Documentation (Markdown Guide).
A set of 21 PDF objects were ingested into Digital.Grinnell’s Faculty Scholarship collection using IMI on 22-July-2019; unfortunately none of these PDFs contained OCR (optical character recognition) or “text recognition” data, so none of them generated a valid FULL_TEXT datastream. FULL_TEXT datastreams are required to make PDF, and similar text content, searchable and discoverable in Digital.
Claiming another small victory today! Why? Well, the Digital.Grinnell instance of IMI (Islandora Multi-Importer) module is customized so that choosing “*local” as an object ingest source invokes a hook function I created in our DG7 module. That hook enables IMI to “find” named files/content (things like PDFs, images, etc.