Я тоже склонен к написанию для обычных юзеров собственной мини-админки, но для маленьких и средних проектов это пустая трата времени, имеет смысл для реально крупных проектов, чтобы ну вообще, с бюджетом, временем на разработку 1-2 месяца минимум.
Ну вот чтобы ничего не пилить, а быстро накидать полей и напринтить их в нужных местах, нода как раз ок. Задача выполняется? Да. Быстро? Да. Решение шаблонное? Да. Позволяет быстро кастомизировать и расширять вообще как угодно? Да. Нужно ли что-то учитывать при апдейтах? Нет.
Не знаю что сказать даже, для меня при любом раскладе создание нового типа содержимого для настроек удручает.
Не знаю что сказать даже, для меня при любом раскладе создание нового типа содержимого для настроек удручает. Для меня вполне логично выносить эти настройки на отдельную страницу, если уж уходить от страницы настройки темы.
Секретарша вообще не должна ничего менять на сайте, а только следить за ним, контент-менеджер да, но ему и можно выдать такие права. Да и то не имеет смысла, данные настройки редактируются крайне редко. По сути, у большинства это единоразовая операцию за весь его жизненный цикл.
Вынос настроек из темы на соответствующую страницу уже потребует написание кастомного модуля с hook_menu() и drupal_load_form(), в таком смысле уже проще и пилить свою форму настроек а не грузить из настроек темы.
В общем это палка о двух концах, вам удобен с нодами, мне ближе с темами, третьим вообще кастомная админка. Да, народ высказывался пару раз на каких-то друпал докладах, воде это был Дубовский Александр. Я тоже склонен к написанию для обычных юзеров собственной мини-админки, но для маленьких и средних проектов это пустая трата времени, имеет смысл для реально крупных проектов, чтобы ну вообще, с бюджетом, временем на разработку 1-2 месяца минимум. А то ведь все хотят сайт за 3 дня, тут не до админки.
Подумал над списком необходимого для решения с полями в Настройках темы. Получается, чтобы «догнать» вариант с новым типом ноды нам нужно реализовать:
Image cache
Сохранение файлов вообще
Разделение доступа к настройкам (тут я согласен с луллаботами: редактор контента и человек с доступом к настройкам темы — разные люди). Т.е. нужна возможность дать доступ только к нашим новым полям в сеттингсах темы. Ведь наш юзер — секретарша, меняющая телефоны и пр. мелкую, но иногда меняющуюся инфу на сайте.
Вынос всего этого на отдельную страницу
Ну и ещё нужно учесть, что семантически это всё именно данные сайта, это не настройки темы всё-таки.
Мне пока видится, что отдельный тип материала для всего этого выигрывает по всем параметрам.
Да где там гемор, по циклу же прогнать можно если их больше одной) Гемор было мне это решение собрать и чтобы заработало, а то я сделал сначала настройки а потом стали жаловаться что картинка пропадает. Сейчас зато всё ясно)
Вообще, если подумать, то ок, пусть будут настройки темы. Их действительно немного удобнее юзать для выдёргивания полей.
Но нужно как-то вынести наши новые поля на отдельную страницу. Чтобы, например, можно было в тулбаре сделать большую красивую кнопку/ссылку «Настройки», которую будет юзать заказчик, не лазая туда, куда не нужно, получая отдельную таку страницу со всем, что он может поменять. И на этой странице ещё бы на табы по тематике всё разделить: контакты, инфа для блока со скидками, инфа в подвале и тп.
Вот это было бы офигенное полезное решение и отличноая статья для блога :)
Узнайте какие публикации сейчас обсуждаются.
Какой редактор?
А, и только :) Ну если нету каких-то фактических возражений, значит можно пробовать.
У меня последние вопросы снялись после того, как я понял, что это никакие не настройки на самом деле, а такие же данные.
А как у вас, кстати, сделан редактор?
Не знаю, что-то изнутри теребит, и говорит что так неправильно)
Ну вот чтобы ничего не пилить, а быстро накидать полей и напринтить их в нужных местах, нода как раз ок. Задача выполняется? Да. Быстро? Да. Решение шаблонное? Да. Позволяет быстро кастомизировать и расширять вообще как угодно? Да. Нужно ли что-то учитывать при апдейтах? Нет.
А чем плохо?
Не знаю что сказать даже, для меня при любом раскладе создание нового типа содержимого для настроек удручает. Для меня вполне логично выносить эти настройки на отдельную страницу, если уж уходить от страницы настройки темы.
Секретарша вообще не должна ничего менять на сайте, а только следить за ним, контент-менеджер да, но ему и можно выдать такие права. Да и то не имеет смысла, данные настройки редактируются крайне редко. По сути, у большинства это единоразовая операцию за весь его жизненный цикл.
Вынос настроек из темы на соответствующую страницу уже потребует написание кастомного модуля с hook_menu() и drupal_load_form(), в таком смысле уже проще и пилить свою форму настроек а не грузить из настроек темы.
Image Cache? Зачем? image_style_url('stylename', $file->uri)
В общем это палка о двух концах, вам удобен с нодами, мне ближе с темами, третьим вообще кастомная админка. Да, народ высказывался пару раз на каких-то друпал докладах, воде это был Дубовский Александр. Я тоже склонен к написанию для обычных юзеров собственной мини-админки, но для маленьких и средних проектов это пустая трата времени, имеет смысл для реально крупных проектов, чтобы ну вообще, с бюджетом, временем на разработку 1-2 месяца минимум. А то ведь все хотят сайт за 3 дня, тут не до админки.
Да, и ещё + мультиязычность.
Никита, привет!
Подумал над списком необходимого для решения с полями в Настройках темы. Получается, чтобы «догнать» вариант с новым типом ноды нам нужно реализовать:
Image cache
Сохранение файлов вообще
Разделение доступа к настройкам (тут я согласен с луллаботами: редактор контента и человек с доступом к настройкам темы — разные люди). Т.е. нужна возможность дать доступ только к нашим новым полям в сеттингсах темы. Ведь наш юзер — секретарша, меняющая телефоны и пр. мелкую, но иногда меняющуюся инфу на сайте.
Вынос всего этого на отдельную страницу
Ну и ещё нужно учесть, что семантически это всё именно данные сайта, это не настройки темы всё-таки.
Мне пока видится, что отдельный тип материала для всего этого выигрывает по всем параметрам.
Что скажете?
Да где там гемор, по циклу же прогнать можно если их больше одной) Гемор было мне это решение собрать и чтобы заработало, а то я сделал сначала настройки а потом стали жаловаться что картинка пропадает. Сейчас зато всё ясно)
И ещё прикрутить к картинкам применение actions, конечно.
Вообще, если подумать, то ок, пусть будут настройки темы. Их действительно немного удобнее юзать для выдёргивания полей.
Но нужно как-то вынести наши новые поля на отдельную страницу. Чтобы, например, можно было в тулбаре сделать большую красивую кнопку/ссылку «Настройки», которую будет юзать заказчик, не лазая туда, куда не нужно, получая отдельную таку страницу со всем, что он может поменять. И на этой странице ещё бы на табы по тематике всё разделить: контакты, инфа для блока со скидками, инфа в подвале и тп.
Вот это было бы офигенное полезное решение и отличноая статья для блога :)