Адаптация шаблонов под 0.4
52
Я уже переделывал шаблон под 0.4, но делал это в несколько заходов, к тому же, начал делать тогда, когда сама конструкция еще не устаканилась, и что-то приходилось переделывать несколько раз.
Теперь, как я понимаю, резких телодвижений в обозримом будущем быть не должно. И можно уже смело паковать чемоданы, готовя «нольтришные» сайты к переезду на 0.4. Надеюсь, все с пониманием относятся к тому, что нет пока внятной документации — не до того пока ребятам. Поэтому я сейчас попробую описать отличия в шаблонах для версий 0.3 и 0.4. Думаю, это будет полезно тем, готовится к переезду.
Что же нужно переделывать в шаблонах?
1. HTML-заголовки
В шаблонах почти не осталось явных ссылок на css и js-файлы.
В шапке шаблона (header.tpl) было много подобных строк:
Если вы ничего не поняли из статьи, ссылку на которую я дал, и чтение конфиг-файла так же ничего не прояснило в голове, то никто вам, конечно, не запретит прописывать файлы стилей и скриптов явно в шаблоне, чтоб получить требуемый результат, но это будет совсем не зер гут.
А вообще в большинстве случаев вполне достаточно просто взять и заменить файл header.tpl на новый из скина new для версии 0.4 (т.к. там есть еще несколько скриптовых блоков, которые тоже надо перенести).
2. Меню
Раньше меню вставлялось в шаблоне header_nav.tpl такой комбинацией:
Если этого не сделать, то на первых порах, возможно, неприятностей не будет, но в будущем «замучаетесь пыль глотать», отыскивая, почему же в некоторых плагинах меню не отображается.
3. Маршрутизация (ссылки)
Раньше, если мы хотели поставить ссылку, скажем, на блоги, то в шаблоне писали так:
4. Параметры конфигурации
Раньше константы, которые прописаны в конфиге, надо было явно передавать во вьюер (некоторые из них передавались автоматически), и только после этого можно было на них ссылаться. Т.е. дя того, чтобы обратиться к адресу сайта в шаблоне надо было использовать переменную {$DIR_WEB_ROOT}. Например, так:
Теперь обращение ко всем параметрам конфигурации стандартизировано, и выглядит так:
Это обращение к параметру, который в файле конфигурации config.php описан так:
Но в некоторых случах нужно не просто вставить в шаблон значение параметра конфигурации, а использовать его, напрример, в конструкции {if ...}...{/if}. В таких случаях функция вьюера {cfg ...} работать не будет, и надо использовать экземпляр объекта $oConfig:
5. Формы
Во все формы должно быть добавлено новое поле:
Вот, собственно и все.
Итак, краткое резюме
Чтобы переделать скин с 0.3 на 0.4 надо сделать следующее (и именно в таком порядке!):
1) заменить (или переделать) шаблон header.tpl, добавить новую конструкцию с меню в header_nav.tpl
2) заменить конструкции вида {$DIR_WEB_ROOT}/{$ROUTE_PAGE_BLOG}/ на {router page='blog'}
3) для оставшихся переменных/констант вида {$DIR_WEB_ROOT}, {$DIR_STATIC_SKIN} и т.д. найти соотвествующие параметры в новом config.php и подставить в шаблон в виде {cfg name='path.root.web'}, {cfg name='path.static.skin'} и т.д. Там, где эти переменные/константы используются в выражениях (т.е. в конструкциях {if ...}) их надо заменить на такую комбинацию: $oConfig->GetValue('path.root.web'), $oConfig->GetValue('path.static.skin') и т.д.
4) после всех этих манипуляций у вас еще могут остаться в шаблонах старые переменные/константы вида $ROUTE_PAGE_INDEX, $ROUTE_PAGE_PERSONAL_BLOG и т.д., так вот их можно заменить просто на соответствующие строковые константы — 'index', 'personal_blog' и т.д.
5) везде, где в шаблонах есть встречается такая комбинация:
UPD Дополнил текст с учетом замечаний Алексея
Теперь, как я понимаю, резких телодвижений в обозримом будущем быть не должно. И можно уже смело паковать чемоданы, готовя «нольтришные» сайты к переезду на 0.4. Надеюсь, все с пониманием относятся к тому, что нет пока внятной документации — не до того пока ребятам. Поэтому я сейчас попробую описать отличия в шаблонах для версий 0.3 и 0.4. Думаю, это будет полезно тем, готовится к переезду.
Что же нужно переделывать в шаблонах?
1. HTML-заголовки
В шаблонах почти не осталось явных ссылок на css и js-файлы.
В шапке шаблона (header.tpl) было много подобных строк:
<link rel="stylesheet" type="text/css" href="..." />Сейчас они заменены одной переменной:{$aHtmlHeadFiles.css}Аналогично эти строки:<script type="text/javascript" src="..."></script>Заменены на эту переменную:{$aHtmlHeadFiles.js}Каким образом файлы стилей и скриптов попадают в эти переменные, читайте здесь: Если вы ничего не поняли из статьи, ссылку на которую я дал, и чтение конфиг-файла так же ничего не прояснило в голове, то никто вам, конечно, не запретит прописывать файлы стилей и скриптов явно в шаблоне, чтоб получить требуемый результат, но это будет совсем не зер гут.
А вообще в большинстве случаев вполне достаточно просто взять и заменить файл header.tpl на новый из скина new для версии 0.4 (т.к. там есть еще несколько скриптовых блоков, которые тоже надо перенести).
2. Меню
Раньше меню вставлялось в шаблоне header_nav.tpl такой комбинацией:
{if $menu}
{include file=menu.$menu.tpl}
{/if}
Теперь это надо делать так:{if $menu}
{if in_array($menu,$aMenuContainers)}
{$aMenuFetch.$menu}
{else}
{include file=menu.$menu.tpl}
{/if}
{/if}Если этого не сделать, то на первых порах, возможно, неприятностей не будет, но в будущем «замучаетесь пыль глотать», отыскивая, почему же в некоторых плагинах меню не отображается.
3. Маршрутизация (ссылки)
Раньше, если мы хотели поставить ссылку, скажем, на блоги, то в шаблоне писали так:
<a href="{$DIR_WEB_ROOT}/{$ROUTE_PAGE_BLOG}/">Теперь это делается так:<a href="{router page='blog'}">4. Параметры конфигурации
Раньше константы, которые прописаны в конфиге, надо было явно передавать во вьюер (некоторые из них передавались автоматически), и только после этого можно было на них ссылаться. Т.е. дя того, чтобы обратиться к адресу сайта в шаблоне надо было использовать переменную {$DIR_WEB_ROOT}. Например, так:
<a href="{$DIR_WEB_ROOT}">Теперь обращение ко всем параметрам конфигурации стандартизировано, и выглядит так:
<a href="{cfg name='path.root.web'}">Это обращение к параметру, который в файле конфигурации config.php описан так:
$config['path']['root']['web'] = '...'Т.е. то, что в конфиге дано в квадратных скобках, в шаблоне мы указываем через точку.Но в некоторых случах нужно не просто вставить в шаблон значение параметра конфигурации, а использовать его, напрример, в конструкции {if ...}...{/if}. В таких случаях функция вьюера {cfg ...} работать не будет, и надо использовать экземпляр объекта $oConfig:
{if $cmtlevel>$oConfig->GetValue('module.comment.max_tree')}В этом примере запрашивается параметр конфигурации$config['module']['comment']['max_tree']5. Формы
Во все формы должно быть добавлено новое поле:
<input type="hidden" name="security_ls_key" value="{$LIVESTREET_SECURITY_KEY}" />Это необходимо для корректной работы системы безопасности ЛС.Вот, собственно и все.
Итак, краткое резюме
Чтобы переделать скин с 0.3 на 0.4 надо сделать следующее (и именно в таком порядке!):
1) заменить (или переделать) шаблон header.tpl, добавить новую конструкцию с меню в header_nav.tpl
2) заменить конструкции вида {$DIR_WEB_ROOT}/{$ROUTE_PAGE_BLOG}/ на {router page='blog'}
3) для оставшихся переменных/констант вида {$DIR_WEB_ROOT}, {$DIR_STATIC_SKIN} и т.д. найти соотвествующие параметры в новом config.php и подставить в шаблон в виде {cfg name='path.root.web'}, {cfg name='path.static.skin'} и т.д. Там, где эти переменные/константы используются в выражениях (т.е. в конструкциях {if ...}) их надо заменить на такую комбинацию: $oConfig->GetValue('path.root.web'), $oConfig->GetValue('path.static.skin') и т.д.
4) после всех этих манипуляций у вас еще могут остаться в шаблонах старые переменные/константы вида $ROUTE_PAGE_INDEX, $ROUTE_PAGE_PERSONAL_BLOG и т.д., так вот их можно заменить просто на соответствующие строковые константы — 'index', 'personal_blog' и т.д.
5) везде, где в шаблонах есть встречается такая комбинация:
<form action="POST" ...>
...
</form>перед тегом </form> надо вставить такую строку:<input type="hidden" name="security_ls_key" value="{$LIVESTREET_SECURITY_KEY}" />UPD Дополнил текст с учетом замечаний Алексея
- +26
- 03 февраля 2010, 12:21
- avadim
Сразу дополнение к пункту #3.
Иногда параметры конфигурации приходиться вызывать в альтернативных конструкциях IF. Так нельзя использовать функцию cfg, но зато можно пользоваться объектом $oConfig:
В данном случае запрашивается значение из
Еще добавил бы п.4. В формах, отправляющих POST запросы должно быть введено новое hidden-поле для обеспечения работы системы безопасности движка:
Аналогично с некоторыми action-ссылками.
Пункт 5. Не забывайте про оформления меню и необходимость поддерживать «контейнеры», иначе в скине могут не все плагины нормально работать. Сейчас пример вы можете увидеть в header_nav.tpl (раньше на этом месте была другая конструкция):
Иногда параметры конфигурации приходиться вызывать в альтернативных конструкциях IF. Так нельзя использовать функцию cfg, но зато можно пользоваться объектом $oConfig:
{if $cmtlevel>$oConfig->GetValue('module.comment.max_tree')}
В данном случае запрашивается значение из
$config['module']['comment']['max_tree']
Еще добавил бы п.4. В формах, отправляющих POST запросы должно быть введено новое hidden-поле для обеспечения работы системы безопасности движка:
<input type="hidden" name="security_ls_key" value="{$LIVESTREET_SECURITY_KEY}" />
Аналогично с некоторыми action-ссылками.
Пункт 5. Не забывайте про оформления меню и необходимость поддерживать «контейнеры», иначе в скине могут не все плагины нормально работать. Сейчас пример вы можете увидеть в header_nav.tpl (раньше на этом месте была другая конструкция):
{if $menu}
{if in_array($menu,$aMenuContainers)}{$aMenuFetch.$menu}{else}{include file=menu.$menu.tpl}{/if}
{/if}
Алексей, уточни, плиз, поле security_ls_key в формах является обязательным или желательным? Т.е. без него данные формы не будут обрабатываться вообще или будут, но с угрозой для безопасности?
security_ls_key является обязательным в формах и в ссылках, отправка на сервер которых (переход по которым) приводит к выполнению действия (добавление\редактирование\удаление и т.д.).
В поисковых формах, например, смысла в них нет =)
Но все равно нужно помнить про них, потому что ошибка «недоставленного» security-ключа при «натяжке» макета трудно диагностируема.
В поисковых формах, например, смысла в них нет =)
Но все равно нужно помнить про них, потому что ошибка «недоставленного» security-ключа при «натяжке» макета трудно диагностируема.
Очень интересно, спасибо!
Но есть вопрос не совсем по теме. Как работает security key? То есть я так понимаю, он при каждом обновлении страницы меняется или при при каждом использовании. Потом на стороне сервера он с чем-то сравнивается, например с самом собой. То есть мы выдаем пользователю строку, если он ее же возвращает, то это норм пользователь. Это ведь защита от XSS атак. Но ведь любой XSS-хакер легко может парсить этот код со страницы и возвращать, так же?
Где-то в моей логике дыра, залатайте ее пожалуйста, очень интересно!
Но есть вопрос не совсем по теме. Как работает security key? То есть я так понимаю, он при каждом обновлении страницы меняется или при при каждом использовании. Потом на стороне сервера он с чем-то сравнивается, например с самом собой. То есть мы выдаем пользователю строку, если он ее же возвращает, то это норм пользователь. Это ведь защита от XSS атак. Но ведь любой XSS-хакер легко может парсить этот код со страницы и возвращать, так же?
Где-то в моей логике дыра, залатайте ее пожалуйста, очень интересно!
Надеюсь я могу задать дополнительный вопрос здесь?
Систему понял, очень интересна. Но она обеспечивает выполнения действий авторизованного пользователя, только по его действительному волеизъявлению.
А как защитить сайт, если пользователь авторизовался, парсит этот код и с другого скрипта у себя на серве, в авто режиме добавляет спам сообщения? Рефер не спасет.
Систему понял, очень интересна. Но она обеспечивает выполнения действий авторизованного пользователя, только по его действительному волеизъявлению.
А как защитить сайт, если пользователь авторизовался, парсит этот код и с другого скрипта у себя на серве, в авто режиме добавляет спам сообщения? Рефер не спасет.
Когда же уже будет доступен 0.4? Жду с декабря 2009 года, уже 3-й месяц.
Тут только и говорят о версии 0.4, а где оно есть, нету же?
Тут только и говорят о версии 0.4, а где оно есть, нету же?

- prometheus
- 06 февраля 2010, 20:51
- ↓
Комментарии (17)
RSS свернуть / развернуть