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 the type
Custom FieldTypes 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.
This tutorial aims at covering the conception and development of a custom eZ Publish 5 FieldType.
We will do this by implementing a Tweet Field Type. It will:
accept as input the URL of a tweet (https://twitter.com/<username>/status/<id>)
fetch the tweet using the twitter oEmbed API (https://dev.twitter.com/docs/embedded-tweets)
store the tweet’s HTML & author URL in a custom database table
display the tweet when displaying the field from a template
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
Read more about Creating the bundle and structuring the bundle.
This part will cover the implementation of the eZ Publish API elements required to implement a custom FieldType
Read more about implementing the API.
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.
Displaying a FieldType's data is done through a twig template.
Read more about implementing the FieldType template.
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.