Как мне разрешить этот конфликт между двумя функциональными модулями?

У меня есть два типа контента с различными меню, представлениями, меню и т. Д., Которые я упаковал в виде двух пользовательских модулей Feature. Оба типа контента используют таксономию и используют несколько одинаковых полей в базе данных. Когда я загружаю эти функциональные модули на новом сайте, они показывают конфликты друг с другом по этим общим полям и словарному запасу, и я не уверен, что было бы наилучшим способом разрешения конфликта.

Хотя функциональные модули предназначены для совместной работы, они не обязательно должны присутствовать на одном сайте. Каждый из них также может работать с другими функциями. Они оба используют таксономию и поля для фильтрации представлений и т. Д., Поэтому имеет смысл включить каждый из этих компонентов в определение своей функции. Нужно ли мне:

Удалить поля и таксономию из одного из модулей и объявить зависимость для другого? Это нежелательно, так как каждый может работать без другого.
Сделайте две версии функций, одну для самостоятельного использования и одну для совместной работы.
Определить поля и таксономию как отдельную функцию?
Игнорировать конфликт и включить модули? (Если я это сделаю, они оба будут делить поле?)
Другое решение?

Я еще не проверял это, но будет ли отключение или удаление одного из двух модулей Feature удалять поля из базы данных, даже если это требуется для другого модуля?

features

— штучный камень
источник

Ответы:

Создайте третий компонент, определяющий компоненты (*), используемые двумя другими независимыми компонентами.

В двух других функциях удалите компоненты, на которые теперь претендует третий компонент, и вместо этого перечислите третий компонент как зависимость.

$echo 'digraph G {label = "График зависимостей"; структурный [ярлык = "Структурная особенность \ n (Поля, Таксономия)"]; "Feature A \ n (Content Type)" -> структурный; "Feature B \ n (Content Type)" -> структурный; };» | dot -Tpng> dependency.png$

(*) В Функциях для Drupal 7, однако, эта функция еще не зафиксирована - см. Http://drupal.org/node/1064472 и помогите просмотреть предложенный код там. - Этот патч был добавлен в Особенности 7.x-2.x.

— smokris
источник

Да, это бы сработало. Хотя если это то, что заставляет пользователей делать это, то это не элегантное решение. Возможности предоставляют возможность упаковать Особенность, а затем не позволяют нам сделать это полностью. Общие поля между отдельными функциональными модулями не должны быть проблемой. Спасибо

— Ашлар

@Ashlar: Но что, если определения полей в каждой из первых двух функций различаются - как будут разрешаться конфликтующие определения? Кроме того, в целом наличие нескольких достоверных определений одной и той же информации проблематично . Совместное использование полей не является проблемой, но наличие нескольких прав, определяющих, что это за поля, является проблемой.

— Smokris

Нет, я говорю , что вы должны определить поле один раз (и , таким образом , определить возможные значения поля в один раз ) в структурном Feature - и ссылки , что поле в каждом из функций типа контента. (Ack ... Я только что понял, что то, что я предложил, предполагает применение патча на drupal.org/node/1064472 , о котором я забыл упомянуть. Отредактированный ответ.)

— smokris

Спасибо, смокрис. Ссылка была очень полезной. У меня было неверное предположение о том, как обрабатывалось поле / экземпляр. Ваш ответ теперь имеет смысл для меня, и ссылка на патч спасет меня от выдергивания волос :)

— Ashlar

Упомянутый патч для D7 Features теперь добавлен в dev drupal.org/node/1064472#comment-7235792

— danbohea

Это решение отлично сработало для меня, гораздо надежнее экспортировать на различные сайты, чем создавать третью функцию, которая создала бы потерянные поля на другом не связанном сайте.

http://drupal.org/node/1698290

— frazras
источник

Одно из решений, которое сработало для меня, заключалось в том, чтобы объединить две функции в одну большую функцию. Это решило конфликты.

— Sokratis
источник