The code created in this tutorial is available on GitHub: https://github.com/ezsystems/TweetFieldTypeBundle.
This tutorial covers the creation and development of a custom eZ Publish
Field Types are responsible for:
Storing data, either using the native storage engine mechanisms, or specific means
Validating input data
Making the data searchable (if applicable)
Displaying Fields of this type
Custom Field Types are a very powerful type of extension, since they allow you to hook deep into the content model.
You can find the in-depth documentation about FieldTypes and their best practices. It describes how each component of a FieldType interacts with the various layers of the system, and how to implement those.
This tutorial is aimed at developers who are familiar with eZ Platform and are comfortable with operating in PHP and Symfony2.
Content of the tutorial
This tutorial will demonstrate how to create a Field Type on the example of a Tweet Field Type. It will:
accept Accept as input the URL of a tweet (https://twitter.com/<username>/status/<id>)
fetch Fetch the tweet using the twitter oEmbed API (https://dev.twitter.com/docs/embedded-tweets)
store Store the tweet’s HTML & author URL in a custom database tabledisplay the tweet embed contents and url
Display the tweet's embedded version when displaying the field from a template
About Field Types
They are the most granular building block for content managed by eZ Publish. Quite a few are shipped by default (https://confluence.ez.no/display/EZP/FieldTypes).
They are responsible for:
storing data, either using the native storage engine mechanisms, or specific means
validating input data
making the data searchable (if applicable)
displaying an instance of itself
1. The bundle
FieldTypes, like any other eZ Publish 5 extensions, must be provided as Symfony 2 bundles. This chapter will cover the creation and organization of this bundle.
2. and 3. API
This part will cover the implementation of the eZ Publish API elements required to implement a custom FieldType
Storing data from any FieldType into the Legacy Storage Engine requires that your custom data is mapped to the data model. This part will cover the implemention of the storage converter for the Tweet FieldType.
Whenever a FieldType must store more than the basic primitives the API supports, custom, external storage must be implemented. This part covers how a FieldType can store custom data anywhere, in particular into custom tables in the legacy database.
Read more about Implementing the Legacy Storage Engine Converter.
Displaying a FieldType's data is done through a twig template.
Read more about implementing the FieldType template.