10 июня 2009 в 13:42
Примерно месяца два назад я попал в команду на интересный проект. Сеть сайтов на Друпале. Каждый конечный сайт (мы называем их satellite) имеет свою базу пользователей, свой текст на страницах, свою контактную информацию в блоках, но по функционалу является точной копией сайта "донора" (template website), который вроде как является шаблоном из которого можно очень быстро создать еще один сателлит. Сайты не самые простые, webforms, cck, OG, views, наполеоновские планы по развитию и добавлению нового функционала типа i18n и приема платежей, все как надо. Все бы ничего, но эти изменения с шаблонного сайта надо регулярно переносить на все сателлиты. Понятное дело, что целиком каждый раз убивать базу сателлита и переписывать базой с шаблонного сайта нельзя - надо сохранять юзеров, их комменты, изменения на страницах. Т.е. переносить надо: новые ноды, сеттинги из админки, созданные блоки.
Как бы вы решали такую задачу?
[буду дописывать сюда по мере мыслей]
BTW, ищутся эксперты по Друпалу. Конкретно решать эту задачу, и другие, попроще. Проект интересный, задачи адекватные, общение с ребятами из Acquia, такими гуру как Robert Douglas, Joshua Brauer, соответственно офигенный экспириенс и level up 
Оплата достойная.
Требования:
- php/javascript
- знать Drupal как свои пять пальцев
- умение пользоваться svn
- устный и письменный английский, достаточный чтобы объясняться на нем и понимать других
Комментарии
Недавно поднимал подобный вопрос (одновременно на drupal.org и phpclub.ru) - однозначных и универсальных решений не нашлось. Варианты были примерно такие:
- Patterns или только на пятёрку Autopilot
- использовать SQL менеджеры (EMS или TOAD к примеру) на предмет экспорта-импорта отдельных таблиц и контента (работа полуручная по сути).
- основной вариант: написать скрипт синхронизации (на том же php или perl), который сам будет делать альтеры, апдейты, drop-create отдельных таблиц).
Ну с нодами я бы решал задачу через написание своего модуля, который выгружает ноды определенного типа за определенный период (это как-бы известные данные) в какой нибудь CSV файлек и потом импортировать из него данные на саттелиты через node_save()
А вот админские настройки и блоки, это каг-бы вопрос, поскольку у блоков есть привязка непосредственно к названию темы, да и в админке наверное свои прелести :).
Мы успели попробовать:
FeedAPI
Deploy
Macro
Patterns
рассматривался бегло Domain Access.
В итоге похоже будем останавливаться на Deploy, но он сыроват, и к нему много чего придется дописывать.
Вопросы пошли уже интересные:)
Очень размытое начальное ТЗ.
Но общая идея такая (когда то давно что-то подобное делалось):
На сайте существует 3 типа данных по уровням:
Дальше, все ползёт сверху вниз. Самое страшное (как и везде
- удаление и изменение.
Если система распространения звезда - вполне 2-3 таблицами можно обойтись.
Опять же, без точной привязки не посоветуешь.
Совет: посмотрите идеологию, как живет 1C. Есть платформа, конфигурация и данные.
тз как такового и нет, потому что никто не знает какой классный полезный модуль завтра будет включен на шаблонном сайте, соответственно не зная конечной структуры сайтов ни о каких четких спеках речи не идет, agile dev такскзть ) Сейчас пишется Sync Policy, документ в котором будет указано явно, какие вещи будут регулярно синхронизироваться template -> satellite, а какие на сателлите будут неизменными (некоторые типы нод скорее всего будут обновляться, поэтому тут тоже все не так просто).
Скелет и Настройки - вещь в Друпале достаточно близкая по-моему, различие только в тому что скачанный модуль может быть удален.
Скорее, в drupal скелета как такового практически нет. В основном все таблицы настройки и данные. Скелет - сами поля в таблицах и логика.
Абсолютно нет смысла писать полиси. Сделайте универсальную систему, раз уж берётесь. Зачем жёстко ограничиваться?
Введите себе новые классы понятий(другой ракурс взгляда) для системы в целом и задача будет абсолютно не проблемной.
Вводных не особо много будет и общая логика простая и прозрачная.
Иначе это будет бесконечный поиск глюков и писание патчей.