Як перенести вміст блоку з розробника на виробничий сайт?

Нарешті я серйозно почав дивитися на Drupal 8 і мене особливо цікавить управління конфігурацією. Я натрапив на щось, що може бути трохи проблематичним, і це стосується вмісту користувацького блоку.

Я бачу, що система управління конфігурацією здатна експортувати конфігурацію блоку - область, тему, вагу, видимість тощо. Однак фактичний вміст блоку не зустрічається при експорті конфігурації, що є розумним і зрозумілим.

При імпорті конфігурації блоку на виробничий сайт, здається, відбувається створення блокової конфігурації та розміщення повідомлення про зберігання, що повідомляє про те, що блок розбитий або відсутній. Очевидно, що вміст блоку не існує на виробничому сервері.

Як можна перенести користувацькі блоки з сервера розробки / постановки на виробничий сервер? Я усвідомлюю, що блоки в Drupal 8 - це супутні об'єкти, такі як вузли, і тому їх потрібно буде перенести так само, і я розумію, що в Drupal 8 є міграційний API, але це, здається, створено для міграції вмісту з сайтів Drupal 6 та 7 на Drupal 8 на відміну від Drupal 8 на сайтах Drupal 8.

Ця проблема спеціально стосується користувацьких блоків, як блоків, генерованих іншими модулями, такими як Views, як очевидно, буде переміщуватися через конфігурацію.

Ще одна відповідь, яку я не бачив тут, - це використовувати модуль простого блоку , який майже ідентичний налаштуванню ядра "Спеціальний блок", але замість того, щоб мати дивний гібрид контенту + конфігурація, у вас є всі налаштування та вміст блоку. зберігається в конфігурації, яку можна чисто експортувати та імпортувати.

Дивіться, для подальшого обговорення в ядрі Drupal 8: Спеціальні блоки не можна належним чином експортувати та імпортувати .

Я щойно опублікував внесений модуль, який вирішує це. По суті, модуль надає тип блоку на основі конфігурації (фіксований блок), який обертає користувацький блок (блок вмісту). Якщо блоку вмісту не існує, він створюється зі змістом за замовчуванням або порожнім, якщо вміст за замовчуванням не встановлено. Все робиться через інтерфейс користувача, не потрібні спеціальні файли чи спеціальний модуль.

Я назвав його вмістом виправленого блоку, і він публікується за адресою:

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

Інший підхід до збереження контенту, який додається як частина розробки, також підштовхується до використання, - використовувати модуль контенту за замовчуванням для експорту вмісту. Він створений для експорту контенту в папку "вміст" профілю установки, а потім модуль, якщо він включений, автоматично приводить вміст, коли сайт встановлений, але також можливо імпортувати вміст по одному елементу за раз , наприклад, у гачку оновлення, із наведеним нижче кодом у example.install або 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();
}

Експортуйте спеціальний блок з ідентифікатором 8:

drush dcer block_content 8

(Якщо ви не встановите шлях свого профілю в налаштуваннях Drush, вам доведеться вказати його вище.)

І використовуйте отриманий експорт у файлі example.install таким чином:

<?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

Я не впевнений, що я бачу якісь сильні переваги синхронізації блокових конфігурацій серед кількох середовищ, оскільки блоки настільки переплетені із вмістом.

Причиною цього є те, що з файлів yml створюється новий блок, який не має заголовка / тіла (вмісту) і тому дає повідомлення "зламане / відсутнє".

Ви можете спробувати зробити UUID (якщо ви хочете зробити блок в обох місцях - переконайтеся, що ім’я машини збігається ...) у вашій таблиці block_content розвитку відповідає тому, що уїд у вас у виробництві (в інших відносинах, здається, використовується сутність ід). Тоді, коли ви робите синхронізацію конфігурації, ви можете побачити "Перегляд відмінностей" у файлах yml і, можливо, побачити, що ще потрібно змінити на програмі dev, щоб вона відповідала виробничим уюдам і т. Д. Я змусив це працювати, але все-таки зрозумів найпростіше ігнорувати всі ваші блокові конфігурації в коді, якщо ви не пройдете цей процес або не створите для себе якусь синхронізацію блоку бази даних, використовуючи block_content, block_content__body та block_content_field_data.

Це не дуже елегантно, але може дозволити вам зберігати конфігурації блоків у коді. В іншому випадку, якщо ви продовжуєте розгортати блоки з конфігурацією, вони завжди будуть "зламані або відсутні".

Ще одна публікація в блозі пропонує створити спеціальний блок у прямому середовищі, але не розміщувати його. Після синхронізації бази даних з програмою dev, користувацький блок можна налаштувати, конфігурувати експортувати, і оскільки він вже існує в реальному імпорті розміщення.

Маючи ту саму проблему і насправді не є рішенням, лише доповнення: У спільній розробці ми використовуємо поетапний сервер, який витягує з сховища та скидає всю конфігурацію. Це означає, що конфігурація блоку скидається автоматично, ви просто не можете розміщувати блоки, які ви вважаєте "вмістом" безпосередньо на цьому сервері.

Використовувати синхронізування синхронізування конфігурації "drush" легко, одночасно точно знаючи, що ви зробили, і впевнені, що будь-які зміни конфігурацій призначені для розгортання. Але Drupal вирішує для нас, що блоки є конфігурацією (хоча, очевидно, блоковий контент обробляється як вміст). Тож це, здається, порушено дизайном.

За час, який я вважаю, найбільш практичним рішенням буде додати файли yml, що стосуються блоку, до .gitignore.

Я теж не впевнений, але якщо ви не знайшли жодного рішення, ви можете подивитися цей модуль https://www.drupal.org/project/deploy . Чесно кажучи, я не пам’ятаю, можна розгортати поштові блоки від DEV до PROD чи ні.

Я думаю, що найкращим способом вирішити це було б:

• налаштувати псевдонім для різних версій вашого сайту
• використовувати команди drush, наприклад:
  • drush rsync
  • drush sql-sync

Це те, що я зазвичай бачу, як люди користуються, і я особисто використовую. Але він синхронізує всю базу даних порівняно з лише вмістом блоку.

Будь ласка, майте руки на модулі синхронізації структури .

Синхронізація структури забезпечує команди Drush та екрани інтерфейсу адміністратора для синхронізації вмісту, який також може вважатися конфігурацією. Включаючи елементи меню, спеціальні блоки та умови таксономії.

Кроки:

1. Перейдіть до синхронізації структури.
2. Перейдіть на вкладку Блоки.
3. Експорт.
4. Ваші конфігурації та вміст буде експортовано в папку конфігурації.
5. Перенесіть конфігурації на інші сайти та імпортуйте.
6. Перейдіть до синхронізації структури та натисніть на імпорт.
7. Зроблено