Темы alias
14.10.2010Голосование
| Тип | Задача |
| Состояние | Исправлено |
| Приоритет | Средний |
| Версия | 3.98 |
| Система | * |
| Воспроизводимость | Нет |
| Автор | Блоголётчик |
| Исполнитель | Блоголётчик |
В новой версии 3.98 ввел поддержку тем типа alias. Вроде как работает. но требует тестирования, уточнения и прочего. Карта алиасов находится в файле
_http://litepublisher.ru/source/lib/include/aliases.ini
RSS комментарии к этой записи
Рубрики: Задачи
Комментарии (65) на запись “Темы alias”
Оставить комментарий
Попробовал вкрутить новую тему - не удалось. Навскидку:
- не работает управление виджетами;
- расползается админка;
- не понял, как задать формат поста;
- не работают теги раздела "post" (или я чего-то не понял...);
- по тегам %%posts%% и %%sitebar%% структура берется из дефолтной темы, из default.tml. Можно, конечно, найти и перековырять это и там, но неправильно это. В чем тогда смысл тегов?
Я раскомментироал index.tml и default.tml, недоделанная тема здесь:
http://belturbo.info/dnl/regeneracy.tar.gz
И так, в общем... идеей наследования не проникся, система "элемент дизайна = отдельный файл (секция в файле)" и "админка неизменна" по прежнему кажутся наиболее простым и логичным решением.
С конца - можно сделать спецтему для админки и ставить ее в инсталяторе, но вот отлючать возможность смены темы админки - ккой в этом смысл/польза? Только уменьшение степени свободы и все.
Изначально я писал, что не представляю для чего нужны темы alias - ты обяснял это удобством именования тегов. Шаблоны берруся из родительской темы. Все темы по умолчанию наследуются от default/default.tml - оттуда берутся все недостающие шаблоны, а поскольку в алиасе отсутствуют шаблоны (только шаблон всей страницы - больше там ничего нет), то все шаблоны получаются из дефолтной темы. Как рраз жаловался на отсутствие алгоритма описания шаблонов в алиасе - это можно делать только таким же способом как для всех тем блоголёта. Пока что это вложенные секции из html комментариев. Я уже размышлял, что подобные секции не являются самоописательными, но это уже отдельная проблема.
Я только мельком просмотрел работу темы - сразу много багов, например с постом что то неладное и т.д.
<b>это можно делать только таким же способом как для всех тем блоголёта. Пока что это вложенные секции из html комментариев.</b>
Можно живой пример, как это сделать? Потому что пока шаблоны берутся из одного файла, где сам черт ногу сломит, блоголет имеет только одну тему. Наследовать что-либо с форматированием из какого-то файла неправильно в принципе, все форматы должны задаваться только в самой конкретной теме. Наследовать можно только, имхо, единую хорошо отлаженную админку. Все остальное - в теме. Кстати, в 3.98 после отключения Hover Menu отказались работать все линки в админке, кроме верхних. Плагин был не установлен (с установленным - то же самое), броузер - Опера 9.64 Linux, админка - дефолтная.
Наследуются те шаблоны, которые отсутствуют - живой пример это в теме по умолчанию два файла default.tml и index.tml, , где во втором перекрываются наследуемые из default.tml шаблоны. На самом деле можно было вообще ничег не наследовать, так как во обоих случаях шаблоны абсоллютно одинаковы и такое наследование сделано как демо пример.
Наприме для задания своего шаблона поста необходимо обявить секцию content, а в ней секцию post в которой и расписывать шаблон полного поста. Аналогично для других шаблонов. Для алиас темы следует удалить тег %%posts%% и вставить туда секцию content си внутри него секцию post
Попробовал. В варианте:
<!--content-->
<!--excerpts-->
<!--excerpt-->
<div class="postbody">
<h2 class="title"><a href="%%CLEAN_LINK%%">%%CLEAN_TITLE%%</a></h2>
<p class="meta"><span class="date">%%DATE%%</span><span class="posted">Posted by <a href="#">%%AUTHOR%%</a></span></p>
<div style="clear: both;">&nbsp;</div>
<div class="entry">
<p>%%BODY%%</p>
</div>
%%POSTS_BROWSER%%
</div>
<!--/excerpt-->
<!--/excerpts-->
<!--post-->
<div class="postbody">
<h2 class="title"><a href="%%CLEAN_LINK%%">%%CLEAN_TITLE%%</a></h2>
<p class="meta"><span class="date">%%DATE%%</span><span class="posted">Posted by <a href="#">%%AUTHOR%%</a></span></p>
<div style="clear: both;">&nbsp;</div>
<div class="entry">
<p>%%BODY%%</p>
</div>
%%POSTS_BROWSER%%
</div>
<!--/post-->
<!--/content-->
частично заработало, но все равно, похоже, где-то идет "наложение" по стилям. Более глубоко лезть пока физически нет времени. Вывод - непростительно заморочно для массового движка.
Саккумулирую идею еще более сжато:
- наследование похоронить как классово вредный элемент, вносящий путаницу;
- сделать редактор шаблонов с окошечками для каждого шаблона (header, post, main, footer, comments etc... ), где будет выдаваться код для редактирования. Куда и как это будет писаться - без разницы.
- заменить всё начинающееся со значка бакса в шаблонах на теги с понятными названиями и краткими описаниями;
- написать подробную и понятную каждому не программисту с базовым знанием HTML (иные и не будут шаблоны ковырять) документацию по адаптации шаблонов;
- админку сделать одну на все случаи жизни, простую, вылизанную от багов и надежную, как молоток (в 3.95 глючит - писал выше), без всяких новомодных приблуд, работающую в любых броузерах и системах - это рабочий инструмент, свиристелки здесь не обязательны.
Из-за админки ставил последний блог на 3.49 - душа радуется. Кстати, визуальное ощущение, что работает быстрее. Кстати, подпиши в инсталяторе радио-кнопки "с MySQL" and "без MySQL", как-то диковато смотрится.
- сделать нормальный серверный (не путать с онлайновым) инсталятор и онлайн-апдейтер, нормально расставляющие права на папки и файлы. Не тупо 777 на все, а 777 и 666 только на то, что реально необходимо в данный момент (апдейтер), на все остальное - 444/644/755. В особенности 444 на все index.***, туда в первую очередь и-фреймы и трояны сажают. Я знаю, что все index.htm в папках требуют 666... ну так заменить на какой-нибудь blg.htm, что ли.
Константин пишет:
Не-а. Тем для Вордпресса клепают немеренно, и чем дальше - тем сложнее и навороченней.
А наследование - холить и лелеять как единственный способ создавать семейства тем.
Есть серверный инсталятор:
http://litepublisher.googlecode.com/svn/trunk/utils/install.php
также в readme написаны две волшебные строчки для шела, которые загружают на сервер движок со всеми правами. Наследование вещь отличная, просто сейчас отсутствуют шаблоны откуда можно наследовать. Темы алиас эксперемент, и да - секции в html комментариях неудобны, вчера писал парсер для новой модели шаблонов, о чем я писал в посте про мысли. Тема будет самодокументированной.
Делать редактор шаблонов - это практически нереально, из за большого количества шаблонов, на вскидку в секции content верхний уровень это
А ВОТ СЕКЦИЯ POST
Далее шаблоны виджетов, где в каждом виджете шаблон контейнера, списка, элемента списка.
Для каждого из этих шаблонов и шаблончиков можно сделать редактор. Сейчас подумал, что можно сделать редактор следующего вида: слева колонка с дереввом шаблонов (чтобы было ясно иерархия шаблона - реализация любая, например хотя бы вложенные списки по клику), а справа один редактор текущего выбранного шаблона. Вещь должна получится интересной, но вот реализация боюсь займет больше чем новая модель шаблонов...
Что касается темы для админки - я не умею писать темы (текущую тему по умолчанию я заказывал за деньги), и пожэтому подвижек в этом направлении от меня вряд ли будет. А почему 3.4х админка лучше?
Про инсталятор - движок может поддерживать несколько типов бд а не только mysql, и почему нынешняя подпись нелепа? Кроме шуток - почему?
С конца.
Нынешняя подпись не нелепа - я просто не увидел вообще никаких подписей, просто две голые радиокнопки и поля ввода инфы для базы данных.
Админка - в 3.49 нормально работает при отключенном Hover menu. В 3.95-98 у меня глючила - писал выше.
Шаблон админки - дефолтный хорош, ничего изобретать не надо, просто он должен работать независимо. Простой пример: убираю из дефолтного темплейта верхнее меню, и оно исчезает и в админке. Это есть гуд?
Древовидный редактор шаблонов - это звучит очень интересно. Важен принцип - чтобы можно просто увидеть нужный кусок кода с краткими пояснениями.
Насчет наследования - возможно, соглашусь, если будет внятный редактор шаблонов со внятным описание команд / тегов. Пока - только для профессиональных разработчиков тем. Для остальных - муть и геморрой.
Две волшебные строчки для шела - а много блогов на дедиках/VDS у простых юзеров? На виртуалах есть доступ к шеллу?
Я про тот, который должен идти в составе дистрибутива. Предложенный качает дистрибутив и лепит на все 777 / 666.
Константин пишет:
37+-обсчитался тем портировано за полтора (ладно, 2) месяца. (Усилиями в основном 2х человек, за что им отдельное спасибо). Лиха беда начало.
Philipp пишет:
37+-обсчитался тем портировано за полтора (ладно, 2) месяца. (Усилиями в основном 2х человек, за что им отдельное спасибо). Лиха беда начало.[/quote]
Если не сложно, скинь линки, пожалуйста.
По поводу наследования опять... Понял наконец причину своего инстинктивного отторжения оного, спасибо Philipp'у в #8 ("...семейства тем").
Просто в данный момент присутствует одна концептуальная ошибка - все завязано на тему default, которую нельзя удалять из-за default.htm, из которого все "потроха" и наследуются. То есть на базе этого можно одно семейство тем, например def-blue, def-red, def-sky и т.д.
Если условный дизайнер Вася (УДВ) захочет сделать свое радикально новое семейство тем vasya-* на базе шрифта Comic Sans 18px, то он все равно получит "начинку" (структуру виджетов, постов и т.д.) в Arial'е 15px из default.htm. Ибо - наследование... Перепахать default.htm? Можно, но тогда ВСЕ темы, в т.ч. и семейства def-* получат "начинку" от тем vasya-* от УДВ.
Выводов всего два:
- каждый дистрибутив темы должен содержать в себе default.htm родительской, default-def.htm, default-vasya.htm и т.д.
- все темы не могут быть завязаны на /themes/default/default.htm, ибо это будет "блог одного семейства тем".
В итоге приходим к тому, что, как ни крути, каждый дистрибутив темы должен содержать index.tml aka main template и файл default.htm со "потрошками". Но тогда что мешает разбить код по основным категориям по файлам post.tml, widget.tml, sidebar.tml, comments.tml - и уже можно обойтись без мудреных редакторов тем. И наследование никуда не делось - копируй тему vasya-def
и меняй только index.tml - остальное снаследуется. В "наследстве" что-то поменять тоже не проблема, хоть ясно в каком файле искать.
Ок, протестирую всплывающее меню и исправлю. Файл themes/default/default.tml запрещено редактировать каким либо образом - в нем находятся абсолютно все шаблоны и как следствие некоректное изменение этого файла может вести к краху всей системы. По умолчанию абсолютно все темы наследуются от default/default.tml, но любая тема может наследоваться от другой, для этого в файле темы about.ini в секции about прописывается строка
parent = themename
Достаточно написать одну базовую тему, где прописать все не совпадающие с темой по умолчанию шаблоны, чтобы потом ее наследовать. Таким образом получаем семейство тем, которые могут не имет ничего общего с темой по умолчанию. Тему по умолчанию удалять нельзя - на нее автоматом переключается движок если не найдена текущая тема (например удален каталог темы). Уровней наследования всего 2:
Сейчас для автоматического обновления требуются права 666 и 777 на абсолютно все файлы: весь дистрибутив при обновлениизаливается поверх и для данных тоже требуются большие права. Возможно, когда обновление будет идти через ftp к самому себе, то права можно будет понизить. Да, я встречал и пользовался шаред хостингом с шеллом, но правда шелл выделяется на шареде по запросу и часто требовали обоснование. Я сейчас на вдс. В дистрибутив сейчас входит батник для Windows который автоматом загружает все файлы на сервер.
В форме инсталяции радиокнопки сделаны так:
<p><label>
<input id="dbversion" name="dbversion" type="radio" value="1" onclick="changedbversion(1);" checked="checked"/>
$lang->dbversion</label></p>
Что всегда обеспечивало подпись к радиокнопке, но проверю, может сбились языковые переменные.
С наследованиемтем все проще - по умолчанию все темы наследу
Файл themes/default/default.tml запрещено редактировать каким либо образом - в нем находятся абсолютно все шаблоны и как следствие некоректное изменение этого файла может вести к краху всей системы.
Имхо неправильно это. Все равно периодически кто-то будет сносить и удивляться.
По умолчанию абсолютно все темы наследуются от default/default.tml, но любая тема может наследоваться от другой, для этого в файле темы about.ini в секции about прописывается строка
parent = themename
Достаточно написать одну базовую тему, где прописать все не совпадающие с темой по умолчанию шаблоны, чтобы потом ее наследовать. Таким образом получаем семейство тем, которые могут не имет ничего общего с темой по умолчанию...
Уровней наследования всего 2:
default/default.tml
parent из файла about.ini (если есть)
А как "сказать" движку, что новая тема является базовой, т.е. что наследовать все надо из this_theme/default.tml? Или по другому - как задать НЕСКОЛЬКО базовых тем?
Тему по умолчанию удалять нельзя - на нее автоматом переключается движок если не найдена текущая тема (например удален каталог темы).
Вот это хорошая функция, только я бы ее отделил от дефолтной темы (продублировал где-то в недрах движка, где юзеру делать просто нечего), это ведь чисто вопрос работы движка, страховка. Юзер тут ни при чем. А дефолтную тему тему сделал бы удаляемой.
Сейчас для автоматического обновления требуются права 666 и 777 на абсолютно все файлы: весь дистрибутив при обновлении заливается поверх и для данных тоже требуются большие права.
Это-то понятно. Я про другое:
Инсталятор:
- install.php грузится c дистрибутивом;
- запускается и ставит все с правами 777;
- потом устанавливает нормальные (минимально необходимые) права.
Апдейтер:
- ставит на все права 777;
- обновляет;
- потом снова устанавливает нормальные права.
Константин пишет:
В ссылках на блоголет.ру Будет время и переделаю больше одной темы - тоже туда попрошусь :)
http://litepublisher.GOOGLECODE.COM/svn/trunk/themes/default/theme.txt
Рекомендую взглянуть хотя бы меьком - тема получается одновременно с документацией к ней, появится это в течении нескольких дней. ООстанется полная совместимость со старыми темами. Думаю что в таком формате станет на порядок легче разрабатывать новые темы
В новом формате темы редакция темы не приведет к краху, скорее к отсутстввию контента. Редактировать можно все что угодно, в том числе и тему по умолчанию, если соблюдать формат.
Тема, которая может стать базовой (родительской), не должна сама наследоваться, то есть в ней должно отсутствовать в ABOUT.INI parent, либо быть пустая строка. Сделано это для предовращения зацикливания наследования. Родительская тема может объявить абсолютно все шаблоны, либо часть - остальная часть будет браться из темы по умолчанию.
Скрипт автоинсталяции устроен достаточно примитивно - ему нужно писать в корень сайта, и да, для файлов нужны максимальные права 666, а на папки 777 - я с этим поделать ничего не могу, чтобы можно было писать в файлы. Это однозначно не безопасно. Наверно в будущем через FTP к самому себе будет безопаснее.
http://litepublisher.GOOGLECODE.COM/svn/trunk/themes/default/theme.txt
Даже не знаю... И очень здорово, и при этом по-моему у любого редактора с проверкой синтаксиса крышу снесет - а это лишние ошибки и лишний копи-паст... т.е. идеология меняется с "берем ХТМЛ и вставляем теги" на "берем заготовку темы и вставляем в нее куски ХТМЛ и туда опять теги"
И при этом - замечательная документация по темам получается!
Как пример тем "валидный ХТМЛ с метками" http://typo3.org/extensions/repository/view/tt_news/current/info/?tx_terfe_pi1%5BdownloadFile%5D=res%252Ftt_news_v3_template.html
(осторожно, юниксовские переводы строк ЕМНИП)
Да, проверил - у Аптаны например крышу сносит наполовину - т.е. подсветка работает, но проверка синтаксиса идет нафиг... Но в принципе приемлимо. Возможно хорошей мыслью было бы таки иметь 2 файла - один - общий (для template{}), и второй - с подшаблонами.
Ссылка побилась в предыдущем комментарии. Сейчас сокращу. (возможно надо учесть, что ссылки с подчеркиваниями и амперсендами фильтр комментов не любит)
Вот http://bit.ly/aRtBlP .
Константин пишет:
Правильно ли я понял, что вопрос можно поставить так: как указать, что эта конкретная тема ничего ниоткуда не наследует? Как я понимаю, для этого нужно чтобы в самой теме были все используемые в ней подшаблоны - тогда наследования не происходит автоматически.
Да, Владимир, а кстати - все надо указывать в index.tml или можно и в теме задать default.tml ?
Правильно ли я понял, что вопрос можно поставить так: как указать, что эта конкретная тема ничего ниоткуда не наследует?
Правильно. И что можно наследовать из нее. Т.е. приравнять ее в правах с ныне существующей дефолтной.
Возможно хорошей мыслью было бы таки иметь 2 файла - один - общий (для template{}), и второй - с подшаблонами.
Ну мне тоже все равно более логически стройной и понятной почему-то кажется система, как я излагал в #13.
При использовании нормального (показывающего структуру документа - outline) редактора разбиение на много файлов смысла не имеет.
Разбиение на 2 смысл имеет почему:
1 шаг. Берем готовый HTML-шаблон и заменяем часть кусков на теги. Имеем грубое приближение (5-10 минут в настроенном редакторе).
2 шаг. Начинаем тонкую подгонку шаблона (классы, тонкости метки). тут вобщем все равно сколько файлов, но делать как сейчас, в том же файле что и основной шаблон не совсем удобно. Плодить 10-20 файлов тоже плохо - уменьшение скорости работы, да и в редакторе больше 2-3 открытых держать... От 10 минут до часа-двух - зависит от количества наворотов, наличия дополнительных яваскриптос и т.п. ...
Тема всегда наследует шаблоны и по умолчанию такой темой является тема по умолчанию. В случае желания полностью отказаться от всех наследуемых шаблонов их необходимо прописать в своей теме - тогда ее дочерние темы будут наследовать именно ее шаблоны. Неперекрытые шаблоны будут наследоваться без изменений. Для прояснения еще раз напишу по другому: расмотрим два случая тем - с наследованием и без
Таким образом получается максимум двузвеная цепочка наследования:
Если нет родительской темы - вычеркиваем пункт 1.
А куда ее выносить то? Выносить просто некуда, по мне ей самое место в папке тем.
Теперь про новый формат: Как вариант для больших шаблонов думал приделать внешние файлы, например сделать для все страницы целиком:
$template = [ file=index.html ]
Другое дело, что встречаются вложенные шаблоны, которые могут начисто ломать верстку для редакторов. Я то не пользуюсь никакими html редкторами - все в аналоге блокнота делаю. Ну предположим, что комментарии можно закавычивать в html комментарии (это так - можно любой текст вне тегов, как сейчас). Мне этот формат понравился еще тем, что в дочерней теме достаточно будет прописать только перекрываемые шаблоны, например новый шаблон заголовка страницы, тогда файл такой темы будет состоят из одной строки:
$template.title = [Крутой сайт$title]
Опять же я мыслю как програмист. Предложи какой либо вариант с самоописанием тегов? Имеется в виду формат. Как гипотитический тег можно было бы декларировать так:
[CODE]
<!--$template.title = [-->
...html ШАБЛОНА...
<!-->
Тогда новый формат будет не сильно отличаться от существующего, но разборщик темы будет удалять абслютно все комментарии.
Блоголётчик пишет:
Про дефлтную тему :
Тогда бы хорошо (если позволяет хостинг) после установки и обновления менять права на нее и на файлы в ней в ридонли. Как защита от дурака.
Сое ИМХО про тему я написал (про 2 файла). Идеальная тема должна быть максимально приближена к чистому ХТМЛ. Есть кстати такие шаблонизаторы. Только там назначать элементв приходится через xpath-нотацию (например /html/body/*/span[@class]), что геморой еще тот.
Дальше: чистый XTML в который вставлены теги вида (а все равно какого) {{TAG}} или ###TAG### или %%TAG%%, и (или) конфигурируемые области типа сайтбаров выделены html-комментариями. Настроек у тегов нет! В общем, с точностью до обозначений - нынешняя модель Блоголета. Основная сложность начинается дальше: вывод тегов надо конфигурировать. Для этого или делают тучу форм в админке, или пишут конфигурационный файл (файлы). ИМХО самая удобная модель, и именно к ней ты собственно и пришел. Единственно что - да , для большинства удобней писать вместо $options.files/files/$filename что-то вроде {{PATH_TO_FILE}}.
Что касается файла конфигурации - а он мне очень понравился, если и правда добавить в него включение файлов. Мне кстати будет вполне удобно и без замены переменных на теги, поэтому более удобный вариант предложить затрудняюсь...
Вот рассматриваю сейчас его и все больше он мне нравится :)
Единственное изменение - я бы пожалуй сделал разметку в CSS-стиле, то есть вместо например POST_CONTENT = [...] сделать POST_CONTENT {...} , а вместо
$template = [ file=index.html ] TEMPLATE {@import(index.html)} ... как-то так.
Каким должна быть идеальная тема?
Мое представление:
- несколько окошек в админке: main, post, comments и т.д. с соответствующей выборкой кода. Количество - не важно, можно сгруппировать на несколько страниц.
- в коде только понятные теги без каких-либо настроек/опций и стандартный HTML/CSS код. Ни одной конструкции типа $template = [ file=index.html ]. Верстальщик может не знать ни одной буквы из PHP, но это не должно мешать ему работать.
- наследование - не далее родительской темы, не надо верстальшику думать, все ли он перекрыл и откуда какая-то хрень вылезла. Соответственно, файловая структура - два файла, main и все остальное, пусть будет default.htm. Файл default.htm - "наследство", нет его - идем на родительскую. Есть - берем все из него. Хочешь сделать новую родительскую тему - копируешь default.htm в новую папку и пашешь его как хочешь, что-то не перекрыть или потерять можно только сдуру. Соответственно нужды в дальнейшем наследовании из дефолтной нет, только путаницу создаст.
- админки в теме нет по определению - либо из дефолтной, либо вообще отдельная песня.
**
Володя, предлагаю приближенный оценочный критерий. Ты писал, что HTML тебе чужд и не очень понятен? Это отлично. Тыкаешь в любой темлейт на http://www.freecsstemplates.org/css-templates/, и если получается минут за 20-30 запустить новый блог идентичного вида (т.е. с новой родительской темой, с тем же форматированием, шрифтами и т.д.) - система в основном удобна.
Потом проводишь такой эксперимент на ком-то, знающем HTML и не знающем РНР и блоголета. Если человек справится за час-два - система точно удобна.
В BlogOrganizer'е, который я тебе приводил не раз приводил в пример, такое получается, причем руководствуясь только подсказками на странице. Не задумываясь даже об устройстве темы и каких-то спец.форматах.синтаксисах. По такому принципу работает еще немало скриптов.
Philipp, дефолтную тему я бы вынес дублем в папку lib, чтобы именно на нее автоматом переключался движок, если не найдена текущая тема (аварийный режим). А тема в папке default - обычная тема, как и все, без всяких привилегий.
В настоящий момент в новой модели можно использовать по личному выбору любые из 3 видов скобок: [], {}, (). Я выбирал квадратные из за того, что не нужно жать shift на клавиатуре, но писать абсолютно любые, лишь бы внутри шаблона количество открытых было равно количеству закрытых - просто - как я в предыдущем комменте писал до html комментария, чтобы можно было найти конец шаблона. скобки можно расширить до нескольких символов
В lib ничего выносить нельзя - эта папка запрещена через .htaccess для доступа из web. На самом деле тему по умолчанию редактировать то можно - лишь бы редакция была коректной. Алгоритм отката на тему по умолчанию существует с самого начала движка и до сих пор не было жалоб на откат к теме по умоллчанию. Насчет наследования - не могу согласиться. Если хочется абсоллютно все новые шаблоны, то просто берется исходный файл из темы по умолчанию и правиться. Шаблоны по умолчанию вещь очень полезная - как я ни старался все равно приходится вносить изменения в формат темы, например добавление нового шаблона, и при очередном обновлении новый шаблон появляется в теме по умолчанию и как следствие по цепочке наследования п всем остальным темам. Как вариант можно предложить запрет наследования от темы по умолчанию. Так или иначе можно дискутировать о наследовании.
Новый формат темы не имеет ничего общего с php - ну кроме символа $ в начале тега, но по мне это несущественная мелочь. Нуа какой вариант указания внешнего файла можешь предложить. Моя конструкция вида file=filename это так, что в голову сразу пришло, могу с import сделать или несколько вариантов одновременно.
Редактор в админке - да, но только как вспомогательное средство, которое бы писало результаты в файл темы. В первой версии блоголёта некоторые шаблоны хранились в ini файле - страшно неудобно выяснилось.
Насчет быстрого создания темы из любого шаблона - в этом тикете есть файл темы (неважно, что он толком не работает) и сделать такой шаблон может любой, но для таких шаблонов скорее больше нужен облегченный вариант шаблонов по умолчанию, где бы присутствовали упрощенный html шаблоны, которые подходили под большинство тем. Все же нынешняя тема по умолчанию несколько специфичная (могу наверно только это предпологать).
Основной посыл понял - подключаемые файлы больших шаблонов, редактор шаблонов. Вариант с самодокументированной темой вполне устраивает? Меня он точно устраивает - когда писал новую тему с документацией к ней прямо в тексте темы мне казалось, что подобная тема снимит большинство вопросов.
Насчет быстрого создания темы из любого шаблона - в этом тикете есть файл темы (неважно, что он толком не работает) и сделать такой шаблон может любой...
Увы, Володя, на данном этапе это не работает, именно из-за наследования получается полная ерунда, я же посылал тебе образец... Будет это работать только в варианте наследования не далее своей папки или редакторе шаблонов в админке.
Вариант из #19 гораздо понятнее, но конструкции типа $options.url$url все-таки мне лично глаз режут. И все таки на мой взгляд сложновато. Детально не ковырял, со временем просто цейтнот, но сказать, чтобы вот так пролистал и в общем-то понял - таки нет. Это, кстати, в каком виде хранится будет - одном файле или нескольких? Все-таки окошки в админке с конкретизироваными кусками кода - это необходимость "намбер ван". Ничто, кстати, не мешает, сделать это просто отдельной тулзой и не впихивать в движок.
Володя, моя логика проста, как мычание. Чем проще и быстрее слепить шаблон, тем больше
их будут делать и тем больше использовать движок. Больше будет фри шаблонов, пусть зачастую кривоватых... но они будут, и в купе с библейской простотой адаптации новых шаблонов это привлечет новых пользователей. Движок-то сам ой как хорош... Поэтому в моем понимании это первоочередная задача. Все изыски и навороты - потом.
BlogsOrganizer - это самая удобная модель из всех мною виденных, ибо только полный валенок не сумеет собрать там темплейт. И практически полное отсутствие слова template на форуме саппорта тому доказательство. Добавь к тому, что скрипт платный и отнюдь не дешевый - за свои деньги люди бы душу вынули с разработчика, если бы что не так.
ИМХО: сейчас все упирается не в сложность-простоту шаблонов, а в отсутствие полной документации по ним. Будет - уж тьюториал "Сделай блог за полчаса" я напишу.
Константин, или я или вы неправильно понимаете наследование.
Владимир, если я правильно понимаю линия наследования такая:
index.tml темы -> index.tml родительской темы (если задана) -> default.tml из default
Так или ошибся?
ЗЫ. Наиболее популярные бесплатные движки спокойно живут с ПХП-темами, зачастую с жуткими макаронами - и ничего... /друпал, джумла, вордпресс / Главное - документация! И собрать начальную толпу активистов :)
Шаблон я смотрел - с первого раза ничего не понял, отложил, сегодня еще раз смотрел - опять не понял, придется делать третью попытку...
Что касается именования тегов - я сейчас подуал и сделаю поддержку по умолчанию альтернативного именования тегов, то есть $post.title будет эквивалентно %%post_title%%,также будет упразднено в шаблонах $options - ЗАМНЕНО НА БОЛЕЕ ЕСТЕСТВЕННОЕ $site, таким образом получится теги $site.url, $site.name и их альтернативные названия %%site_url%%, %% site_name%%, также в шаблонах надо будет предусмотреть полный адрес элемента вместо сложения двух адресов - сайта и элемента. Может быть типа full_url, но не знаю точно, надо подумать. Тип алиас можно назвать бесполезным эксперементом - для следующих тем будет одновременная, то есть смешанная поддержка таких тегов, это не сложно, всего лишь одно регулярное выражение. Это ксается составных тегов, для мелких шаблонов, где используется $url, $title МОЖНО НАВЕРНО сделать теги вида %%item_url%%, %%item_title%%.
Наверное я привел весьма неудачный пример.
Все по именованию тегов - отлично!!!
Про наследование - именно так.
Думаю, что новый формат темы решит вопрос с документацией - одновременно это будет и рабочая тема, и документация и примеры к документации.
Пока есть возможность и движок не популярный надо сделать формат темы максимально простым - чем больше популярность, тем жестче требования обратной совместимости. Ведь такая штука - просто сделать любые вещи сложными, но сложно сделать сложные вещи простыми.
В маркдауне есть code в двух вариантах:
здесь действует какое то другое правило с подчеркиванием или процентами, надо будет их добавить в конвертатор мнемоник html
В течении нескольких дней - сейчас пишу парсер нового формата и детально работаю со структорой шаблонов, есть мысли по улучшению, например заменить $post.categorieslinks на просто $post.categories, и так далее.
Сама же версия не ожидается скоро - запланировал другие изменения, будет несколько бета версий недоступных для автоматического обновления, также изменен index.php в корне сайта и остальное
Имеется в виду тексты на языках, тогда можно несколькими путями:
Этот вопрос меня навел на добавление пользовательских тегов прямо в теме без использования плагинов - например тот же ini файл, либо теги которые будут перекрываться в дочерних темах, сейчас существующее множетство тегов является жестко фиксированным.
Блоголётчик пишет:
А я писал, а я писал :) :)
Правда я это называл свойствами (настройками) темы, но это уже детали :)
Тогда можно дойти до изменения значений из темы, ну например
$site.name = "Мое временное название сайта"
И теоритически таким образом можно будет повлиять на работоспособность движка, скорее даже на безопасность. И встает вопрос - тема это данные или код. С другой стороны можно позволить вводить новые теги, которые никак не могут повлиять на работу движка, так как движок о них ничего не знает. Конечно в рассуждениях о безопасности есть доля лукавства - плагины это исполняемый код. Думаю можно в теме завести секцию custo, где можно будет добавлять любое количество тегов, обращение к ним будет $custom.myname (или в процентах, но маркдаун корежит, в том числе и текст поста). Где и как потом употребялять эти теги остается на плечах разработчика темы. Эти теги будут видны только в одной теме и ее дочерних темах.
В случае кастом тегов это будет как-то так наверное - менее удобно чем прямое редактирование из админки, но в общем приемлимо если документировать:
theme.txt:
...
$custom = {@import(custom.tml)}
...
custom.tml:
введите название цветовой гаммы - возможные значения green (зеленый), blue (синий)
color = {green}
соответственно в редакторе тем пользователь не лезет в большие шаблоны а редактирует маленький файлик несколько строк.
<code><code>
theme.txt:
...
$custom = {@import(custom.tml)}
...
custom.tml:
введите название цветовой гаммы - возможные значения green (зеленый), blue (синий)
color = {green}
</code></code>
$custom.myname = [..html...]$admin.custom.add = [$name = 'myname]
$title = [установка значений для myname]$type = [combo]
$values = [value1, value2...]]это то, что быстро придумалось
http://litepublisher.googlecode.com/files/litepublisher.4.00.beta.zip
где реализован новый формат тем и поддержка видов
Несколько вопросов по новому формату тем в v.4beta4 после прочтения документации.
.
- какова роль index.tml? Это просто совместимость со старым форматом? - в доках он не упомянут никак.
Будет ли понята движком конструкция вида:
а) выносим content.admin = [........ из секции content
б) декларируем шаблоны
$template = {@import(main.htm)}
$admintemplate = {@import(admin.htm)}
$custom.admintpl = [$admintemplate] (надо ли?)
......
в) в файл admin.htm вставляем
<html><head>
.........
<body>
content.admin
..........
г) дальше "поплыл" :) - как сделать, чтобы при обращении к админке вызывалось именно оно, т.е. полный темплейт только из файла admin.htm...
$custom.siteurl = [%siteurl%] = [$site.url]
с дальнейшим использованием в main.htm %siteurl% вместо $site.url ? Или как-то по другому на уровне темплейта это сделать можно?
А идея с самодокументированной темой - просто супер, снимаю шляпу...
Сейчас в папке themes/default находятся новая и файлы старой темы, когда будет релиз стабильной, то эти файлы удалю - оставались когда писал новый формат и надо было копировать шаблоны из старого формата. Сейчас точка входа к теме находится в about.ini параметр
file = theme.txt
можно указать любой другой отличный от theme.txt файл, либо сделать для каждого языка свою тему. В некотором будущем я переведу на английский theme.txt и тогда в папке будет два файла с одинковыми шаблонами, но с документацией на разных языках.
Чтобы в админке были свои собственные сайтбары надо в настройках вида "Админка" указать, что вид имеет свои собственные виджеты и накидать виджетов для вида админки. Сейчас после инсталяции есть 3 вида:
можно добавлять свои и удалять старые, вид по умолчанию не удаляем. Путь через собственные виджеты вида является логичиски правильным, но если хочется сохранить общие виджеты, то для редактируемых виджетов рекомендую использовать php скрипт:
<?php if (!litepublisher::$urlmap->adminpanel && !litepublisher::$urlmap->is404) {?>
... любой html код, например адсенс или банеры
<?php } ?>
При задании шаблонов можно прямо в тексте темы их задавать, как это сделано для всех шаблонов, кроме шаблона всей страницы, поэтому для шаблонов админки следует поступать абсолютно также, а именно:
content.admin = {@import(admin.htm)}
То есть нужно точно соблюдать имя шаблона, а именно здесь это content.admin (или более длинная его запись $template.content.admin - $template. можно опускать, как об этом написано в документации). Для custom симметрично, но спасибо за напоминаие - надо будет их потестировать: их добавил в формат, а тестов еще ни одного не делал. Для шаблонов админки доступны всего лишь несколько шаблонов, которые перечислены в документации (например editor, text, checkbox, combo) и других шаблонов там нет. Если нужнен новый шаблон всей страницы, то это будет уже новая тема. Шаблон content.admin предназначен для тех случаев, когда тема исползуется в админке.
Конструкция $custom.siteurl = [%siteurl%] = [$site.url] не будет понята, а будет понята как %siteurl%. Что ксается % то любые шаблоны можно использовать в формате с % вместо $, а именно%%site_url%% вместо $site.url То есть точка внутри заменяется на подчеркивание вначале и в конце два %. Поскольку многие шаблоны (если не все) позволяют использовать внутри себя других шаблонов, то можно вставлять любыевложенные шаблоны, но это надо тестировать и в случае чего просто мне сообщить, чтобы я подкрутил движок нужным образом. Все таки формат темы приходится дорабатывать
http://litepublisher.googlecode.com/files/litepublisher.4.00.zip
которую я уже считаю стабильной пока не опровергнуто утверждение), где реализовал древовидный редактор всех шаблонов в админке.