Синхронизация публикаций на связанных сайтах в Drupal

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

Частный случай. Конкретная реализация этой связки (головной сайт и сайт-спутник) уже практически завершена (остались штрихи по дизайну и наполнению, но это уже не моя забота :) ), это пара сайтов suet-co.ru и suet-motor.ru. Suet-motor.ru содержит ветку товарного каталога по моторам с головного сайта. Цель suet-motor — в привлечении покупателей по тематике «моторы». Он должен содержать несколько статей, посвященных данной тематике и каталог, ссылки из которого ведут на конечные позиции товаров на головном сайте. Там мы можем подробно изучить характеристики найденных на suet-motor товаров и заказать их.

Техника синхронизации.

Обмен данными. Первый вопрос в том как же обмениваться данными между сайтами, оставаясь в рамках движка drupal. Мне пришла идея воспользоваться техникой, которая применяется в drupal в случае ajax запросов. Для каждой стороны был написан модуль, в которых в объявляется hook_menu — зацепка для меню с элементами типа MENU_CALLBACK :

Т.е. создаётся специальная страница, которой можно передавать параметры, а в ответ получать какой то массив данных, обработанный, к примеру, serialize(). Параметры можно передавать, как часть url. Вот как было это сделано у меня. Специальная функция генерировала url из имени команды и массива параметров —

А принимающая сторона, реализующая страницу типа MENU_CALLBACK, обрабатывала запрос следующим образом :

Отложенное выполнение. Давайте посмотрим в какой момент лучше всего производить синхронизацию данных. Так как событие изменения статьи можно перехватить (в hook_form_alter добавляем обработчик $form[#submit] для формы нужного типа публикации ), то это наиболее удобный момент для синхронизации. Но это только на первый взгляд.

Когда мы меняем статью в каталоге на головном сайте, надо изменить её и на сайтах-спутниках. Для этого спутники надо каким то образом оповестить (выполнить запрос ко всем спутникам из какого-то известного списка). При этом можно либо помнить, кто из спутников запрашивал определенные статьи, а можно оповещать все спутники, и они сами должны решать — нужно ли запрашивать изменившуюся статью или нет.

Процесс редактирования часто связан с многократным сохранением статьи. Если каждый раз немедленно оповещать всех спутников, а они в свою очередь начнут синхронизироваться, то выйдет не очень хорошая ситуация с использованием ресурсов веб-сервера.

Эти рассуждения привели меня к следующему решению. При сохранении статей на головном сайте, я добавляю запись в специальную очередь-таблицу обновлений с помощью  sql-команды replace. Записи имеют код статьи (node-id или nid) в качестве ключа, и потому новая команда для каждой ноды не добавляет строк. А сама команда может быть или delete или insert соответственно для удаления статьи и обновления/добавления.

После того как команда попадает в очередь, она там хранится до вызова cron. Обработчик (hook_cron) в моём модуле грузит весь текущий список команд и оповещает сайты-спутники. Те в свою очередь не бросаются сразу выполнять запросы на обновление статей, а тоже складывают команды, прошедшие проверку в уже собственные очереди команд. И, как вы уже поняли, очереди команд на спутниках выполняются также во время уже собственной зацепки hook_cron. Лучше запуски cron для спутников и головного сайта разнести по времени, чтобы они не накладывались.

Написать комментарий

Мало букафф? Читайте есчо !

Contact Form 7 - добавим галочку на согласие по обработке персональных данных

Июль 21, 2017 г.

Вступившие в силу поправки (с 01.07.2017) федерального закона ФЗ 152 "О защите персональных данных" требуют, чтобы владельцы сайтов информировали пользователя ...

Читать

Когда jQuery.find может не работать

Декабрь 8, 2012 г.

Обычно, "проблема" возникает с данными, получаемыми через асинхронные запросы (ajax-запрос). Вы пытаетесь выполнить jQuery.find() для полученных данных, а функция возвращает пустой объект. В примере ниже, мы пытаемся извлечь содержимое HTML контейнера ...

Читать

 

Комментарии к «Синхронизация публикаций на связанных сайтах в Drupal»

Понравилась статья? Есть вопросы? - пишите в комментариях.



Комментарий: