Тема для Cotonti Siena: как использовать, распространять и поддерживать

Бесплатная тема для Cotonti Siena – это редкий в наших краях зверь. Вроде есть для этого умные головы и небольшая армия страждущих, но темы все равно не появляются. Хотя ничего сложного в этом в принципе нет. Пробуем понять почему.

Как устанавливать тему Cotonti

Вопрос не технический, а скорее стратегический, и вариантов два:

1. Сайт только планируется
2. Сайт уже есть

Первый вариант проще, но все равно требует понимания. Разберем сначала его.

Установка темы на чистый дистрибутив это уже маленькая проблема. Сделать тему без использования сторонних плагинов сложновато. Я, например, не люблю тянуть в нее Bootstrap и гружу его отдельным плагином. Аналогично по иконкам. Pagelist для меня удобнее и привычнее встроенной cot_page_enum() А для реализации, например, рубрикатора вообще не обойтись без стороннего расширения. Так что требования к дополнительному обвесу надо обязательно расписывать в документации. И не факт, что любители all-in-one не понизят вам карму комментариями-жалобами о том, что для установки одной темы нужно установить еще пять двенадцать плагинов.

Следующая проблема состоит в том, как тему оценить. В “коробке” у нас четыре “модельных” раздела и одна тестовая страница. Этого определенно мало для того, чтобы, например, увидеть и оценить реализацию адаптивности в целом или стилей в частности. Мы не увидим как на мобильном устройстве раздел “схлопывается” в одну колонку или как выглядят подзаголовки, цитаты, паджинатор и множество других элементов. В качестве решения можно создать демо на поддомене или поставлять тему в виде сборки (но это уже совсем другая история). Перегружать дистрибутив лишним десятком тестовых страниц или картинками тоже не вариант.

Установка на уже существующий сайт добавит новых проблем. Например, у вас есть свой набор плагинов, под которые нужны свои TPL-шаблоны. Нейминг разделов может потребовать переименование шаблонов в дистрибутиве темы. Опять же, терминология: у кого-то “тег”, а у кого-то “хэштег”.

И это только навскидку. Подводных камней на действующем сайте может быть гораздо больше.

Как адаптировать front-end тему под необходимый или существующий функционал

Отдельный момент – это реализация технических вопросов. Частично это уже было расписано выше. Но есть и другое. Возьмем, например, блог. Здесь есть как минимум несколько опций:

1. Все посты создавать в разделе blog
2. Использовать тематические разделы, посты из которых выводить в “виртуальном” разделе blog с помощью Pagelist / cot_page_enum()
3. Не использовать раздел blog. Посты создавать в тематических разделах и собирать их на главной с помощью все тех же Pagelist / cot_enum()

Есть еще как минимум несколько вариантов, в том числе с подразделами. И все они имеют право на существование. Вот только в одной теме все это учесть невозможно. И это только блог, где все и так предельно просто, а местами – примитивно.

В идеальном варианте, можно и нужно добавлять в тему шаблоны для сторонних плагинов – если с их помощью возможна реализация уже заложенного в тему или (особенно) дополнительного функционала.

Как все это влияет на создание и распространение тем для Cotonti

Выкладываемая в открытый доступ тема должна быть одновременно свободна от каких-либо вариантов адаптации и, при этом, быть рассчитана на определенный вариант адаптации. Привязок к конкретному проекту быть не должно. Весь контент из шаблонов необходимо оформлять в виде lang-строк и собирать в lang-файлы темы.

Кастомизация темы должна быть понятным образом задокументирована. Пользователь должен понимать не только как установить тему, но и как ее кастомизировать под свой проект, не внося хаос ни в тему, ни в сам проект.

Это идеальный “расклад”. В реальной жизни все может быть совсем иначе.

Простой пример: ваша тема называется Kilimandjaro. Именно это название вы используете в хедере в качестве названия сайта. Но мой блог называется “100 способов починить проводку” или сокращенно 100SPP. Я должен буду заменить им исходное название от разработчика темы. А это значит, что при обновлении темы файл header.tpl будет перезаписан, и мой сайт из 100SPP превратится в Kilimandjaro.

Конечно, здесь можно использовать и значение {PHP.cfg.maintitle} – если это устроит пользователя. А если не устроит?

Это примитивный пример, но их может быть довольно много. Впрочем, как и решений и адептов этих самых решений.

И теперь главный для меня вопрос:

Скачивая front-end тему Cotonti, кем вы себя видите: пользователем или разработчиком?

В первом случае вы используете ее как готовый продукт и ожидаете:

• возможности использовать тему “как есть” (с учетом требований к установке дополнительных плагинов),
• обратной связи от разработчика в решении вопросов и закрытии багов,
• получении обновлений и (насколько это возможно) новых возможностей и фич в виде дополнительных шаблонов, скриптов и проч.

Если же вы непримиримый разработчик, то тему вы будете адаптировать под свои нужды в режиме “по живому”. Поэтому из всего перечисленного выше будет доступна только обратная связь, да и то в рамках разумного.

Оба варианта для меня совершенно равнозначны. Цель в том, чтобы понять, реально ли предлагать front-end тему для Cotonti в виде готового и поддерживаемого продукта, или это всегда будет полуфабрикат для дальнейшего творчества.

Комментарии для данного поста закрыты, обсуждение можно продолжить в соответствующей ветке на форумах Cotonti.

Ранее мы разбирались с выводом ошибок в TPL-шаблоне Cotonti Siena.