Попробуйте на паре проектов свой метод и метод с настройками темы, а затем поделитесь впечатлениями собственными и тех кто потом пользуется сайтом.
Примерно такого и просят эти самые пользователи. Потому что сейчас они правят инфу в блоках одним способом (даже когда там всего поменять два слова), инфу в шапке — другим способом, инфу на странице с контактами — третьим сопсобом.
Так можно закрыть им доступ вообще ко всем блокам, оставить одну страницу, на которой бы в полях были все даннные такого типа (в своих филдсетах или даже табах), которые на этой одной странице меняла бы секретарша, и они бы сразу менялись во всех местах на сайте.
И, кстати, говоря о чистоте. Ведь это не настройки сайта. Это просто инфа. Прятать просто инфу в раздел с настройками темы сайта — не так уж и очевидно, на мой взгляд. А так просто нода с настройками сайта содержит всё, что на этом сайте может поменять условная секретарша.
Ну создание типа содержимого для единственной настройки... я на такое точно не пойду) Стараюсь в проектах все держать в чистоте и такой типа с одной нодой для меня будет грязью.
Попробуйте на паре проектов свой метод и метод с настройками темы, а затем поделитесь впечатлениями собственными и тех кто потом пользуется сайтом.
Вы создаете отдельный тип ноды для настроек где ципляете свои филды, или как? Ведь если это тип общего назначения у него появляется куча бесполезных полей. Как я вижу тут появляется зависимость в модуле, которые позволяет динамически цеплять поля к ноде не иначе, либо пилить свой тип ноды для настроек... В общем что-то до меня сейчас дошло это и настройки через ноду стали еще туманнее.
Я ещё не создаю. Я кормил утку сегодня и подумал, что можно так попробовать делать, тогда на утку может быть больше времени. А тут ваш пост, решил сразу посоветоваться.
Да, просто создать новый типа ноды. Набить туда полей (например, телефон, который показывается в шапке, подвале и блоке на странице с заказами; и, например, поле для названия акции (скажем, секретарше нужно раз в месяц менять строчку «Акция Скидка 50%» на строчку «Акция Скидка 75%»).
Дальше эти два поля мы просто принтим в шаблоны в нужных местах и блоках. Всё. А секретарша заходит на одну единственную ей известную страницу настроек (нашу ноду), и менят там в простых полях то, что нужно.
В данном случае быстро, простое и удобное решение такое, каким привыкли пользоваться вы.
Если судить со стороны новичка в друпале, технически не сильно подготовленного, допустим которые могут что-то на php влепить из копипаста, мб даже чего поймут и у них заработает. То тут я так вижу ситуацию. Вариант с настройками сложен для настройки (первые разы), но легко в дальнейшем использовании данных. А в случае с нодой, очень легко запилить такую ноду, но вызывать не совсем логично. Им придется принтить массив и разгребать его, если они свободно не смогут обратиться к данным.
И вот пока писал назрел вопрос. Вы создаете отдельный тип ноды для настроек где ципляете свои филды, или как? Ведь если это тип общего назначения у него появляется куча бесполезных полей. Как я вижу тут появляется зависимость в модуле, которые позволяет динамически цеплять поля к ноде не иначе, либо пилить свой тип ноды для настроек... В общем что-то до меня сейчас дошло это и настройки через ноду стали еще туманнее.
Просто так со стороны, это не drupalway решение. Ведь возможность добавления своих настроек в тему не для галочки сделана.
Многие drupalway-решения своими корнями застряли очень глубоко и часто это является единственным оправданием их сущестоввания в теперешнем виде, о б этом часто говорят и работающие над 8-9. Так что я как раз смотрю, если у нас есть столько проблем и странностей с набором настроек, а не сделать ли всё это проще и логичнее для юзера?
А в довесок к этому создавать свой кастом модуль, где создать специальную, собственную админку на тех же формах и пейджах. Оформить как положено и т.д. Но такие админки есть смысл писать только под действительно крупные проекты, а всякую мелочь можно скинуть на тему.
Писать админку или скинуть на тему и скрывать/дорабатывать? Подход с простой нодой не проще/очевиднее ли?
А как вы из ноды данные грузите, допустим поле с телефоном?
Я не могу назвать минусы подхода с нодой, потомучто не использовал, да даже не задумывался о таком решении. Просто так со стороны, это не drupalway решение. Ведь возможность добавления своих настроек в тему не для галочки сделана. Просто я считаю, что всему своё место, и таким вещам как банальные фразы, текста, имейджы для темы надо выносить в её настройки.
Вообще, как по мне, клиенту нужно отдавать сайт с двумя юзерами, админом что по дефолту в друпале, и некий адмиинстратор который может набор-минимум. Добавление, редактирование контента, комментарии, если магазин то управлять заказами и т.д. Никаких технических настроек. А в довесок к этому создавать свой кастом модуль, где создать специальную, собственную админку на тех же формах и пейджах. Оформить как положено и т.д. Но такие админки есть смысл писать только под действительно крупные проекты, а всякую мелочь можно скинуть на тему.
По крайней мере в моих проектах решение в качестве ноды точно не найдет применения. Я очень щепитилен к такому. Меня очень выбешивает тип содержимого webform, который создается при включении одноименного модуля. Сразу сношу и навешиваю возможности форм на обычный пейдж =\ Админка чище и клиент не задает а что такое Вебформ, а в русском варианте и вовсе "Опросник". Они думают что это опрос и сидят в непонятках.
Поэтому я поднял тему на счет того что я хочу спрятать как-то грамотно настройки зена, чтобы обычный юзер не видел никаких настроек фавиконок, theme rebuld и т.д.
А как вы из ноды данные грузите, допустим поле с телефоном?
Про вынесение настроек в ноду. Я не утверждаю, что так нужно делать, но не является ли это как раз хорошим решением для кастомных настроек?
Ну, смотрите, какие плюсы мне тут видны:
а) Делается (и переделывается) очень быстро. Т.е. для другого сайта можно использовать готовые шаблоны, что-то добавляя и убирая по необходимости.
б) Прятать от поисковиков? Так одна строчка же в роботсе всего, нет?
в) У секретарши в админке будет ссылка «Настройки», которая будет показывать эту ноду с нужными полями, ничего лишнего она не уидит и не испортит. Телефон изменился — ввела другой, сохранила.
А тема меняется и там появляются\убираются некоторые поля. Опять искать ноду и править чтоли. А так это настройки для конкретной темы получаются.
Ну, это ведь речь уже о кастомной теме. Конечно, при смене темы нужно будет наши поля (из этой одной ноды с настройками) засунуть по нужным местам тпл (через print) новой темы.
И вопрос изменений при смене тему тут не очень актуален. Ведь у любого достаточно кастомизированного сайта при смене темы отвалится много чего.
Т.е. всё перечисленное выглядит скорее как плюсы такого решения, нет? А какие ещё существенные минусы вы бы могли назвать?
Да. Картинка будет вызываться как положено, все будет хорошо. Но через 6 часов слетит и после сброса кеша её уже нигде не будет.
Не знаю, не пробовал. Попробую, если разберусь напишу статью. Я тоже думаю как допустим зеновские конфиги прятать. Хайдом и прочим бредом очень криво получается, и форма слетает. Скорее всего проще делать врапперы с классом на дисплой нон. А вкладки... я думаю что это маловероятно, ведь это форма а не пейдж. Это надо сначала сделать страницу-вкладку,а уже затем туда форму нашу сливать.
Я делаю через найстроки темы. Зачем через ноду. Она ведь для этого еще и страницу резервирует. Её надо перекрывать для поисковиков и т.д. и т.п. Это гемор. А тема меняется и там появляются\убираются некоторые поля. Опять искать ноду и править чтоли. А так это настройки для конкретной темы получаются.
Т.е. если даже форму сохранили, то файл картинки всё равно удалится по крону?
А как сделать отдельную вкладку в настройках темы с нишими кастомными настройками?
А имеет ли смысл на ваш взгляд сделать для кастомных настроек (телефоны, адреса и прочая информация, которая часто показывается в разных местах сайта) свой отдельный тип материала с кучей нужных полей и рассовать принтом по разным частям tpl?
Узнайте какие публикации сейчас обсуждаются.
Примерно такого и просят эти самые пользователи. Потому что сейчас они правят инфу в блоках одним способом (даже когда там всего поменять два слова), инфу в шапке — другим способом, инфу на странице с контактами — третьим сопсобом.
Так можно закрыть им доступ вообще ко всем блокам, оставить одну страницу, на которой бы в полях были все даннные такого типа (в своих филдсетах или даже табах), которые на этой одной странице меняла бы секретарша, и они бы сразу менялись во всех местах на сайте.
И, кстати, говоря о чистоте. Ведь это не настройки сайта. Это просто инфа. Прятать просто инфу в раздел с настройками темы сайта — не так уж и очевидно, на мой взгляд. А так просто нода с настройками сайта содержит всё, что на этом сайте может поменять условная секретарша.
Ну создание типа содержимого для единственной настройки... я на такое точно не пойду) Стараюсь в проектах все держать в чистоте и такой типа с одной нодой для меня будет грязью.
Попробуйте на паре проектов свой метод и метод с настройками темы, а затем поделитесь впечатлениями собственными и тех кто потом пользуется сайтом.
Я ещё не создаю. Я кормил утку сегодня и подумал, что можно так попробовать делать, тогда на утку может быть больше времени. А тут ваш пост, решил сразу посоветоваться.
Да, просто создать новый типа ноды. Набить туда полей (например, телефон, который показывается в шапке, подвале и блоке на странице с заказами; и, например, поле для названия акции (скажем, секретарше нужно раз в месяц менять строчку «Акция Скидка 50%» на строчку «Акция Скидка 75%»).
Дальше эти два поля мы просто принтим в шаблоны в нужных местах и блоках. Всё. А секретарша заходит на одну единственную ей известную страницу настроек (нашу ноду), и менят там в простых полях то, что нужно.
В данном случае быстро, простое и удобное решение такое, каким привыкли пользоваться вы.
Если судить со стороны новичка в друпале, технически не сильно подготовленного, допустим которые могут что-то на php влепить из копипаста, мб даже чего поймут и у них заработает. То тут я так вижу ситуацию. Вариант с настройками сложен для настройки (первые разы), но легко в дальнейшем использовании данных. А в случае с нодой, очень легко запилить такую ноду, но вызывать не совсем логично. Им придется принтить массив и разгребать его, если они свободно не смогут обратиться к данным.
И вот пока писал назрел вопрос. Вы создаете отдельный тип ноды для настроек где ципляете свои филды, или как? Ведь если это тип общего назначения у него появляется куча бесполезных полей. Как я вижу тут появляется зависимость в модуле, которые позволяет динамически цеплять поля к ноде не иначе, либо пилить свой тип ноды для настроек... В общем что-то до меня сейчас дошло это и настройки через ноду стали еще туманнее.
Многие drupalway-решения своими корнями застряли очень глубоко и часто это является единственным оправданием их сущестоввания в теперешнем виде, о б этом часто говорят и работающие над 8-9. Так что я как раз смотрю, если у нас есть столько проблем и странностей с набором настроек, а не сделать ли всё это проще и логичнее для юзера?
Писать админку или скинуть на тему и скрывать/дорабатывать? Подход с простой нодой не проще/очевиднее ли?
Ну, другому программисту придётся прочитать три слова про то, что поля нужно брать в ноде Nastrojki, например. Тоже ведь ничего сложного и страшного.
Я не холиварю ни в коем случае. Пытаюсь найти быстрое, простое, удобное решение.
Я не могу назвать минусы подхода с нодой, потомучто не использовал, да даже не задумывался о таком решении. Просто так со стороны, это не drupalway решение. Ведь возможность добавления своих настроек в тему не для галочки сделана. Просто я считаю, что всему своё место, и таким вещам как банальные фразы, текста, имейджы для темы надо выносить в её настройки.
Вообще, как по мне, клиенту нужно отдавать сайт с двумя юзерами, админом что по дефолту в друпале, и некий адмиинстратор который может набор-минимум. Добавление, редактирование контента, комментарии, если магазин то управлять заказами и т.д. Никаких технических настроек. А в довесок к этому создавать свой кастом модуль, где создать специальную, собственную админку на тех же формах и пейджах. Оформить как положено и т.д. Но такие админки есть смысл писать только под действительно крупные проекты, а всякую мелочь можно скинуть на тему.
По крайней мере в моих проектах решение в качестве ноды точно не найдет применения. Я очень щепитилен к такому. Меня очень выбешивает тип содержимого webform, который создается при включении одноименного модуля. Сразу сношу и навешиваю возможности форм на обычный пейдж =\ Админка чище и клиент не задает а что такое Вебформ, а в русском варианте и вовсе "Опросник". Они думают что это опрос и сидят в непонятках.
Поэтому я поднял тему на счет того что я хочу спрятать как-то грамотно настройки зена, чтобы обычный юзер не видел никаких настроек фавиконок, theme rebuld и т.д.
А как вы из ноды данные грузите, допустим поле с телефоном?
$node = node_load($nid);
$node->field_name['und'][0]'value']
Так чтоли?
Если да, то ведь если проект будет поддерживать другой прогер, theme_get_setting() более говорящая функция)
Ну и гемора с картиночными и файловыми данными не будет, опять же.
Спасибо за быстрый ответ!
Про вынесение настроек в ноду. Я не утверждаю, что так нужно делать, но не является ли это как раз хорошим решением для кастомных настроек?
Ну, смотрите, какие плюсы мне тут видны:
а) Делается (и переделывается) очень быстро. Т.е. для другого сайта можно использовать готовые шаблоны, что-то добавляя и убирая по необходимости.
б) Прятать от поисковиков? Так одна строчка же в роботсе всего, нет?
в) У секретарши в админке будет ссылка «Настройки», которая будет показывать эту ноду с нужными полями, ничего лишнего она не уидит и не испортит. Телефон изменился — ввела другой, сохранила.
Ну, это ведь речь уже о кастомной теме. Конечно, при смене темы нужно будет наши поля (из этой одной ноды с настройками) засунуть по нужным местам тпл (через print) новой темы.
И вопрос изменений при смене тему тут не очень актуален. Ведь у любого достаточно кастомизированного сайта при смене темы отвалится много чего.
Т.е. всё перечисленное выглядит скорее как плюсы такого решения, нет? А какие ещё существенные минусы вы бы могли назвать?
Да. Картинка будет вызываться как положено, все будет хорошо. Но через 6 часов слетит и после сброса кеша её уже нигде не будет.
Не знаю, не пробовал. Попробую, если разберусь напишу статью. Я тоже думаю как допустим зеновские конфиги прятать. Хайдом и прочим бредом очень криво получается, и форма слетает. Скорее всего проще делать врапперы с классом на дисплой нон. А вкладки... я думаю что это маловероятно, ведь это форма а не пейдж. Это надо сначала сделать страницу-вкладку,а уже затем туда форму нашу сливать.
Я делаю через найстроки темы. Зачем через ноду. Она ведь для этого еще и страницу резервирует. Её надо перекрывать для поисковиков и т.д. и т.п. Это гемор. А тема меняется и там появляются\убираются некоторые поля. Опять искать ноду и править чтоли. А так это настройки для конкретной темы получаются.
Отличный пост, Никита!
Монжо задать пару вопросов?
Т.е. если даже форму сохранили, то файл картинки всё равно удалится по крону?
А как сделать отдельную вкладку в настройках темы с нишими кастомными настройками?
А имеет ли смысл на ваш взгляд сделать для кастомных настроек (телефоны, адреса и прочая информация, которая часто показывается в разных местах сайта) свой отдельный тип материала с кучей нужных полей и рассовать принтом по разным частям tpl?