RFC: Adding additional properties to media assets

Hi @cgat, thanks for your message, this RFC is just about handling asset meta data, not about replacing asset. We know the problem with stable URI for Assets and Nodes.

I’m currently working on a redirection module for Documents Nodes (see https://jira.neos.io/browse/NEOS-721). If we move the asset storage, to the CR, maybe we can use the some parts of this API to generate redirection to new resource.

I added a project proposal for this topic: Project Proposal: Asset MetaData Handling
@dfeyer I would be thrilled to work on that topic during the sprint in Rosenheim.

I’d join you in Rosenheim to work on this @daniellienert!


@daniellienert Feel free to work on the topic, a first prototype will be nice. Unfortunatlly I don’t know when I arrive at the sprint too much thing to do this month.


I worked on that topic and built a (i think quite promising) prototype. Nothing is carved in stone of course and I appreciate any feedback.

Like discussed earlier, the prototype currently consists of these three parts:


  • Defines DTOs for metadata standards, like EXIF, IPTC or XMP
  • Provides a manager class to handle updated meta data
  • Already maps the DTOs to title / caption of the asset table. Mappings can be provided using eel:


      title: '${asset.title || iptc.documentTitle}'
      caption: '${asset.caption || iptc.caption}'


  • Provides ExtractorAdapters to 3rd party packages and converts the result to the according DTOs
  • An Extractor class that selectes the apropriate ExtractorAdapater by asset type and builds a collection of DTOs
  • A command to extract metaData of existing assets


./flow metadata:extract
No Extractor available for media type application/pdf
17/17 [============================] 100%
Finished extraction.


  • Generates nodes in the root meta
  • Maps the DTOs on specific metaData Node Types
  • Provides FlowQueryOperations to handle meta data

Mapping MetaDataDTOs to nodes
There is a lot of meta data formats out there. Meta data in images for example are stored in three different standards. Some of the standards cover their own domain (eg EXIF for capturing device generated data) but some are overlapping. Therefore a mapping to the storage in neos needs to be flexible. I would suggest to configure a small standard, as it is easily possible to add more properties to the nodes and adjust the mapping. A nodeType definition could look like:

abstract: true
type: string
mapping: ‘${asset.fileName}’

  abstract: true
      type: DateTime
      mapping: '${iptc.creationDate}'
      type: string
      mapping: '${iptc.authorByLine}'

  abstract: true
      type: string
      mapping: '${exif.Model}'

    'Neos.MetaData:Asset': true
    'Neos.MetaData:Exif': true
    'Neos.MetaData:Iptc': true

NodeData Table after import

Typoscript Interface

Get the meta data of the property image:

prototype(TYPO3.Neos.NodeTypes:Image) {
	metaData = ${q(node).metaData('image').properties}

Select Images by their MetaData:

assets = ${q(meta).find('[instanceof Neos.MetaData:Image][authorByline*="Daniel Lienert"]').getAssets()}

(currently needs a hack in the TypoScriptView to work, see How to extend the Node Context to query an additional root node)

I am no confident with the API yet - so any ideas welcome.

I haven’t added the packages to composer yet, as I hope to move them to the neos account soon. If you want to try it out - here are the packages:

What is missing yet is the storage of the extracted tags
A next step could be the kickstarting of the Neos.MetaData.Browser package with an interface to edit the meta data. I also am curious to see what filters are possible with the meta data.

I hope to decide on this as a project for the neos teams soon :slight_smile:

@daniellienert Thanks a lots for the prototype look promising and love the current code a lots. I’m in holiday between tomorrow and for 10 days. So no times to test this carefully, I will test it when I’m back at the office.