How to import a unique field set in several migration definitions ?

[franck-grenier]

Hello Kaliop,
first of all, thanks for this great bundle ! So useful !

I have a use case where I must create several content types which all include the same set of content fields.
Moreover, new content types needing this same set will arrive in the future.

So, I would like to write this set's definition only once and then include it in each of my content types.

Is it possible with "ezmigrationbundle" ? How ?

Thanks for your help !

[gggeek]

Hello. Thanks for the support.

I fear that your use case it not covered too well at the moment.
You can have a file which stores reference values, and include it from many migrations. But I am not sure that the codebase allows setting structured data to references, so replicating the set of lines that defines many content fields is not trivial.

Give me some time to find out an acceptable solution...

[gggeek]

ps: not very friendly, but you can do this at the moment:
use a migration event listener to manipulate the migration definitions after they are parsed and before they are executed. You could thus in your custom listener add the 'generic attributes' to the content class definition, after having read them from a separate yaml file

[gggeek]

nb: this is getting easier in version 4.8: you should now be able to define a field structure as reference, and use it for any field definition

[franck-grenier]

Hello,
we achieved it even on 3.6 by creating "custom_fieldsets", for example, in a common_attributes.yml file :

fieldset:
  -
      type: ezstring
      name: Nom
      identifier: name
      required: true
      searchable: true
      info-collector: false
      disable-translation: true
  -
      type: ezstring
      name: Titre affiché
      identifier: displayed_title
      required: false
      searchable: true
      info-collector: false
      disable-translation: false
  -
      type: ezselection
      name: Alignement
      identifier: align
      required: false
      searchable: false
      info-collector: false
      disable-translation: false
      field-settings:
          isMultiple: false
          options:
              0: "Centre"
              1: "Gauche"

Then, in migrations, we call the custom_fieldset :

-
    mode: create
    type: content_type
    content_type_group: reference:widget_1_ou_2_blocs_group_id
    name: Widget 1 ou 2 blocs image/texte
    identifier: widget_1_ou_2_blocs
    name_pattern: <name>_widget
    url_name_pattern: <name>_widget
    is_container: false
    lang: fre-FR
    custom_fieldset: common_attributes

We created a listener which includes the "custom_fieldset" YAML before migrations execution :

services:
    ezwidget.step_executed_listener:
        class: Fiducial\EZWidgetsBundle\Helper\BeforeStepExecutedListener
        tags:
            - { name: kernel.event_listener, event: ez_migration.before_execution, method: beforeStepExecuted }

namespace Fiducial\EZWidgetsBundle\Helper;

use Kaliop\eZMigrationBundle\API\Event\BeforeStepExecutionEvent;
use Kaliop\eZMigrationBundle\API\Value\MigrationStep;
use Symfony\Component\Yaml\Yaml;

class BeforeStepExecutedListener
{
    public function beforeStepExecuted(BeforeStepExecutionEvent $event)
    {
        $oldStep = $event->getStep();
        if(!empty($oldStep->dsl['custom_fieldset'])) {
            $dsl = $oldStep->dsl;
            $ymlFilePath = stristr($oldStep->context['path'], "MigrationVersions/", true) . 'MigrationVersions/custom_fieldset/' . $dsl['custom_fieldset'] . '.yml';
            $data = file_get_contents($ymlFilePath);
            $data = Yaml::parse($data);
            if (!array_key_exists('attributes', $dsl)) {
                $dsl['attributes'] = $data['fieldset'];
            } else {
                $dsl['attributes'] = array_merge($data['fieldset'], $dsl['attributes']);
            }
            unset($dsl['custom_fieldset']);
            $newStep = new MigrationStep(
                $oldStep->type,
                $dsl,
                $oldStep->context
            );
            $event->replaceStep($newStep);
        }
    }
}

I guess you set up almost the same mecanism in 4.8.