Transformations

Before content is published to the Content Cloud, the structure is optimized to simplify working with content as a non-Drupal developer and to optimize content delivery for simplicity and performance.

Most transformations can be customized or disabled for your space upon request.

Type transformation

• Type names are translated to Pascal case, e.g., basic_page becomes BasicPage.

• Type names are based on bundle + type names, e.g., media.image becomes ImageMedia.

• Some types are renamed:

  • Node becomes Content.

  • TaxonomyTerm becomes Term.

  • Block becomes BlockType.

  • BlockContent becomes Block.

  • MenuLinkContent becomes MenuLink.

• Some types are shortened to avoid redundancies.

  • E.g. file.file becomes File instead of FileFile.

    • If you are using custom file bundles, this optimization will be skipped to allow e.g. ImageFile or DocumentFile types.

• Some types are embedded instead of being treated as separate entities. This speeds up content delivery significantly and makes it much easier to use for non-Drupal developers, especially for nested content structures. This affects:

  • Paragraphs

  • Bricks

• The following types are not exported by default as they’re usually not used in custom, non-Drupal apps:

  • Views

  • Redirects

Type semantics

Some of the content is turned into a Content Cloud native type. These native types are assets and tags and they provide additional functionality in the APIs. By default, the following Drupal types are translated:

• Taxonomy Terms are treated as tags.

• Files are treated as assets.

These system types exist next to the original type, so you can still query for taxonomy terms and files as you would normally. They will contain additional sys properties in GraphQL and entry properties in REST:

• tagEntry

• assetEntry

Property transformation

• The field_ prefix is removed unless it leads to a collision with a property name.

• Property names are translated to camel case, e.g., custom_property becomes customProperty.

• All properties are made optional to maximize backwards compatibility (the same recommendation that GraphQL makes).

• Arrays are unwrapped if they only allow one value, e.g., customProperty[0] becomes customProperty.

• Objects are unwrapped if they only allow one property, e.g., customProperty[‘value’] becomes customProperty.

• Unwrapping stacks, so field_custom_property[0][‘value’] becomes customProperty.

• Some properties are renamed:

  • GroupContent

    • gid becomes group.

    • entityId becomes entry.

Deletion

The following properties are deleted by default:

• defaultLangcode

• moderationState

• publishedAt

• revisionLogMessage

• revisionLog

• revisionUid

• revisionTimestamp

The following properties are deleted from non-root entities by default:

• draggableviews

• menuItems

Optional

Custom Unique Identifiers

If you want to query for specific, semantic content in your applications, you can assign dedicated IDs to it. Examples include home, privacy-policy, imprint or contact. You can use any 255-character string of letters, numbers, hyphens, and underscores for your custom identifiers.

This works for any type of entry, so you can also use it to query for taxonomy terms that have a specific meaning rather than relying on hard-to-read UUIDs or changing names.

If you want to allow such identifiers, please reach out to our support team to get you started.