eZ Platform Discussions

We are opensourcing our Netgen Remote Media Bundle for eZ Platform with Cloudinary support


#1

Cloudinary is a media management platform in the cloud. Even though it does support other file formats (you can easily deliver, for example, .pdf files from Cloudinary), its biggest strength is image management. It offers cloud storage, transformation prcessing and serves images via Akamai’s CDN.

Netgen Remote Media Bundle bundle fully implements the field type for eZ Platform as well as the legacy part for the administration interface. The main features are, obviously, the support for remote resources and the image cropping editor, which is integrated into the content editing interface.

Read more: https://www.netgenlabs.com/Blog/We-are-releasing-our-Netgen-Remote-Media-for-eZ-Platform-with-Cloudinary-support


#2

Great!
Didn’t look into details, complementary of @Plopix’s Cloudinary plugin?
Do you have ideas when you’ll start to move this to version 2?
I think the platform is probably ready for that now, and we’d love to try it on the beta :slight_smile:


#3

AFAIK, Novactive bundle uses Cloudinary for transformations only, the original media file is still handled with eZ. @Plopix correct me if I am wring :slight_smile:

We will be happy to implement it on eZ Platform UI v2 as soon as we can. A tutorial/docs on how to implement custom field type interface would be helpful :wink:


#4

We’re working on doc. Afaik, there is a draft available that should make it simple for you, may be @sylvain.guittard can share a bit about that?


#5

Hi @gof and @rolandbenedetti!

Indeed there is a draft for creating a Field Type in eZ Platform v2. We will publish the official documentation for v2.

In the meantime, you can follow those steps:

Adding FieldTypes

Implementing new FieldTypes in v2 isn’t much different from v1. You should still follow our documentation: https://doc.ezplatform.com/en/1.7/api/field_type_api_and_best_practices/ which will tell you how to create a FieldType which can display the value.

The biggest difference is the approach to creating content editing template for new FieldTypes. With v2 we dismissed YUI and frontend approach. FieldTypes are now integrated with Symfony forms.

1. Create FormMapper

Your mapper has to implement 2 interfaces:

  • EzSystems\RepositoryForms\FieldType\Mapper\FieldValueFormMapperInterface to provide editing support
  • EzSystems\RepositoryForms\FieldType\FieldDefinitionFormMapperInterface to provide FieldType definition editing support

1.1. FieldValueFormMapperInterface

FieldValueFormMapperInterface::mapFieldValueForm method accepts 2 arguments: FormInterface $fieldForm and FieldData $data. You have to add your form type to the content editing form. Refer to the listing below showing how ezboolean injects the form:

public function mapFieldValueForm(FormInterface $fieldForm, FieldData $data)
{
    $fieldDefinition = $data->fieldDefinition;
    $formConfig = $fieldForm->getConfig();

    $fieldForm
        ->add(
            $formConfig->getFormFactory()->createBuilder()
                ->create(
                    'value',
                    CheckboxFieldType::class,
                    [
                        'required' => $fieldDefinition->isRequired,
                        'label' => $fieldDefinition->getName(
                        $formConfig->getOption('languageCode')
                        ),
                    ]
                )
                ->setAutoInitialize(false)
                ->getForm()
        );
}

Probably the most important thing is to remember that your type has to be called value. In the example, CheckboxFieldType::class is used but you can use standard Symfony form type instead. It’s a good practice to encapsulate fields with custom types as it allows easier templating.
Type has to be compatible with your FieldType’s eZ\Publish\Core\FieldType\Value implementation. You can use a DataTransformer to achieve that or just assure correct property and form field names.

1.2. FieldDefinitionFormMapperInterface

Providing definition editing support is almost identicial to creating content editing support. The only difference are field names:

public function mapFieldDefinitionForm(FormInterface $fieldDefinitionForm, FieldDefinitionData $data)
{
    $fieldDefinitionForm
        ->add(
            'isMultiple',
            CheckboxType::class, [
                'required' => false,
                'property_path' => 'fieldSettings[isMultiple]',
                'label' => 'field_definition.ezcountry.is_multiple',
            ]
        )
        ->add(
            // Creating from FormBuilder as we need to add a DataTransformer.
            $fieldDefinitionForm->getConfig()->getFormFactory()->createBuilder()
                ->create(
                    'defaultValue',
                    CountryFieldType::class, [
                        'choices_as_values' => true,
                        'multiple' => true,
                        'expanded' => false,
                        'required' => false,
                        'label' => 'field_definition.ezcountry.default_value',
                    ]
                )
                // Deactivate auto-initialize as we're not on the root form.
                ->setAutoInitialize(false)->getForm()
        );
}

Use names corresponding to the keys used in FieldType’s eZ\Publish\SPI\FieldType\FieldType::$settingsSchema implementation. Special key defaultValue allows you to specify a field for setting default value assigned during content editing.

1.3. Service definition

The next step is to provide service definition for previously created FormMapper:

EzSystems\RepositoryForms\FieldType\Mapper\CheckboxFormMapper:
    tags:
        - { name: ez.fieldFormMapper.definition, fieldType: ezboolean }
        - { name: ez.fieldFormMapper.value, fieldType: ezboolean }

As you can see in the example above it’s necessary to tag services using ez.fieldFormMapper.value when providing content editing support (FieldValueFormMapperInterface interface) and ez.fieldFormMapper.definition when providing FieldType definition editing support (FieldDefinitionFormMapperInterface interface). fieldType key has to correspond to the name of your fieldtype.

1.4. Templating

At this point you are able to edit FieldType value but in some cases you might be interested in providing customized form theme. The procedure is the same as described in Symfony’s documentation.
We encourage to use custom form types for encapsulation as this makes templating easier by providing twig block name. All eZ Platform fieldtypes are implemented with this approach. In that case overriding form theme is as easy as:

{% block my_fieldtype_widget %}
    Hello world!
    {{ block('form_widget') }}
{% endblock %}

1.5. More examples

For best practices please refer directly to our codebase:

(Thanks Maciej Kobus for this draft)


#6

yes @gof you are right.

Which allows it to be installed right now without doing/migrating anything.
Yours seems more developed but they are very similar.

You are providing a new FieldType though right? We are not sure we should do that (even more now your plugin provides it)

I would have loved it to be transparent. Using the ezimage field type. Somehow Cloudinary could be a cluster backend for images but also videos and files. (like S3)

We should sync on our work… that is kind of sad we did twice the work.

Nice job guys.


#7

Hey Sylvain,

Thanks for the input, I am sure @emodric will be the first to jump on this for the Tags Bundle :slight_smile:


#8

Well, it is a bit bad we are partially duplicating the work, but on the other side its good to have more options. We are doing it with a custom field type. This brings the need to migrate images etc. in which case your solution sounds easier to use.

We opted for full custom field type because of several reasons:

  • we don’t need to store anything locally, the original is also stored on Cloudinary. We that we can aim for a storage-less local installation to simplify devops
  • we can implement features that are completely new, like cropping for particular image alias. Maybe you can do this with the native image field but then it sounds you need to customize it anyway :slight_smile:
  • due to more admin interfaces we need to support, it made more sense to make it custom
  • we also aim for supporting videos which already exists in Cloudinary but will get big improvements quite soon. Again, custom field made more sense

All this might not be needed on some projects, in which case it could be simpler to just plugin your bundle :slight_smile:


#9

I will tackle the field type for eZ Platform UI for Tags Bundle, yes, but it could take some time seing how frontend work done for eZ Platform UI v1 cannot be reused, at least for content fields.

For now, admin interface for Tags Bundle is integrated into eZ Platform Admin UI v2.


#10

I already shared this un-official documentation with @emodric, hopping he will find time to implement the support of eZ Tags on v2 :wink:


#11

For those interested in Tags Bundle progress, I’ve posted here, in order to keep this thread Remote Media Bundle specific:


#12

Related post on BusinessWire: https://www.businesswire.com/news/home/20180306006040/en/Cloudinary-Delivers-Seamless-Image-Video-Management-eZ