DAM Integration Considerations

In POWR-205, the integration of ResourceSpace (RS), or potentially a different digital asset manager (DAM), was analyzed for potential integration with Drupal. Three main main approaches were considered.

Assumptions

1. Any approach we take will absorb or replace the ResourceSpace implementation created for the Water Bureau.
2. DAM functionality will be used by all city bureaus.
3. We do not want to host or manage non-public media in the public site; unlike the current implementation of POG, internal resources will reside in a dedicated intranet.

Approach 1: Manage and host all media in ResourceSpace

• RS is the single source for all resources used in POWR, both public and private.
• All bureaus are on-boarded to use RS to manage their resources.
• A custom media selector moduleis created within Drupal/POWR that allows editors to search public RS collections via the RS API, select resources, and link to them in POWR.
• Images and other files are only linked in POWR; all source files are stored in RS.
• Image styles/sizes are synchronized between Drupal and RS, either manually or through a custom automated process.
• Custom Drupal module intercepts media queries and links to the appropriate image sizes/styles in RS.
• Only resources in public RS collections can be linked in POWR, so granular collection permissions are not needed on the Drupal side.
• Custom media types can be created in Drupal that would support external resource references, while still utilizing taxonomies in Drupal.

PROS:

• Single repository for all resources; no duplication between POWR and RS instances.
• Preserves the existing implementation and all functionality of RS.
• Preserves the ability to use site taxonomies and group permissions through the use of custom media types that use references to resources in RS.

CONS:

• Requires even incidental images to be uploaded and managed in RS.
• Public and private resources are stored and managed in the same system.
• Editors would need to use a custom media uploader in Drupal that is more complex than the default Drupal uploader, or would have to jump between Drupal and RS and be trained in both.
• Performance considerations--the RS implementation would need to replicate the high-speed CDN functionality already available in Pantheon for file resources.
• ADFS SSO may not provide sufficient permissions granularity, so permissions may need to be duplicated in both Drupal and RS.
• Image styles/sizes need to be synchronized between Drupal and RS.
• Significant amount of custom development is required to both create a custom media selector, custom reference-style media types, and management tools in Drupal.

Approach 2 (PREFERRED): Host all POWR resources in Drupal but provide the ability to import from ResourceSpace

• RS is used as a repository for both private and public resource repository.
• Custom media sub-module in Drupal allows editors to search for and import resources from RS using the RS API.
• Drupal image styles are applied to images upon import; Drupal's media queries and display logic are utilized.
• Use of RS for managing images is not mandatory; editors may import from RS or upload directly into Drupal (mixed model).
• Resources may only be imported from public collections in RS, so collection permissions do not need to be synchronized with POWR.
• Specially trained resource administrators from each bureau manage resources in RS.
• Public collections could be "pushed" to Drupal.

PROS:

• Editors don't need to have knowledge of RS, beyond the ability to search and import using a customized media selector in Drupal.
• Preserves the existing implementation and all functionality of RS.
• Preserves the ability to use site taxonomies and group permissions for resources imported from RS.
• Performance issues in RS are less consequential, since images are served from Drupal.
• Amount of development effort is less than with Approach 1 or Approach 3.

CONS:

• Resources are duplicated in both Drupal and RS.
• Non-trivial amount of custom development is required to create the custom media selector and import functionality.

Approach 3: Customize Drupal to serve as a DAM, replacing ResourceSpace entirely

• Drupal doesn’t have media collections as RS does. However, tags could be used for this purpose. The D8 Permissions by Term module would allow us to approximate the permissions structure currently set up for the Water Bureau in RS.
• Additional tagging and custom fields can be applied to media types, approximating functionality in RS.
• EXIF data and PDF text extraction modules are available.
• Display galleries can be created using Views.
• Extending DAM functionality to other bureaus will be easier using this approach, as opposed to extending in RS to accommodate other bureaus. If taxonomy is used to create collections and manage permissions, on-boarding new bureaus and editors could be as simple as creating taxonomy terms.
• Advanced DAM features would need to be custom developed: ** Tracking downloads and usage ** Resource sharing, and share sunsetting ** Logic for displaying watermarked versions based on permissions and file restrictions (d8 watermarking module exists)
• While not an ideal solution in the public site, could be used effectively in the intranet implementation, but then would need tools to import resources into the public site.

PROS:

• Single system for CMS and DAM, requiring lower maintenance and training overhead.
• Eliminates the need to maintain RS, which is a fairly complex system with frequent core updates.

CONS:

• Co-mingles public and private resources in public site.
• Unnecessarily stores "deep storage" resource archives in an environment that requires high performance; cannot store resources in a cheaper, lower performance cloud space.
• Duplication of functionality that all already exists in RS.
• Existing Water Bureau documents and metadata will have to be imported from RS.

Conclusion

Approach 2 is preferred for a number of reasons, primarily because we want to keep public and private sites and resources separate. It also requires the least amount of development time. This approach allows us to integrate the RS option at a later date, since it preserves the existing media functionality in Drupal. We will defer the decision for now, with the option of building Approach 2 at a later date.

References

• There are a couple of old sandbox projects to integrate Drupal with ResourceSpace, but they are all on Drupal 7 and the previous version of RS that uses an obsolete API. They may be useful as an integration guide, but there is little or no re-usable code there.
• Acquia has created a D8 module for integration with their own DAM, which might provide some helpful guidance to creating our own RS integration module(s): https://www.drupal.org/project/media_acquiadam
• ResourceSpace API documentation: https://www.resourcespace.com/knowledge-base/api