Вообще не должна, т.к. фактически она не вклинивается в установку а запускается после нее и исключительно при обращении к интерфейсу (со страницы admin/modules). Drush же полагаю использует функции напрямую.
Но проверю на вский случай.
По разному на самом деле. В моем случае я создал issue 29 октября и после некоторых замечаний и правок получил апрув 2 ноября. drupal.org/node/1326122
Стандарты действительно жесткие, но в большинстве случаев оправданные. Задачей апрува вообщем-то является не столько заставить следовать беспрекословно этим стандартам, сколько заставить плотно ознакомиться с ними. Думаю после тщательного ознакомления у Вас не должно возникнуть особых вопросов к их логичности и необходимости )
Пожалуйста.
Скоро должна проявится DEV версия на drupal.org. Просто DEV версии обновляются раз в 12 часов в отличии от релизов.
Что касается релизной, в принципе DEV версия должна быть стабильной, но я привык пару недель подождать с момента публикации перед выпуском релиза. Мало ли что выплывет.
Ну если Ваша статистика верна, это лишь значит что модуль нужен для оставшихся 10% )
Вывести форму настроек после установки через Feautures это ничуть не лучше чем делать это вручную в модуле с помощью хуков. А у меня видно слишком много модулей из тех самых 10% чтобы в каждом делать это хуками.
Как уже было сказано, задача этого модуля — унифицировать процесс и обеспечить последовательность настройки в соответствии с зависимостями.
В первую очередь тем что не решают данной конкретной задачи — не дают возможность модулям автоматически отображать и обрабатывать свои страницы настроек после установки.
Не говоря уже о том что в этом модуле 100 строк а только в feautures.module их 9 сотен.
Я потратил около часа времени на поиск чего-то подобного. Потом мне надоело, и я потратил второй час времени на написание этого модуля )
Если кто-то знает подобный модуль под 7ку, киньте линк и, ну что же, буду тогда посыпать голову пеплом :)
Не соглашусь.
1. Тема переносима. Все остальное также переносимо с помощью Features или аналогов. А если Вы не считаете подобный подход корректным «переносом», тогда, исходя из Вашей логики, создание нового типа материала — тоже костыль. Ведь его нельзя воткнуть в новый сайт просто подключив модуль.
2. А по Вашему писать под каждую микро задачу отдельный модуль — это не костыль?
3. В чем заключается избыточность? Вьюха хранится компактно, кэшируется. Административный интерфейс всех модулей убран в отдельные inc файлы которые при отображении вьюхи не включаются. Если очень хочеться, можете не использовать модули Link и Weight. В этом и заключается гибкость решения, не надо — выключил.
Точной статистики сейчас на руках нет, но г-ин Гэлвин из iO1.biz как то показывал сравнительные данные по Views 2 и Views 3. Views 3 формирует гораздо более вменяемые запросы к DB чем его предшественник.
«Костыль — средство добавления недостающей функциональности или исправления серьёзных дыр без должного редизайна системы. Каждый костыль затрудняет дальнейшее развитие. В тех случаях, когда костыль уничтожает незапланированную функциональность, называется заплаткой.»
Вы уверены что верно применили слово «костыль»?
В ядро я не лез, модули не правил. Все делалось с помощью официальных версий готовых модулей.
Так что в моем способе как раз таки костылей нет :)
Views стоит на большинстве сайтов. Тем более что в 7 Views работает гораздо быстрее.
Остальные модули очень легкие.
Свой код применялся только для темизации.
Можно не темизировать, но тогда будет некрасиво :)
А готового варианта который идеально впишется в Ваш дизайн Вы никогда не найдете. Всеравно придется что-то темизировать.
В том то и суть, что если попадается задача, которую нельзя разбить на этапы, подход более чем бесполезен.
Конкретно про упаковку файлов могу сказать, что в данном случае чаще всего просто пишется специальная програмка упаковщик. Задание для нее можете заносить в БД через сайт, а програмка сама оттуда будет его получать.
Например подобный подход используется на Drupal.org для создания релизов модулей. С некоторой частотой (для дев релизов 2 раза в день, для стабильных релизов раз в 5 минут) программа паковщик проходится по git репозиториям модулей и создает скачиваемый архив.
Но проверю на вский случай.
Если нет, то сам сделаю, но не могу ничего обещать относительно сроков.
drupal.org/node/1326122
Стандарты действительно жесткие, но в большинстве случаев оправданные. Задачей апрува вообщем-то является не столько заставить следовать беспрекословно этим стандартам, сколько заставить плотно ознакомиться с ними. Думаю после тщательного ознакомления у Вас не должно возникнуть особых вопросов к их логичности и необходимости )
Скоро должна проявится DEV версия на drupal.org. Просто DEV версии обновляются раз в 12 часов в отличии от релизов.
Что касается релизной, в принципе DEV версия должна быть стабильной, но я привык пару недель подождать с момента публикации перед выпуском релиза. Мало ли что выплывет.
Вывести форму настроек после установки через Feautures это ничуть не лучше чем делать это вручную в модуле с помощью хуков. А у меня видно слишком много модулей из тех самых 10% чтобы в каждом делать это хуками.
Как уже было сказано, задача этого модуля — унифицировать процесс и обеспечить последовательность настройки в соответствии с зависимостями.
Не говоря уже о том что в этом модуле 100 строк а только в feautures.module их 9 сотен.
Если кто-то знает подобный модуль под 7ку, киньте линк и, ну что же, буду тогда посыпать голову пеплом :)
Поделите одно на другое. Вот Вам и пруфлинк.
1. Тема переносима. Все остальное также переносимо с помощью Features или аналогов. А если Вы не считаете подобный подход корректным «переносом», тогда, исходя из Вашей логики, создание нового типа материала — тоже костыль. Ведь его нельзя воткнуть в новый сайт просто подключив модуль.
2. А по Вашему писать под каждую микро задачу отдельный модуль — это не костыль?
3. В чем заключается избыточность? Вьюха хранится компактно, кэшируется. Административный интерфейс всех модулей убран в отдельные inc файлы которые при отображении вьюхи не включаются. Если очень хочеться, можете не использовать модули Link и Weight. В этом и заключается гибкость решения, не надо — выключил.
Вы уверены что верно применили слово «костыль»?
В ядро я не лез, модули не правил. Все делалось с помощью официальных версий готовых модулей.
Так что в моем способе как раз таки костылей нет :)
Остальные модули очень легкие.
Свой код применялся только для темизации.
Можно не темизировать, но тогда будет некрасиво :)
А готового варианта который идеально впишется в Ваш дизайн Вы никогда не найдете. Всеравно придется что-то темизировать.
На Вашей собрке также посмотрел, все нормально.
Конкретно про упаковку файлов могу сказать, что в данном случае чаще всего просто пишется специальная програмка упаковщик. Задание для нее можете заносить в БД через сайт, а програмка сама оттуда будет его получать.
Например подобный подход используется на Drupal.org для создания релизов модулей. С некоторой частотой (для дев релизов 2 раза в день, для стабильных релизов раз в 5 минут) программа паковщик проходится по git репозиториям модулей и создает скачиваемый архив.