Metadata and binary data handlers are configured under ez_io. Below is what the configuration looks like for the default handlers. It declares a metadata handler and a binary data handler, both labeled default. Both handlers are of type flysystem, and use the same Flysystem adapter, labeled default as well.

The 'default' Flysystem adapter's directory is based on your site settings, and will automatically be set to %ezpublish_legacy.root_dir%/$var_dir$/$storage_dir$ (for example: /path/to/ezpublish_legacy/var/ezdemo_site/storage).

eZ Platform uses it as the default way to read and write content in form of binary files. Flysystem can use the local filesystem (this is the default and officially supported configuration), but is also able to read/write to sftp, zip or cloud filesystems (azure, rackspace, S3).

For clustering use we provide a custom metadata handler that stores metadata about your assets in the database. This is done as it is faster than accessing the remote NFS or S3 instance in order to read metadata. For further reading on setting this up, see Clustering.

Unlike image files, files stored in BinaryFile or Media Fields may be restricted to certain User Roles. As such, they are not publicly downloadable from disk, and are instead served by Symfony, using a custom route that runs the necessary checks. This route is automatically generated as the url property for those Field values.

By default, images and binary files referenced by content will be served from the same server as the application, for example /var/ezdemo_site/storage/images/3/6/4/6/6463-1-eng-GB/kidding.png. This is the default semantic configuration:

1
2
3
4
5

ezpublish:system:default:io:url_prefix:"$var_dir$/$storage_dir$"

$var_dir$ and $storage_dir$ are dynamic, SiteAccess-aware settings, and will be replaced by their values in the execution context.

One common use case is to use an optimized nginx to serve images in an optimized way. The example image above could be made available as http://static.example.com/images/3/6/4/6/6463-1-eng-GB/kidding.png by setting up a server that uses ezpublish/ezpublish_legacy/var/ezdemo_site/storage. The configuration would be as follows:

Used to configure the default URL decorator service (ezpublish.core.io.default_url_decorator), used by all binary data handlers to generate the URI of loaded files. It is always interpreted as an absolute URI, meaning that unless it contains a scheme (http://, ftp://), it will be prepended with a '/'.

A UrlDecorator decorates and undecorates a given string (URL). It has two mirror methods: decorate and undecorate.

Two implementations are provided: Prefix, and AbsolutePrefix. They both add a prefix to a URL, but AbsolutePrefix will ensure that unless the prefix is an external URL, the result will be prepended with /.

Three UrlDecorator services are introduced:

ezpublish.core.io.prefix_url_decorator used by the binary data handlers to decorate all URIs sent out by the API. Uses AbsolutePrefix.

ezpublish.core.io.image_fieldtype.legacy_url_decorator used via the UrlRedecorator by various legacy elements (Converter, Storage Gateway, etc.) to generate its internal storage format for URIs. Uses a Prefix, not an AbsolutePrefix, meaning that no leading / is added.

In addition, a UrlRedecorator service, ezpublish.core.io.image_fieldtype.legacy_url_redecorator, uses both decorators above to convert URIs between what is used on the new stack, and what format legacy expects (relative urls from the ezpublish root).

You can configure the storage options for uploading files using semantic configuration.

When a file is uploaded using multi-file upload, it is automatically stored in a Field of a new Content item. This configuration specifies which MIME types will be uploaded as content of which Content Types, using what Field Types. For example: