Skip to content

Instantly share code, notes, and snippets.

@andsimakov
Forked from marteinn/info.md
Created September 16, 2020 19:07
Show Gist options
  • Save andsimakov/c933b2849e31e043b46b0a8b1984e7ec to your computer and use it in GitHub Desktop.
Save andsimakov/c933b2849e31e043b46b0a8b1984e7ec to your computer and use it in GitHub Desktop.
Integrating a DAM solution in Wagtail

Integrating a DAM solution in Wagtail

Key arguments for using a DAM

First, what is the primary purpose with using a DAM (Digital Asset Management) solution? There are several, but these are the features:

  • Having a centralized digital asset management (keep your pictures in one place)
  • Keeping your assets in sync and making sure licenses are up to date (when does image X expire, are author information correct?)
  • Keep track on where your digital assets usage (my bird image are used on site X, Y and Z)

So, how would we go about integrating a DAM in Wagtail? These are the steps me (me and others) took in a real-world project.

Implementing a DAM browser and importing data

The approach we took in Wagtail was to first override the default templates and add custom navigation elements, we did this to both the images and documents app where we override the chooser and add templates. (ex: wagtailimages/chooser/chooser.html, wagtailimages/multiple/add.html)

The custom navigation opens up a 3:rd party widget built by the DAM provider, where assets are listed and the author can select assets to import.

We can communicate with the widget using a js based api, so callbacks lets us know selections are done.

window.DAMProvider.onSelectionDone = (images) => doImport(images);

function doImport(images) {
    images.map(image => callMyCustomImportEndpointInWagtail(image.id));
}

We then react on the callbacks and import all selected assets into Wagtail by downloading proper assets and programmatically create image/document model instances. I think we performed the import by calling a custom endpoint we set up in Wagtail that accepted an id and did the heavy lifting, by retrieving data from DAM and downloading assets and creating the model instance. We made sure to use a custom image and document model, so we could add extra data, such as license information, author, DAM identifier and so on.

The positive aspect with importing assets (rather than referencing it) is that we can leverage Wagtails focal field and image sizing and other apps in the Wagtail ecosystem.

Making sure the assets are in sync

To keep the data in sync, we created a management command that runs on a schedule and updates local asset data, such as licensing, description and author against the DAM api. Updating assets on demand could be done with a webhook, if supported by DAM.

We also provided a customized admin view so authors could keep track of license information and get warnings if a certain asset license is about to expire. Since we already had a custom image/document model with DAM data, adding filters and fields was easy. Not sure if we used the built in modeladmin, but you should definitely use it.

Keeping track on where assets are used

Keeping track of usage is a bit trickier, since there are multiple ways to include assets on a website (ForeignKey, RichTextEditor...). We settled on a bulky approach (requests+beautiful soup!) where we added additional metadata on every image tag on the frontend. We then scrape the page on every save, using a hook, and parse the tags to pick up usage. We then report that usage data back to the DAM provider over their API.

It works well, but you need to have SSR (Server Side Rendering) in place if you have a JS-heavy site, or find another way to add usage markers.

The end

This was all, I’m available for questions at the Wagtail slack under the user marteinn. You can also ask questions in the comments below (just make sure to tag me, so I get notifications)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment