Собственные опции шаблона
Метки: опции
Суббота, 24 мая 2008 г.
Просмотров: 127
Подписаться на комментарии по RSS
Как я уже писал, опции я реализовал в виде ini-файла. Основные преимущества такого подхода в том, что можно с помощью простого ini-файла создать или поменять любые настройки сайта. То есть вместо «вшивания» настроек в «движок» мы выносим их в отдельный описательный файл.
Точно такой же способ я реализовал и для настройки шаблона. Попробую объяснить что я хотел добиться на примере WordPress.
Для примера можно рассмотреть такую настройку как количество записей для вывода на главной. В WordPress данная опция определена в самой админке. Кажется, что все логично, но предположим я хочу выводить разное количество записей для главной и для страницы рубрик. Что делать? В WordPress нужно лезть в шаблон и прописывать query_posts(). Согласитесь, малоэлегантное решение.
Когда-то я понял, что многие админские настройки WordPress - это прежде всего настройки самого шаблона. И вот добавление своих опций в админ-панель в WordPress'е сделано крайне сложно. Для того, чтобы добавить одну опцию придется дополнительно заниматься программированием и самого шаблона и «обслуживающего» файла (например, плагина).
Всё это меня совершенно не устраивало и в своей системе я решил, что настройки шаблона должны реализовываться гораздо проще и легче. Итак, как это работает сейчас.
- Вначале активируем плагин «Template options». Он как раз и подключает опции шаблона в админку. Этот плагин ищет в шаблоне файл options.php, где и реализуется нужный функционал.
- Теперь указываем в options.ini нужные нам настройки
- В шаблоне прописываем вызов настроки mso_get_option().
Вот пример ini-файла (рабочий):
- [Количество записей на главной]
- options_type = templates
- options_key = limit_post_home
- type = textfield
- description = "Укажите количество записей, которые будут выводиться на главной странице сайта."
- default = 5
- [Количество записей на остальных]
- options_type = templates
- options_key = limit_post
- type = textfield
- description = "Укажите количество записей, которые будут выводиться на остальных страницах (рубрики, архивы и т.д.)"
- default = 5
Файл options.php нет смысла описывать - он будет типовой и состоит из нескольких строчек.
В самом шаблоне, например в home.php в функции, которая получает вывод записей мы допишем нужную нам опцию:
- $par = array( 'limit' => mso_get_option('limit_post_home', 'templates', '7') );
То есть мы просто получаем опцию (ключ, тип) и её значение по-умолчанию (если нет).
Здесь важный момент состоит в том, что все опции хранятся в единой таблице БД и у них единый механизм работы. Все опции автоматически кэшируются (в памяти и на диске), поэтому лишних запросов к БД не генерируется. Конечно же в опции не следует «загонять» большие значения, как это сделано в WordPress - из-за этого кэш получается слишком большим и способен уже притормаживать.
Получение же любой опции осуществляется с помощью функции:
- mso_get_option('ключ', 'тип/группа', 'значение если нет')
Комментариев: 8
А почему бы не использовать вместо ini файла базу данных? А вместо ручного добавления в ini файл админку? Кстати, очень быстро сессия заканчивается:
Ошибка сессии! Обновите страницу
ini-файл очень просто редактировать и работать с ним. А данные так и хранятся - в базе.
Забыл имя указать. Я понимаю, что легче работать с ini-файлом, чем непосредственно с кодом, но ведь удобнее редактировать в html интерфейсе, вынесенного в админку.
Если честно, я не понимаю смысл ini-файла, если
[quote]
данные так и хранятся - в базе
[/quote]
Не уловил... Что редактировать?
А зачем ini, если в CI уже есть нативные конфиги и они прекрасно работают?
Видимо я плохо объяснил.
Ini-файл служит для того, чтобы указать саму опцию и форму для вывода этой опции. Проще ini уже ничего не придумать.
Что касается встроенного config, то толку от него как с козла молока: с таким же успехом можно просто задать массив и не морочить голову.
Я бы сделал немного по-другому.
В админке есть пункт «Дополнительные поля», там добавляется поле с параметрами (пример):
«Название поля» — mood
«Описание поля» — Настроение
«Категория» — edit_news
«Тип поля» — выпадающее меню
«Значение» — Отличное | Нормальное | Ужасное
«Использовать при желании» — да (если поле останется пустым, то будет использовано дефолтное значение)
После создания поля, в категории edit_news («Редактирование новости») в самом низу добавляется выпадающее меню для выбора настроения.
Для вывода настроения в шаблоне используется функция get_metafiled('mood', $id), где переменная id — идентификатор новости с настроением.
Кстати, какой будет дефолтный шаблон?
То есть ini-файл вынести в админку? Честно говоря, я не уверен в такой необходимости. Но, если сложилось мнение, что опциями можно управлять только через ini-файл, то это ошибка.
В данном случае я исхожу из того, что ini-файлом проще описать нужные нам опции/формы и не более того. Если нужно отредактировать сам файл, то несложно сделать редактор в файл-менеджере. Это если нужно править через админку.
Другой вариант - это добавить отдельный плагин, который будет выдавать/создавать/редактировать опции.
Что касается мета-полей к страницам, то тут немного сложней, поскольку это уже не таблица опций, а таблица meta. Я исходил из того, что в WordPress'е есть настрока метаполей, но а) многие мета являются служебными и их не требуется отображать; б) с ними неудобно работать; в) уже из своего опыта я выяснил, что в 99% случаев клиенту не требуются какие-то «сверх-поля» - обычно все ограничивается стандартным «источник», «title», «путь к миниатюре». То есть это один и тот же набор мета для всех записей. И тут, конечно же проще всего задать их один раз в файле, чем администрировать через панель управления.
Но, еще раз подчеркну, можно сделать плагин, который будет позволять управлять опциями/мета/ini через админку. Но в моих планах пока он не значится.
Дефолтный шаблон - это который сейчас на этом сайте.