Comments 26
Удивлен, что в друпале раньше такого не было, так как на мой взгляд это required в подобной модульной системе.
P.S. Поправьте в заголовке Drupal PostInstall, пожалуйста.
P.S. Поправьте в заголовке Drupal PostInstall, пожалуйста.
Если я не ошибаюсь, подобную функциональность можно реализовать с помощью профилей (install profile).
Чем не подошли Features + strongarm?
В первую очередь тем что не решают данной конкретной задачи — не дают возможность модулям автоматически отображать и обрабатывать свои страницы настроек после установки.
Не говоря уже о том что в этом модуле 100 строк а только в feautures.module их 9 сотен.
Не говоря уже о том что в этом модуле 100 строк а только в feautures.module их 9 сотен.
90% модулей на 90% проектах имеют 100% идентичные настройки.
Вывести форму настроек на базе Features — не проблема.
Ну а счёт строк… Во вьюсе строки считали?
Не использование модуля Features на проекте среднего уровня и выше это, как минимум, странно.
Вывести форму настроек на базе Features — не проблема.
Ну а счёт строк… Во вьюсе строки считали?
Не использование модуля Features на проекте среднего уровня и выше это, как минимум, странно.
Ну если Ваша статистика верна, это лишь значит что модуль нужен для оставшихся 10% )
Вывести форму настроек после установки через Feautures это ничуть не лучше чем делать это вручную в модуле с помощью хуков. А у меня видно слишком много модулей из тех самых 10% чтобы в каждом делать это хуками.
Как уже было сказано, задача этого модуля — унифицировать процесс и обеспечить последовательность настройки в соответствии с зависимостями.
Вывести форму настроек после установки через Feautures это ничуть не лучше чем делать это вручную в модуле с помощью хуков. А у меня видно слишком много модулей из тех самых 10% чтобы в каждом делать это хуками.
Как уже было сказано, задача этого модуля — унифицировать процесс и обеспечить последовательность настройки в соответствии с зависимостями.
А с какой целью вы используете Features «на проекте среднего уровня и выше»? Много лет работаю с друпалом и пользуюсь Features только для удобного экспорта типов материалов и полей. Откройте мне глаза.
Вы функционал рожаете прямо на продакшене без тестирования? В таком случае вам фичи не нужны, конечно.
Деплой изменений в БД и их ревизионность, которая появляется благодаря фичам, это главный аргумент.
Деплой изменений в БД и их ревизионность, которая появляется благодаря фичам, это главный аргумент.
Я пишу модули, тестирую их, после чего устанавливаю на продакшн. Что делаю не так? Зачем мне фичи?
Я написал выше, сайт состоит не только кода, ещё есть БД и настройки, которые в ней хранятся.
Вы изменяете на Dev вьюху, тип контента, что-то ещё, как вы переносите это на продакшен?
Вы изменяете на Dev вьюху, тип контента, что-то ещё, как вы переносите это на продакшен?
Вьюху я экспортирую, а затем импортирую на продакшен. Тип контента либо создаю сразу на продакшене (согласитесь, там сложно где-то накосячить) либо, иногда пользуюсь фичами (крайне редко). Настройки не обламывает заполнить прямо на продакшене. Всё это быстрее, чем пользоваться фичами в полной мере, плюс получается чище и надежнее.
Надежнее, это как раз таки оформить фичей, к тому же она включает в себя не только одну вьюху, но и экспорты типов контента, настроек, etc.
+ касательно типов контента, у них ещё и зависимости есть, например, требуется filefield или ещё чего.
Потом отправить фичу в систему контроля версий.
Ну и да, в команде ваш стиль будет рождать проблемы
+ касательно типов контента, у них ещё и зависимости есть, например, требуется filefield или ещё чего.
Потом отправить фичу в систему контроля версий.
Ну и да, в команде ваш стиль будет рождать проблемы
Мне кажется, спор зашел в тупик. Вам удобнее пользоваться фичами, мне удобнее пользоваться головой и руками. Если вам нужно изменить тип контента, что вы будете делать? Менять код фичи? Или зайдете в админку и измените нужные поля, потом пересоздадите фичу и перезальете её в SVN? Я правда не понимаю, как этим можно пользоваться в работе, мне кажется, это еще больший геморрой.
Ну и в команде мой подход не создает никаких проблем. Мой принцип разработки: минимум сторонних модулей, максимум функциональности в коде. Все изменения БД должны происходить в install'ах и в update'ах.
Ну и в команде мой подход не создает никаких проблем. Мой принцип разработки: минимум сторонних модулей, максимум функциональности в коде. Все изменения БД должны происходить в install'ах и в update'ах.
Если вы не заметили, спор начали вы, а вам отвечал.
Нравится так работать — работайте, в чём проблема-то? Я не проповедник и даже не иезуит-мессионер.
Если мне нужно изменить тип контента, я изменю его на деве, изменю вьюхи, которые по цепочки за ним пойдут, сделаю апдейт фичи, а далее git и деплой.
Даже если я что-то изменил на продакшене, я сразу вижу, что мне нужно перетянуть на Dev, для сохранения целостности.
Нравится так работать — работайте, в чём проблема-то? Я не проповедник и даже не иезуит-мессионер.
Если мне нужно изменить тип контента, я изменю его на деве, изменю вьюхи, которые по цепочки за ним пойдут, сделаю апдейт фичи, а далее git и деплой.
Даже если я что-то изменил на продакшене, я сразу вижу, что мне нужно перетянуть на Dev, для сохранения целостности.
Вы неправы. Features — необходимость уровня системы контроля версий. Можно применять, как вы говорите «голову и руки» и следить за кодом, но в силу ряда причин эти безголовые и безрукие девелоперы по всему миру тем не менее вовсю используют сисемы контроля версий.
Та же ситуация с Features. Для одного человека можно обойтись и без них. Но проекты среднего уровня и выше предполагают не одного человека в разработке.
Та же ситуация с Features. Для одного человека можно обойтись и без них. Но проекты среднего уровня и выше предполагают не одного человека в разработке.
Тоже не вижу смысла делать костыли, а не пользоваться готовыми и проверенными решениями. Features подходит на 100%
Спасибо за модуль. Судя по описанию, мне этого не хватало. Жду подтверждения и релиза на drupal.org.
Пожалуйста.
Скоро должна проявится DEV версия на drupal.org. Просто DEV версии обновляются раз в 12 часов в отличии от релизов.
Что касается релизной, в принципе DEV версия должна быть стабильной, но я привык пару недель подождать с момента публикации перед выпуском релиза. Мало ли что выплывет.
Скоро должна проявится DEV версия на drupal.org. Просто DEV версии обновляются раз в 12 часов в отличии от релизов.
Что касается релизной, в принципе DEV версия должна быть стабильной, но я привык пару недель подождать с момента публикации перед выпуском релиза. Мало ли что выплывет.
Ну и вопрос не в тему: сколько времени проходит с момента публикации модуля в песочницу до его аппрува? Я три раза бился с выкладыванием модулей, потом плюнул и больше не заморачиваюсь. Уж очень идиотские правила у них.
По разному на самом деле. В моем случае я создал issue 29 октября и после некоторых замечаний и правок получил апрув 2 ноября.
drupal.org/node/1326122
Стандарты действительно жесткие, но в большинстве случаев оправданные. Задачей апрува вообщем-то является не столько заставить следовать беспрекословно этим стандартам, сколько заставить плотно ознакомиться с ними. Думаю после тщательного ознакомления у Вас не должно возникнуть особых вопросов к их логичности и необходимости )
drupal.org/node/1326122
Стандарты действительно жесткие, но в большинстве случаев оправданные. Задачей апрува вообщем-то является не столько заставить следовать беспрекословно этим стандартам, сколько заставить плотно ознакомиться с ними. Думаю после тщательного ознакомления у Вас не должно возникнуть особых вопросов к их логичности и необходимости )
А как на счёт поддержки этого счастья в drush?
Sign up to leave a comment.
Drupal PostInstall — модуль, позволяющий другим модулям «настраиваться» после установки