Attachments

Contents

Content items may optionally contain attachments - files that are uploaded and stored together with the content item.

Intro

Attachments allow you to add files to content items, similar to how files are attached to an e-mail. Attachments can be added to content items via the AttachmentUploader input type, and are stored as part of the content item in the repository.

Attachment vs Media

Media content items represent files as separate content items that, can be linked to, published and deleted individually. Attachments, on the other hand, are stored as part of the content item and do not have a separate existence. Attachments are not indexed as separate items. Attachments are ideal for files that are closely related to the content item and do not need to be managed separately, while media content items are better suited for files that need to be reused across multiple content items or managed independently.

Media items will typically contain one attachment, which is the file that was uploaded to create the media item.

Storage and indexing

Attachments are stored as part of the content item in the repository, and are indexed together with the content item. Attachments are stored within the content’s attachment property. Each attachment is represented as a property-set (object) with the following properties:

size

Attachment size

label

Attachment label

mimetype

Attachment mime-type

name

Attachment name

binary

Attachment reference (defaults to file name)

text

Text extracted from the attachment, e.g., PDF files

Example of how attachments appear in the content data:

{
  "attachments": [
    {
      "name": "document.pdf",
      "label": "source",
      "size": 238764,
      "mimeType": "application/pdf",
      "binary": "document.pdf",
      "text": "Extracted text content from the PDF..."
    },
    {
      "name": "photo.jpg",
      "label": "source",
      "size": 102400,
      "mimeType": "image/jpeg",
      "binary": "photo.jpg"
    }
  ]
}

You may query for attachments using the Content API, and also search for attachments based on their properties, e.g., attachment.name or attachment.text using Enonic’s Query API.

GraphQL

Guillotine exposes attachment metadata on the content item’s attachments field. Use attachmentUrl to obtain the URL components for each file:

{
  guillotine(project: "myproject", branch: "master") {
    get(key: "/articles/report") {
      attachments {
        name
        mimeType
        size
        attachmentUrl(download: true) {
          path
          queryString
        }
      }
    }
  }
}
The data.guillotine.get object for an item with one attachment
{
  "attachments": [
    {
      "name": "document.pdf",
      "mimeType": "application/pdf",
      "size": 238764,
      "attachmentUrl": {
        "path": "/media:attachment/myproject/content-id:fingerprint/document.pdf",
        "queryString": "?download"
      }
    }
  ]
}

The content ID and fingerprint above are illustrative. Build the download address by concatenating your public API or media base URL, path and queryString. On a local sandbox the base is http://localhost:8080/api. See Attachment API for delivery behavior and Guillotine’s URL documentation for client handling.


Contents

Contents