Создание модуля рассылки Drupal для работы со статьями рассылки

Question

Мы создаем модуль для генерации HTML для почтовых рассылок. Мы рассмотрели возможность использования нескольких других модулей (SimpleNews, MailChimp и др.), Но из-за различных требований нам будет проще и лучше создать собственное решение.

Будучи новым разработчиком Drupal, я немного беспокоюсь о том, чтобы справиться с этим "не Drupal" способом. При этом мой план состоит в том, чтобы установить словарь с информационными бюллетенями в качестве термина и фактическими информационными бюллетенями в качестве подусловий, например, так:

Newsletters  (term)
  - Newsletter A (sub-term)
  - Newsletter B (sub-term)

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

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

Newsletters  (term)
  - Newsletter A (sub-term)
    - Issue - 2010-03-01
    - Issue - 2010-03-02
  - Newsletter B (sub-term)
    - Issue - 2010-03-01
    - Issue - 2010-03-08

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

Итак, вопрос в том, есть ли лучший способ для обработки этой структуры? Это Drupal-подобное решение?

Answer 1

Я думаю, что вы определенно думаете о Drupal-Like, тем более что вы думаете об использовании таксономии для классификации своих информационных бюллетеней.

Я думаю, что ваш "Issue - 2010-03-01" на самом деле будет узлом, а не термином. (Если вы не планируете создавать несколько узлов статьи для ссылки на один "выпуск")

Проверьте модуль: http://drupal.org/project/nat (NAT - автоматический термин узла), который управляет отношениями между узлами и таксономией. С помощью этого модуля вы просто создадите новый узел для каждого информационного бюллетеня (подслов). Это автоматически создаст новый термин для вас. Затем вы создадите новый узел Issue, в котором вы выберете категорию "Newsletter", которую хотите опубликовать в этом бюллетене.

Возможно, вы сможете использовать модуль регистрации (или даже флаговый модуль), чтобы позволить пользователям регистрироваться, чтобы присоединиться к узлам вашей рассылки. ( http://drupal.org/project/signup)

Answer 2

Мне интересно, почему пользователи должны сначала создавать узел типа новостной рассылки, когда существует тип узла для проблем? Какова цель наличия второго типа узла?

Что касается вашей иерархии таксономии, вы почти на пути к Drupal. Я бы не стал создавать термин "Newsletters" (пока не вижу смысла), но создал бы словарь "Newsletters". В этом словаре я бы создал термины первого уровня, описывающие различные доступные информационные бюллетени (например, "Информационный бюллетень А").

Затем вы связываете словарь "Информационные бюллетени" с типом контента "проблема".

Как правильно указал xkingpin, NAT ( http://drupal.org/project/nat) будет вашим предпочтительным модулем, поэтому установите его и настройте новые параметры для типа контента "проблема" (т. Е. Связывание термина вопроса),

Затем вы используете тип узла проблемы для создания проблем (я предполагаю, что все информационные бюллетени имеют одинаковый тип контента). После выбора таксономии вы просто выбираете правильный термин, к которому относится этот выпуск (например, "Бюллетень А"). NAT автоматически назначит этот термин для проблемы, а также создаст подусловие для этого термина первого уровня. Имя подтерма будет соответствовать названию вашей проблемы, поэтому вы можете просто назвать его "Проблема № 1 - 2010-03-01", чтобы создать подслово под названием "Проблема № 1 - 2010-03-01".

При просмотре узла проблемы ему будут назначены два термина ("Информационный бюллетень А", "Выпуск № 1 - 2010-03-01"). Любая статья, на которую есть ссылка в проблеме, теперь может быть помечена под термином проблемы. В интерфейсе NAT admin вы можете выбрать, будет ли термин проблемы напрямую связан с узлом проблемы, а не с видом на все узлы, отмеченные одним и тем же термином проблемы (что является поведением по умолчанию для drupal).