Предложение по работе с шаблонами
21.06.2010Голосование
| Тип | Пожелание |
| Состояние | Исправлено |
| Приоритет | Высокий |
| Версия | 3.55 |
| Система | * |
| Воспроизводимость | Нет |
| Автор | Константин |
| Исполнитель | Блоголётчик |
На мой взгляд, часть проблемы решил бы очень подробно раскомментированный шаблон дефолтной темы, где было бы расписано:
- какой блок кода за что отвечает - заголовок, тело поста, вывод виджетов и т.д.;
- что конкретно выдает на экран абракадабра (с точки зрения среднего пользователя :) ) вида "%1$s", "post-$post.id" и т.п., в каком формате сие должно "подаваться" в шаблоне. Чтобы было понятно, что
вот это заголовок - заголовок поста, вот это - дата поста, это - ссылка на комментарий, а вот это лучше вообще не трогать...
Выскажу вообще крамольную мысль... :) Стоило бы заставить делать движок сделать несколько лишних телодвижений и вообще убрать из шаблона всё загадочное вида "$lang.permalink $post.title"
и заменить сие на удобопонятные служебные тэги, например:
- выводит название сайта;
- выводит описание сайта;
- выводит дату поста;
- выводит тело поста;
- выводит ссылку на комментарии к посту;
- выводит кол-во комментариев к посту;
...
и т.д и т.п., на все случаи жизни. То есть сделать шаблон по принципу конструктора: верстаем банальную HTML- страничку на таблицах или стилях, как кому понятнее, и в нужные места вставляем нужные
тэги...
Идея не нова и не моя, таковое, например, давно и успешно используется в GB TOP (gbscript.com/top-dir-docs.html), в Blogs Organizer'е (support.cheapestwebsoftware.com/viewtopic.php?t=27) и других скриптах и делает написание темплейта делом тривиальным даже для не сильно искушенного пользователя, а скрипту очень добавляет популярности в народе (а мы ведь к тому и стремимся?..).
Комментарии (52) на запись “Предложение по работе с шаблонами”
Оставить комментарий
Владимир, маленькая просьба - убери пожалуйста теги комментариев в тикете в %%TITLE%%, %%DESCRIPTION%%, %%POST_DATE%% и т.д... А то не совсем понятно, о чем речь идет. Как самому отредактировать тикет - не понял, "Управление записью" в меню появляется, но по всем пунктам выдает "не найдено".
Блоголётчик пишет:
Берется-то это из админки, и ремарка в описании тегов это прояснит, да и человек знакомые слова увидит и поймет, что и откуда. И все-таки позволю себе не согласиться, что $template.title, $options.title для не-программиста понятнее, чем %%title%%. :)
Блоголётчик пишет:
Мне кажется, что в этом нет необходимости, просто произойдет неоправданное наворачивание кода, раздутие документации (которую простой юзер читать не слишком любит - проверено...) и еще сильнее запутает простого юзера. Одна удобоваримая система шаблонизации, как в приведенных выше примерах, наоборот привлечет оного.
Под простым юзером я подразумеваю человека, который просто хочет поиметь свой блог с минимальными трудозатратами, о PHP знает только, что это какой-то там язык программирования и видел Дримвейвер или иже с ним. Исходя из этого, существующая система шаблонизации (а тем паче мультисистема) против предлагаемой мне видится... ну возьмем такую аналогию: консолью Линукса против графического интерфейса Виндовс. И простой юзер таки предпочитает Виндовс, хотя Линукс с KDE или Gnome ничем не хуже (а кое в чем и получше будет), но предполагает определенное знание матчасти.
Блоголётчик пишет:
Я собственно и имел в виду что-то вроде freecsstemplates.org, где выложена куча простых HTML страничек, ожидающих только запихивания в них соответствующих тегов, как например freecsstemplates.org/preview/symphonic/, к тому же простых в редактировании. На их базе также можно изверстать и что-то свое.
И побохульствую еще... :) Я бы раз и навсегда разделил шаблон админки и шаблон отображаемого в паблик сайта, задавшись простым вопросом: "Что теряет пользователь, имея простую, понятную в навигации и удобную админку стандарного неизменного дизайна?" Да ровным счетом ничего. Зато из index.tml уходит все связанное с админкой и в шаблоне отображается/правится только то, что отображается в паблике.
Блоголётчик пишет:
Ну тут, наверное, поможет подробная документация по армейскому принципу : "...делай раз, делай два, делай три...", кому это надо - прочитает и разберется, как впихнуть эти фичи в шаблон. Пример не совсем в тему, но очень показателен: lasto.com/blog/post_1265907600.html
Начну отвечать с конца - для админки, как и для некоторых других страниц можно установить отдельную тему, делается это в админке/темы/настройки, так что можно сделать и тему, которая исползовалась бы только в админке. Что касается поддержки альтернативных (по отношеню к блоглёту) тем, то пока в размышлении как это проще сделать - пока что не было времени посмотреть как устроен альтернативный шаблон, чтобы судить о сложности. В следствии этого родиласьидея о прямой поддержки тем wordpress - сделать несложную прокладку между функциями wordpress и блоглётом (например 100-300 функций) для поддерки большинства простых тем.
На остальные вопросы/мысли постараюсь ответить несколько позже - тема поднята достаточно серьезная, чтобы отвергатьили сразу впрягаться в реализацию, и необходимо все взвесить. Скорее всего напишу отдельный пост с размышлениями об этом
На мой взгляд, обе идеи будут востребованы, причем в комплексе. Для манимейкинга (Сапа, сателлиты и т.д) с дизайнами особо никто не изголяется, и тут вариант "прокладки" просто находка. А вот для любимых авторских сайтов хочется, как правило, что-то оригинальное, вот тут весьма кстати вариант "визивиг - HTML - спец. теги".
А вообще хотелось бы, конечно, услышать мнение масс :), поскольку тема шаблонов для Блоголета пока остается единственным минусом движка (ну и еще документация - но это не самое сложное...), мешающим ему активно двинуться "в народ". Что в общем-то обидно, ибо движок хорош. Очень хорош.
Буду ждать поста, очень интересно послушать другие мнения.
5 дней!! Почему же в первый день, когда возникли сложности было не написать??? В личку я уже правда стараюсь не отвечать, но в комментах или в тикетах однозначно. Некогда была сделалана часть документации:
http://blogolet.ru/category/razrabotchiku/
где несколько раз пытался писать про темы:
http://blogolet.ru/texzadanie-tema-dlya-blogolyota/
http://blogolet.ru/shablon-dlya-kommentariev-i-formy-kommentariev/
после внесения изменеий в index.tml необходимо нажать кнопку "перечитать" в аждминке/темы, либо тюда/сюда пееключиться между темами. Думаю, что для разработчиков тем надо будет добавить спецрежим, чтбы не нажимать эту кнопку.
Спецрежим очень нужен! Кроме автоперечитывания шаблона надо ошибки отсутствия блоков превращать в предупреждения и все равно грузить тему. И в этом режиме запретить смену темы админки :)
Ольга, Константин, есть простой финт здорово облегчающий разработку. Шапку своего шаблона правите в последнюю очередь. Т.е. пишите его в индекс.тмл, правите пути к wcss и js, вставляете в область контента блок <--content--> со всеми потрохами из дефолтного, и открываете три/четыре окошка. 1. страница в блоголете с подключеной темой ; 2. кнопка перечитать тему; 3. редактор с шаблоном тмл; 4. редактор с шаблоном хтмл. И начинаете копипастить куски своего шаблона внутрь дефолтной секции. Потом так же с сайтбарами.
Владимир, ИМХО нужен примерно такой текстовый файл - структура дефолтного шаблона БЕЗ хтмл. Только комментарии-секции и переменные после каждой из которых - комментарий с объяснением что это.
//я таки помню про свои обещания и темы переделываю. Время от основной работы появилось. но мука-мученическая на данный момент.
Philipp пишет:
Мне знаком этот финт, еще с года этак 89-го, но по сути своей это всего лишь банальное разгадывание ребуса. В столь удачном движке мне лично хочется видеть очень простой для понимания даже не слишком продвинутого юзера метод создания шаблонов. Когда я делаю шаблоны для упомянутых выше GB TOP'ов, FET'ов, Proton'ов и иже с ними, я сконцентрирован именно на том, как должен выглядеть результат (т.е. именно версткой и ничем больше), а не раскапыванием в образце, что и куда нужно всунуть и гаданием на тему того, что из этого получится. О чем и писал выше. При таком раскладе шаблон, отлизанный и "с нуля", делается за 4-10 часов с подглядыванием в 30 строк документации в качестве шпаргалки.
Надеюсь, мысль понятна.
В догонку... Я вообще в данном вопросе за "минимизацию глобализации" вплоть до возможности ручного формирования виджетов ручками прямо в шаблоне. Проиллюстрирую мысль кусками кода:
<h3>%%POST_TITLE%%</h3>
<div class="time"> Posted: %%POST_DAY%%-%%POST_MONTH%%_%%POST_YEAR%%
<div class="meta_widget">
%%FIFO_LINK%% <br />
%%RSS_GLOBAL_LINK%% <br />
%%RSS_COMMENTS%% <br />
<div id="navigation">
<p class="sidebar_menu"> Навигация </p>
%%CATEGORY_1%% <br />
%%CATEGORY_2%% <br />
%%CATEGORY_3%% <br />
Есть здесь что-либо отвлекающее от верстки либо требующее умения разгадывать ребусы?
Непонятен простой и удобный шаблонизатор на метках с удобной настройкой этих меток. Обычно это приводит к иерархии шаблонов - или кучке файлов, или простыне настроек на пяток экранов. Или к шаблонизатору на областях, что мы сейчас в блоголети и имеем. Лично мне все равно что писать $template.title, ###SITETITLE###, {SITETITLE:short}, <f:title/>.
Глобально сейчас неудобно отсутствие описания шаблона кроме кода :) примерно 60 строк с пояснениями, в 30 никак не уложиться.
Константин пишет:
есть. где задается обертка для категорий? С какой стати это ссылки а не просто текст? Где задается текст сcылки для RSS? Т.е. решение идеально - если жестко зафиксировать целую кучу вещей. да, во многих системах так и сделано.
А я нигде и не говорил про настройку меток, да и нигде не видел таковую, кстати. Метки задаются и документируются разработчиком.
Philipp пишет:
С какой стати это ссылки а не просто текст? Где задается текст сcылки для RSS?
Виноват, хомутнул с примерами. Имелось в виду:
<div class="meta_widget">
<a href="%%FIFO_LINK%%" title="Description">Anchor here</a><br />
<a href="%%RSS_GLOBAL_LINK%%" title="Description">Anchor here</a><br />
<a href="%%RSS_COMMENTS%%" title="Description">Anchor here</a><br />
<div id="navigation">
<p class="sidebar_menu"> Навигация </p>
<a href="%%CATEGORY_1%%" title="Description или %%CATEGORY_DESC_1%% если введено описание категории в админке">%%CATEGORY_NAME_1%%</a><br />
<a href="%%CATEGORY_2%%" title="Description или %%CATEGORY_DESC_3%% если введено описание категории в админке">%%CATEGORY_NAME_2%%</a><br />
<a href="%%CATEGORY_3%%" title="Description или %%CATEGORY_DESC_3%% если введено описание категории в админке">%%CATEGORY_NAME_3%%</a><br />
Спасибо за критику.
шаблонизатор без циклов => привязка темы к проекту и необходимость ее менять после любых изменений структуры данных - не подходит для "невнедряемого" движка
все равно придется переходить к
<p class="sidebar_menu"> Навигация </p>
%%GLOBAL_CATEGORY_LOOP%%
<a href="%%CATEGORY%%" title="Description или %%CATEGORY_DESC%% если введено описание категории в админке">%%CATEGORY_NAME%%</a><br />
%%GLOBAL_CATEGORY_LOOP_END%%
GLOBAL_CATEGORY потому что еще придется вводить POST_CATEGORY - для перебора в теле анонсов и постов => приходим просто к переименованию текущих меток.
Константин пишет:
А я нигде и не говорил про настройку меток, да и нигде не видел таковую,кстати. Метки задаются и документируются разработчиком.
Ну значит мы таки имели дело с очень разными системами :)
Владимир, есть ли в ближайших (недельных) планах какая-нибудь документация по шаблонам?
Для себя я ее уже начал составлять, отпрепарировав дефолтный шаблон, но она в несколько специфичном виде - сниппеты для aptana studio. Если есть заинтересованные в такой форме - по готовности выложу.
(
это кучка файлов вида
<!--
category: !Lite Publisher content section
name: 1. mandatory MAIN CONTENT WRAP
-->
<!--content-->
${selection}
<!--/content-->
)
неявное использование шаблонов - зло!
Я про commontags, который используется и в post, и в excert, а задается непременно в post. И почему-то является общим для тегов и категорий.
Отвечу пока на последнии вопросы про commontags: можно задавать индивидуальные шаблоны как в анонсе (excerpts), так и в посте, и отдельно для категорий и меток. В дефолтном шалоне из за того, что все 4 шаблона одинаковы (анонс и полнй пост = 2 * 2 метки и категории) и было бы как то неудобно и странно дублировать ввел новую сущность commontags. Чтобы изменить общий шаблон для меток и категорий в анонсе то замени $post.tagslinks и/или $tags.categorieslinks на соответствующие секции шаблонов, где вместо секции commontags стоит tags или categories.
Документация, безусловно, будет. Сейчас занят доводкой поддержки тем wordpress - по крайней мере дефолтный шаблон wordpress уже работат, приходится немного править сам движок для разруливания разных моделей тем.
Про дискусию в здесь я не забыл - немного позже дам развернутые ответы на все вопросы
Еще раз перечитал комментарии, и вспомнил, чтоу у меня ранее была нигде не озвученная идея идея минимального шаблона, где все шаблоны не описанные в теккущей теме берутся из темы по умолчанию (как вариант или особой спецтемы). В настоящее время имеется небольшое количество шаблонов, которые если отсутствуют и так берутся стандартные, но этот опыт можно транслировать и на остальные темы. В результате получаем псевдоконструктор тем, где если не хочется разбираться в иерархии шаблонов, то они будут браться стандартные.
Далее про % в названиях. Смысла делать подобное не вижу, скорее можно несложно сделать вариант шаблонов с %, который будет переводится в $object.property, как например %title% = $template.title. Для притязательных можно оформить это все в виде ini файла. На производительности движка такая фича никак не скажется, так как без разницы сколько времени идет парсинг темы (в реальности это занимает едва ли сотую доли секунды, но я немного помешан на оптимизации). Цена вопроса - один/ддва дня работы, но для этого требуются образцы уже существующих шаблонов с % или другими альтернативными описаниями, чтобы я смог составить карту сопоставления, и собственно составление такой карты и займет все это время.
После выхода для тестирования тем wordpress, планирую написать пару статей-документация по тегам и шаблонам тем. Увы после нескольких месяцев гонки по выпуску новой стабильной версии словил откат в виде потери работоспособности...
Напиал перввую статью в серии про темы:
http://litepublisher.ru/doc/theme.htm
буду продолжать, ъхотя на одну статью уходит несколько часов
Блоголётчик пишет:
Да, конечно механизм "based on" иметь в движке было бы очень приятно. собрать в базовой все шаблоны (секции), и потом спокойно сделать несколько компактных вариаций где будут только $object.property и чуть разная верстка или там цвета...
В версии 3.63 ввел полную иерархию шаблонов: тема может иметь родительскую тему (указывается в about.ini parent = themename), родительская темане может иметь родител скую тему (предовращение зацикливания). Все темы по умолчанию имеют в неявном виде родителсккую тему default/default.tml, таким образом цепочка наследования может состоят максимум из двух тем: default.tml, родительская. Сейчас размер index.tml темы по умолчанию разгрузил в 4 раза, оставивь только html верхнего уровня, спрятав все шаблоны в default.tml.
Остался открытым вопрос о шаблонах в стиле %% - я не нашел каталогов таких тем, хотя их поддержка была бы несложной, если у кого то есть ссылки на сайты каталоги пподобных тем, то я был бы признателен за подсказку.
http://blogolet.ru/mysli-o-razvitii-formata-temy.htm
Нашел у себя пару простеньких дефолтных для Blogs Organizer'а в качестве рабочего примера:
http://belturbo.info/dnl/sample-themes.zip
Это самые простейшие шаблоны...
Наверное, какая-то таблица соответствий все-таки подразумевается. Кода я, к сожалению, не видел, скрипт под зендом, да и я уже говорил, что я не програмер. По тегам подробнее.
BOMETA - выводит в хедере служебные теги блога
<link rel="alternate" type="application/rss+xml" title="RSS" href="http://blog_path/rss-feed.php" />
<link rel="sitemap" href="http://blog_path/sitemap.xml.gz" type="application/xml" />
<link rel="archives" title="October 2010" href="http://blog_path/archives-2010-10/" />
<link rel="archives" title="September 2010" href="http://blog_path/archives-2010-09/" />
<link rel="archives" title="August 2010" href="http://blog_path/archives-2010-08/" />
TITLE, DESCRIPTION - банально подставляют значения из админки
POSTS - выдает целиком тело поста согласно шаблону поста примерно такого вида:
<div id="posts">
<h2>%%TITLE%%</h2>
<p>%%BODY%%</p>
%%POSTS_BROWSER%%
</div>
Задается отдельно от остального шаблона.
RECENTPOSTS - выдает список N последних постов по одному в строке (или RECENTPOSTS_LI - в тегах li) без всякого форматирования и преобразования. Выпадающие списки постов для категорий работают аналогично.
TAGCLOUD - понятно, настройка в админке отдельно.
В общем, повторюсь, суть сей идеи в том, чтобы насовать в нужные места любой HTML страницы простейших элементов без всякого внутреннего форматирования, и, что немаловажно, с человеко-понятными названиями. Как в детском конструкторе. И судя по популярности этого скрипта идея работает. Да и на форуме поддержки вопросов по шаблонам практически нет... а это уже говорит о многом...
Володя, если очень хочется поиграться с этим скриптом живьем, я могу дать доступ к рабочей админке. Разумеется, не в паблике. Если есть интерес - сбрось контакты на мыло из профиля.
Что означают теги я то понял сразу - в ссылке несть список всех доступных тегов с коментарием к нему. Я хотел сказать, что такой шаблон прямо сейчас может работать в блоголёте, и мой вопрос был скорее о том, что следует ли включать поддержку подобных тем в движок. Причина прочему нет - отсутствие готовых таких шаблонов, кроме как у тебя. И следовтаельно, последобавления этого типа шаблонов вряд ли появятся новые темы. Или я ошибаюсь?
На вскидку видны следующие проблемы с этими темами: не будет поддержки виджетов и аяксовых виджетов (либо добавить тег %%sitebar%%), невозможность изменить какой либо шаблон в теме - все шаблоны будут брться по умолчанию (в принцип решаемо указанием родительской темы).
Я все-таки думаю, что появятся. Дело ведь не в том, что система шаблонов блоголета чем-то плоха - нормальная система. Я говорю о том, что для среднестатического юзера %%BLOG_URL%% куда понятнее чем $options.url и прочие $options.РАЗНЫЕ_ОПЦИИ, тем паче что это практически нигде толком не документировано. Я в основном говорю про то, что если, например, ввести соответствия типа
$template.keywords - %%keywords%%
$template.description - %%description%%
$options.description - %%print_description%%
$options.name - %%print_name%%
При этом не принципиально, сколько будет таких тегов, 20 или 120. Главное, чтобы они были понятны и хотя бы вкратце описаны. Я думаю, что файлик с описанием работы с темами должен по умолчнию входить в состав дистрибутива. Ну вроде шпаргалки в моем примере. Повторюсь - ну нет практически вопросов по темплейтам ВО, при том что всю "документацию" ты уже видел... :)
и т.д. Лично мне как просто пользователю (а я думаю, что и не только мне :) ) не очень хочется вникать, что чего и откуда наследует... "просто юзеру" надо прикрутить темплейт на свой блог с минимальными трудозатратами. "Просто юзеру" просто не интересны классы и синтаксис РНР, он делает блог (сайт) для того, чтобы набить его каким-то контентом - и именно этот аспект занимает его в первую очередь.
Володя, ты мыслишь как [i]программист[i]. Естественно, что для тебя все просто понятно. А для большинства юзеров многие слова вроде "пиашпи" как ругательство... :) Я больше 10 лет обслуживал компьютеры, и теперь меня уже не удивляют вопросы от "юзеров со стажем" типа "где папка Мои документы?" или ответы "...я сохранил это в компьютер", "Тотал Командер слишком сложный..." и т.п. В онлайне средний уровень не намного выше... Я согласен, что грустно это, но такова реальность, и с ней приходится считаться.
С конца - вовсе не грустно, это нормально, движок должен решать проблемы, а не порождать новые. С самого начала шаблоны были узким местом движка, к настоящему времени немного поправил, но все равно остаюсь неудовлетворенным. ДОбавить поддержку таких тем мможно за 1-2 дня, назвать этот тп тем как то "simple", или еще как то, тип темы указывается в about.ini - по умолчанию сейчас это не обязательный
type = litepublisher
допустимым считается еще ндоделанный
type = wordpress
просто добавлю тип
type = simple
или навать tpl, или еще как?
и ИМХО таки надо ввести явную нумерацию сайтбаров. А еще бы их конфигурацию... (максимальное число виджетов, типы виджетов)
Кстати, к списку тегов... В упомянутом мною примере кроме всех прочих есть теги ONLYINDEX и ONLYINNER. Очень удобные в определенных случаях. Я бы еще добавил что-то вроде ONLYINCATEGORY:cat_id(cat_name), т.е. показывать только в определенной категории. Очень удобно для размещения контекстной рекламы, тематических ссылок и прочей "узкой" информации в мультикатегорийных блогах.
И еще маленькая просьба - не делай, пожалуйста, под тегами никаких внутренних форматирований/преобразований, пусть все это определяется только стилями темплейта. То есть если это SITENAME, к примеру, то пусть это будет просто фраза. А шрифт-цвет-выравнивание-регистры пусть определяются только в темплейте (или CSS файле). Тогда будешь точно знать, что все, что касается визуального отображения на экране, может находиться только в index.tml или style.css, и нигде больше.
Philipp пишет:
Может быть, добавить теги вроде SIDEBAR:LEFT(RIGHT,BOTTOM)-END_SITEBAR и WIDGET:NAME(screen_name)-END_WIDGET?
Хотя по своей привычке строить темплейт руками не вижу проблемы скопипастить кусок HTML кода и внутрь насовать что нужно. Все просто и очевидно, в любой момент на результат взглянуть можно, благо что это обычный HTML файл. Имхо барство это - виджеты из админки гонять по темплейту, зачем движок на такую ерунду напрягать-то... :) Это же очень редко надо, дизайн же не меняется каждый день...
Хотя WIDGET:NAME(screen_name)-END_WIDGET можно ввести, это ведь просто пустая рамка для наполнения... Но тогда где-то надо определять кусок кода, соответствующий этим командам. Не проблема, конечно. Может быть и было бы удобно писать в темплейте что-то типа
WIDGET:menu(Навигация)
%%CATEGORIES%%
END_WIDGET
WIDGET:recent(Недавние)
%%RECENT_POSTS,15%%
END_WIDGET
Ну так это уже чуть ли не макро-язык получается, а надо ли оно? Не знаю...
Philipp пишет:
SITENAME - это просто. А POST_DATE к примеру?
Philipp пишет:
На полную дату надо в любом случае формат где-то в админке задавать, или сделать несколько предустановленных. Или вообще сделать конструктор %%DAY%%, %%MONTH%%, %%YEAR%%, %%HOUR%%, %%MINUTE%% - и складывай, как пожелаешь...
Константин пишет:
Сами себе противоречите, однако :) Мы же о непрограммистах говорим, так?
Но я ни в коей мере не отрицаю потребности в таковой возможности, - я же оговорился сразу, что сие ИМХО.
Я тоже, кстати, ни разу не программист, последние из немногих строчек написал в 1989. Поэтому для меня РНР местами сложноват. Несложный код прочитать, конечно, могу, а вот править и дописывать - увы...
Добавить поддержку тегов с процентами могу уже в сегодняшнем релизе, тип будет назваться alias, карта перевода тегов вот здесь
http://litepublisher.googlecode.com/svn/trunk/lib/include/aliases.ini
карту еще не доделал,потому что возникли вопросы (в файле видно где):
- контекст тегов - одноименные теги, например %%TITLE%%, как различить где дляпостов и заголовок страницы неясно
- чуствительность к регистру - она есть или нет? Все теги в заглавных буквах, мне лично это неудобно
- набор тегов для выбора блога, когда как блоголёт одноаккаунтный движок
- абсолютно непонятно зачем теги для виджета ссылок, точнее понятно, но по мне бесполезны
Работать такая тема будет следующим образом: все %% теги заменяются на соответствующие теги блоголёта из карты, после чего будет обычный разбор темы, то есть будет на лету конвертация такой темы в тему блоголёта (именно поэтомуому я писал о целесообразности подобных тем). Следовательно такая тема сохранить все свойства темы блоголёта, а конкретно наследование шаблонов.
Про виджеты - можно разрешить управлять виджетами из темы, но тогда как быть с управлением виджетами из админки? ЕК тому же половина виджетов в подобной теме неизвестны, например трекер ключевиков. Однозначно противоречие - если в другой теме для блоголёта будут отсортированы виджеты, то что должно произойти при смене темы на эту тему? Устанавливать виджеты из темы и игнорировать из админке?
Что ксается дат - в темах блоголёта трехуровневый формат дат:
1. языковой файл lib/languages/ru.ini
2. в теме секция dateformat - есть для постов, анонсов икомментов
3. админка настройка/локализация
Для поддержки тем alias для поста добавил теги $post.day, $post.month, $post.year - все это будет в новом релизе. Про форматирование в тегах - сейчас по моему движок вообще никак не ксается форматирования, все отдается на откуп темы, где все настраивается.
Володя, нет слов! Мы тут все вместе за тобой не поспеваем. :)
Может быть, банально сделать %%post_title%% and %%page_title%% ?
Имхо не принципиально, можно все сделать маленькими буквами или просто не чуствительными к регистру. Это вроде бы ничего не меняет?
Это специфические теги ВО, в Блоголете они не нужны. По второму - в ВО есть простенький менеджер обмена ссылками, обрезанный вариант http://lo.cheapestwebsoftware.com/, эти теги - для него.
Повторюсь в своей просьбе насчет тега ONLYINCATEGORY:cat_id(cat_name), т.е. показывать только в определенной категории. Если это возможно, добавь пожалуйста.
Как по мне... Как правило, тема на блог ставится один раз и меняется крайне редко, во всяком случае я лично не вижу смысла менять темы раз в три дня. Поэтому я бы для данного типа тем управление виджетами из админки отключил. Собрал тему в HTML файле, поставил, и пусть работает. Главное чтобы тегов хватало на все случаи жизни. Из админки можно оставить только наполнение каких-либо виджетов (каких - сходу не соображу), а порядок/сортировку отключить. Конечно, это сугубо личное мнение.
То есть строгого соблюдения именования тегов не требуется?
По моему, это чисто технический момент, юзера не касающийся. Я думаю, что нет.
теги для постов некуда вставлять, то есть шаблон для анонсов и полного поста придется брать из родительской темы, это же касается и шабонов виджетов, и всего остального.
Как это мне видится, шаблоны для полного поста, анонсов, "оболочки" (оформления рамки то бишь) виджета должны где-то задаваться в теме - либо отделенные какими-то спец. тегами в общем шаблоне, либо явно в отдельных файлах, например post.tml, widget.tml, excerpt.tml...
Я сопротивляюсь встроенным виджетам в тему потому, что обязательно появятся желающие, чтобы было как в шаблоне для блоголёта - управлять через админку. С другой стороны если делать как обычную карту тегов, то смысла в темах алиас отсутствует полностью.
Да я в общем-то о том и говорю в основном, про карту тегов в первую очередь. То есть я про то, чтобы как минимум ввести соответствия типа
$template.keywords - %%keywords%%
$template.description - %%description%%
$options.description - %%print_description%%
$options.name - %%print_name%%
чтобы не гадать, чем отличается $template.description от $options.description и т.д., а просто вставлять в темплейт удобопонимаемый тег. Может быть, для начала просто сделать карту кратко документированных тегов? Я так понимаю, что технически это самое простое решение?
Попробую саккумулировать идею еще раз.
1. Общая идея - быстро сделать темплейт из любой HTML страницы.
2. Заменить для разработчика темы всё РНР-шное вида $options.ЧТО_ТО и т.п. на удобопонимаемые документированные теги.
3. Сделать для разработчика список кратко документированных тегов на все случаи жизни, которые позволяет движок.
4. Теги могут вставляться как в темплейт, так и в кастом виджет, футер и т.д. через админку. То есть управление виджетами не трогаем.
5. Подробно документировать вместе с тегами использование <!--simple-->, <!--current-->, <!--item--> и т.д. - что, где, как и для чего используется.
То есть можно дать разработчику выбор - полная поддержка через админку, либо редактор темы.
Честно говоря, я так далеко не шел в своих мыслях, но мне лично идея нравится. Хороша для тех, кто не планирует менять тем вообще или делать это крайне редко (блоги под САПУ, сателлиты и т.д.).
- шаблон темы статичен, управление виджетами из админки, АЯКС(?) отсутствуют;
- шаблон темы не предполагает никаких наследований, все задается явно в отдельных файлах post.tml, comment.tml, widget.tml, excerpt.tml, admin.tml посредством HTML и тегов (п.3). Шаблон админки можно взять, скажем, из дефолтной темы и не менять его никогда - а зачем?
Также я против использования условных тегов для включения/исключения
Момент удобный, но не принципиальный, коли существует возможность использовать разные темы для главной и категорий.
http://litepublisher.ru/task/temy-alias.htm