Как стать автором
Обновить

Комментарии 12

Как опытный пользователь мультисайтинга, использую немного другую организацию каталогов.

Каждый домен смотрит на отдельную папку на сервере, из которой уже идут ссылки на папку со стабильной версией, за исключением папок files и sites и файлов .htaccess и robots.txt. Папочку site.ru/sites/modules линкуем куда удобно, тут будут храниться модули (можно вынести из папки drupal-stable, чтобы проще обновляться) и рядом создаём папку с настройками сайта site.ru/ (ну и папку default).

Обновляюсь я просто: распаковываю рядом последнюю версию друпала и делаю пару команд mv.
mv drupal-stable drupal-backup
mv drupal-6.15 drupal-stable
+ в новую версию линкую папку с модулями.

Готово, осталось только все update.php запустить.

В итоге более гибкую и удобную конфигурацию получаем, плюсы:
— не нужно сторонних модулей для управления файлом robots.txt, фалов для верификации google webmaster tools и я.вебмасетр;
— cвоя папка files.

По этой схеме недавно Андрей записал видеоподкаст, советую.
Я давно камлаю и бью в бубен, и думаю, почему чертовы разработчики Jooml'ы, Drupal'a и других попсовых ЦМС не введут наконец автоапдейт в стандартную комплектацию?
В Друпале 7 обещали. Главное, чтоб автоапдейт модулей не забыли при этом.
Апдейт аптейду рознь. Одно дело когда вопросы безопасности затронуты, другое — когда расширение функционала, третье, когда реорганизация данных. Ситуации различны и не всегда одинаково хороши. И все бы ничего, если бы Вы не разрабатывали свои модули на основе других. Я не говорю про переопределение или дополнение функций, я говорю про использование данных, причем апи модуля часто не позволяет вам сделать то, что вам требуется. И подобного рода автоапдейт может наломать дров.
А обновление вручную гарантирует, что вы не пропустите такие косяки. По крайней мере точно бекап сделает и в момент апдейта не будете спать… В общем — возможно это дело вкуса, но лично я предпочитаю контролировать то, что творится с сайтом и излишняя безопасность не бывает вредной.
Автоапдейт чего ядра? Это похоже на рулетку(а вдруг у вас особенности свои). Да и процесс, иногда требует телодвижений.
Модули и переводы можно обновлять автоматом, но для модулей, опять могут быть ньюансы. А рид.ми мало кто читать любит…
capistrano. Ничего, что так лаконично?
Использовать Руби для деплоя Друпала? Мне одному кажется, что это несколько не универсально, поскольку большое количество сайтов на Друпале крутятся на машинах без Руби? :)
а какая разница на чем писать?
Зачем плодить сущности? У вас, получается, используются:
PHP (плюс апач и мускул, наверное) — сам Друпал
шелл (плюс вгет и тар) — для закачки и разархивации
Ruby — один скриптик

Первые два пункта практически стандартны для любого сервера, на котором крутится Друпал, а вот третий… По-моему, логично его написать или под шелл, или на пехепе, раз уж решили с миром поделиться :)
есть руби — пишу на руби. хостинг не мой.
Интересное сочетание «Простая схема» + 3 слова, отсутствующих в русском языке…
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории