Roel Sint edited this page Jul 22, 2013 · 10 revisions


This is a page for discussing a new SymfonyCmfMediaBundle, see!topic/symfony-cmf-devs/wM-YuOFZhKU


Goal: storing and editing (=uploading and/or metadata) any media (images, binary documents like pdf, embedded movies, uploaded movies, mp3s, whatever) and provide a generic base of common interfaces and models that allow the user to build media management solutions for a CMS.

Scope: the implementation is VERY minimalistic and is focused on images and download files, going any further is duplicating the SonataMediaBundle.

This can be achieved providing:

  • base documents for a simple model
  • base FormTypes for the simple model
  • a download controller for file downloads
  • and handlers for common processes related to the storage layer

It can also provide adapters, the phpcr-odm part, for integrating:

  • media browsers (elFinder, ckFinder, MceFileManager, whatever)
  • image manipulation (Imagine, LiipImagineBundle)


Use interfaces to define functionality and allow handlers to process the functionality depending on the interfaces, also rendering can use the interfaces (example: display a thumbnail or a placeholder in an admin list).

We should either refactor parts out of SonataMediaBundle or at the very least make sure to name methods the same as it does, wherever we do the same things:

Fields with the * are required to have a non-empty content, others may be empty strings resp. null.


The base is a MediaInterface, it contains:

  • id* (or uuid): (required) to identify the media
  • name*: used as internal reference for the user, can be the filename
  • description or legend or caption
  • getImage: an image could just do the same as when requesting binary content, but the embedded video would provide their preview then
  • hasImage: see if there is an image
  • metadata: additional information stored in a hashmap (key-value array)
  • copyright
  • author
  • created
  • updated


  • size
  • mime type
  • extension

BinaryInterface extends FileInterface

  • binaryContent a php stream of media data

ImageInterface extends FileInterface (impl must extend either binary or filesystem i.)

  • width 0 for unknown
  • height 0 for unknown

NOTE: model classes may implement PublishWorkflowInterface from core. The default models provided in this bundle must implement it.

NOTE: if i have a pdf with a preview image, i have to model that in my model by having a preview field that is an ImageInterface and a document field that is BinaryInterface.

Archived Interfaces (out-of-scope)

FileSystemInterface extends FileInterface

  • path a filesystem path to the media data file


  • duration

Base class(es)

Using the interfaces leaves it open to use separate classes for each media type or one media class for all. Also how data is persisted can be changed depending on the situation, an example is that a file size can be persisted in the metadata but also can have it's own field. This way a project can start with an Image class and later grow.


Sonata can batch import a cvs of media and use rabbitmq to delay pulling the metadata and preview pictures from youtube, and brew you a coffee while doing that (thats actually true, except for the bit about the coffee). Thomas would be ok to make the sonata admin only a suggestion so you could use the whole media services, form types and stuff without using sonata admin.

Sonata uses one media class and the integration can be done by implementing the interfaces in the PHPCR model of the SonataMediaBundle.

The phpcr model should probably then extend the base model we do in the cmf media bundle, rather than be a copy of it. when we use the interfaces, there is a dependency anyways.

The cmf media bundle will have interfaces that play well with what sonata wants, but we don't start implementing any handlers and whatnot code. so its: if you want to write your own code, you have some common core interfaces and models to use. if you want a framework that does it for you, use sonata media.

The SonataMediaBundle stores all uploaded files in the filesystem.

PS: for the sonata integration, we should probably also check if implementing a PHPCR gaufrette [2] adapter for nt:file / nt:folder nodes would help us. but this is far out of scope for the cmf media bundle.

Embedded vs path reference

The difference between embedded content and a path should be managed. The BinaryInterface and the FileSystemInterface can be used to identify the difference.

Questions (& Answers)

  • What will getImage return? And how will media implementing the FileSystemInterface and BinaryInterface convert to the output?
  • Should MediaInterface::getImage be MediaInterface::getThumbnail? (dantleech)
  • What about download files? see for example - we could provide a generic controller that provides files out of phpcr-odm, but this could be quite a security issue if not properly restricted.
Clone this wiki locally
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.