Ha habido una serie de preguntas surgen en #drupal-migrate en el IRC en los últimos días y semanas sobre cómo manejar la gestión de configuración para las migraciones. Hay varias opciones disponibles, me gustaría sugerir que parece funcionar muy bien para nosotros (y tal vez también). Existen otros enfoques (Ver menciones en el blog de Mike Ryan o migrate_manifest ).

Pero primero un poco sobre config en Drupal 8. La Configuración es proporcionada por módulos y los distintos perfiles proporcionados durante la instalación. Una vez que la configuración se importa en el sitio, entra en el almacenamiento "activo", en el que se puede hacer uso de esta y cambiar usando varias herramientas visuales. ¿Quieres cambiar el nombre del sitio, se visita la página de administración apropiada y la cambiamos allí. Ese valor se guarda en la configuración "activa".

Pero espera, pensaba al igual que 8,1, que ya no seguían siendo artículos de config . No lo son, si se desea migrar todo utilizando el núcleo de Drupal ,de un primer momento, el mecanismo de actualización. A excepción de la más simple de las páginas web, utilizando el enfoque de una sola marcha, simplemente no escala. Por lo que estarás de vuelta en la creación de entidades de configuración de nuevo. Pero esta vez, que son proporcionados por migrate_plus en contrib.

Las entidades de configuración creadas por migrate_plus no son diferentes de otras entidades de configuración creadas para un sitio. Se almacenan en la configuración "activa" y pueden ser exportadas en la "sincronización". Se puede  sacar el máximo provecho de eso y seguir un proceso de 3 pasos para modificar las configuraciones de migración. Una vez que se exporta la configuración, la añadimos a Git y desplegamos al sitio en desarrollo, producción y en vivo utilizando nuestro flujo de trabajo normal de Git.

1. Exportación de configuración ( drush cex -y || drupal config:export )
2. Modificar la configuración a mi gusto
3. Volver a importar la configuración modificada ( drush cim -y || drupal config:import )

Es simple. De ello se desprende la forma de gestionar toda nuestra otra configuración en el sitio. Me gusta porque podemos usar el mismo enfoque en todas partes. Usando mi primer ejemplo, podemos cambiar el nombre del sitio, las exportar eso a las configuraciones. Y de la misma manera, cambiar una entidad config entity.

Es posible que se esté preguntando, pero ¿qué pasa con escribir plugins de proceso personalizado?. Para ello, creamos un módulo personalizado para contener esos plugins de proceso. A continuación, agregue una config dependency en la migración en el módulo personalizado.

Nota adicional: también aprovechamos config_installer . Un perfil de instalación que permite instalar el sitio usando config "sincronización" de un sitio.

Foto de flickr compartida por ikewinski bajo licencia de Creative Commons (BY)