Comment migrer le contenu d'un bloc d'un développeur vers un site de production?

J'ai enfin commencé à regarder sérieusement Drupal 8 et je suis particulièrement intéressé par la gestion de la configuration. J'ai rencontré quelque chose qui pourrait être un peu problématique et qui concerne le contenu de bloc personnalisé.

Je peux voir que le système de gestion de configuration est capable d'exporter la configuration des blocs - région, thème, poids, visibilité, etc. mais le contenu réel des blocs ne se retrouve pas dans l'exportation de configuration, ce qui est raisonnable et compréhensible.

Lors de l'importation de cette configuration de bloc vers un site de production, ce qui semble se produire est que la configuration de bloc est créée et qu'un message d'attente est mis en place, signalant que le bloc est cassé ou manquant. Évidemment, le contenu du bloc n'existe pas sur le serveur de production.

Comment migrer des blocs personnalisés d'un serveur de développement / de transfert vers un serveur de production? Je me rends compte que les blocs dans Drupal 8 sont des entités modifiables comme les nœuds et devront donc être migrés de la même manière et je comprends qu'il existe une API Migrate dans Drupal 8 mais cela semble être conçu pour migrer le contenu des sites Drupal 6 et 7 vers Drupal 8 par opposition aux sites Drupal 8 à Drupal 8.

Ce problème concerne spécifiquement les blocs personnalisés car les blocs générés par d'autres modules tels que les vues migreront évidemment en tant que configuration.

Une autre réponse que je n'ai pas vue mentionnée ici est d'utiliser le module Simple Block , qui est à peu près identique à la configuration `` Bloc personnalisé '' du noyau, mais au lieu d'avoir un hybride étrange de contenu + config, vous avez tous les paramètres et le contenu du bloc stocké dans la configuration, qui peut être exporté et importé proprement.

Voir, pour plus de détails dans Drupal 8 core: les blocs personnalisés ne peuvent pas être correctement exportés et importés .

Je viens de publier un module contribué qui résout ce problème. Essentiellement, le module fournit un type de bloc basé sur la configuration (le bloc fixe) qui enveloppe un bloc personnalisé (le bloc de contenu). Si le bloc de contenu n'existe pas, il est créé avec un contenu par défaut ou vide si aucun contenu par défaut n'a été défini. Tout se fait via l'interface utilisateur, aucun fichier spécial ou module personnalisé n'est nécessaire.

Je l'ai nommé Contenu de bloc fixe et il est publié sur:

https://www.drupal.org/project/fixed_block_content

Une autre approche pour conserver le contenu ajouté dans le cadre du développement également poussé à vivre consiste à utiliser le module Contenu par défaut pour exporter le contenu. Il est conçu pour que le contenu soit exporté vers le dossier `` contenu '' d'un profil d'installation, puis le module, s'il est activé, apporte automatiquement le contenu lorsque le site est installé, mais il est également possible d'importer le contenu un élément à la fois , comme dans un hook de mise à jour, avec le code ci-dessous dans votre example.install ou example.profile:

<?php
/**
* Import a piece of content exported by default content module.
*/
function example_import_default_content($path_to_content_json) {
  list($entity_type_id, $filename) = explode('/', $path_to_content_json);
  $p = drupal_get_path('profile', 'guts');
  $encoded_content = file_get_contents($p . '/content/' . $path_to_content_json);
  $serializer = \Drupal::service('serializer');
  $content = $serializer->decode($encoded_content, 'hal_json');
  global $base_url;
  $url = $base_url . base_path();
  $content['_links']['type']['href'] = str_replace('http://drupal.org/', $url, $content['_links']['type']['href']);
  $contents = $serializer->encode($content, 'hal_json');
  $class = 'Drupal\\' . $entity_type_id . '\Entity\\' . str_replace(' ', '', ucwords(str_replace('_', ' ', $entity_type_id)));
  $entity = $serializer->deserialize($contents, $class, 'hal_json', array('request_method' => 'POST'));
  $entity->enforceIsNew(TRUE);
  $entity->save();
}

Exportez un bloc personnalisé avec un ID de 8:

drush dcer block_content 8

(Si vous ne définissez pas votre chemin de profil dans les paramètres Drush, vous devrez le spécifier ci-dessus.)

Et utilisez l'exportation résultante dans votre fichier example.install comme ceci:

<?php
/**
* Add the footer block content.
*
* Implements hook_update_N().
*/
function example_update_8001() {
  example_import_default_content('block_content/136efd63-021e-42ea-8202-8b97305cc07f.json');
}

http://data.agaric.com/easily-add-content-update-hooks-use-default-content-module-exports-create-content-needs-be-sync-conf

Je ne suis pas sûr de voir les avantages de la synchronisation des configurations de blocs entre plusieurs environnements, car les blocs sont si étroitement liés au contenu.

La raison en est qu'il y a un nouveau bloc en cours de création à partir des fichiers yml qui n'a pas de titre / corps (contenu) et donne donc le message «cassé / manquant».

Vous pouvez essayer de faire en sorte que l'UUID (si vous vouliez faire le bloc aux deux endroits - assurez-vous que le nom de la machine correspond ...) dans votre table de développement block_content correspond à l'uuid que vous avez en production (les autres relations semblent utiliser l'entité id). Ensuite, lorsque vous effectuez une synchronisation de configuration, vous pouvez voir les `` différences de vue '' dans les fichiers yml et éventuellement voir ce que vous devez changer d'autre sur le dev pour le faire correspondre aux uuids de production, etc. Je l'ai fait fonctionner, mais toujours compris il est plus facile d'ignorer toutes vos configurations de bloc dans le code, sauf si vous passez par ce processus ou créez une sorte de synchronisation de bloc de base de données pour vous-même en utilisant block_content, block_content__body et block_content_field_data.

Ce n'est pas très élégant, mais cela pourrait vous permettre de conserver vos configurations de blocs dans le code. Sinon, si vous continuez à déployer des blocs avec config, ils seront toujours «cassés ou manquants».

Un autre article de blog suggère de créer un bloc personnalisé dans un environnement réel sans le placer. Après avoir synchronisé la base de données avec dev, un bloc personnalisé pourrait être configuré, la configuration exportée et comme il existe déjà en direct, l'import est possible.

Avoir le même problème et pas vraiment une solution, seulement des ajouts: dans le développement collaboratif, nous utilisons un serveur de transfert qui extrait du référentiel et réinitialise toute la configuration. Cela signifie que la configuration des blocs est réinitialisée automatiquement, vous ne pouvez pas placer les blocs que vous considérez comme du "contenu" directement sur ce serveur.

Il est facile d'utiliser la synchronisation drush config-export tout en sachant exactement ce que vous avez fait et en étant sûr que toutes les modifications de configuration sont destinées au déploiement. Mais Drupal décide pour nous que les blocs sont des configurations (alors que le contenu des blocs est évidemment traité comme du contenu). Cela semble donc être brisé par la conception.

Pour l'instant, je pense que la solution la plus pratique serait d'ajouter les fichiers yml liés au bloc à .gitignore.

Je ne suis pas sûr aussi, cependant, si vous n'avez trouvé aucune solution, vous pouvez consulter ce module https://www.drupal.org/project/deploy . Franchement, je ne me souviens pas pouvoir déployer des blocs push de DEV vers PROD ou non.

Je pense que la meilleure façon de gérer cela serait de:

• configurer un alias drush pour les différentes versions de votre site
• utilisez des commandes drush comme:
  • drush rsync
  • drush sql-sync

C'est ce que j'utilise habituellement et que j'utilise personnellement. Mais il synchronise la base de données entière par rapport au seul contenu du bloc.

Veuillez mettre la main sur le module Structure Sync .

La synchronisation de structure fournit des commandes Drush et des écrans d'interface d'administration pour synchroniser le contenu qui pourrait également être considéré comme une configuration. Y compris les éléments de menu, les blocs personnalisés et les termes de taxonomie.

Pas:

1. Accédez à la synchronisation de la structure.
2. Accédez à l'onglet Blocs.
3. Exportation.
4. Vos configurations et votre contenu seront exportés dans le dossier de configuration.
5. Transférez les configurations vers d'autres sites et importez-les.
6. Accédez à la synchronisation de la structure et cliquez sur importer.
7. Terminé