Как получить настройки темы ($theme_settings) на странице? Есть решение
Речь об информационных страницах (/site/#/pages/).
Не доступны значения $theme_settings, как их получить? Пробовал в начало index.html добавить {$wa->globals('theme_settings', $theme_settings)} , но {$wa->globals('theme_settings')} возвращает null в коде контента страницы.
И заодно как подтянуть локализацию из темы?
49 ответов
Пока никак, https://developers.webasyst.ru/forum/22154/podderz...
Да и похоже данная тема никому больше не интересна
Ну а если в коде, то копать в эту сторону
public static function getThemeSettings() { $theme_id = waRequest::getTheme(); $theme = new waTheme($theme_id, 'shop'); return $theme->getSettings(); }Хм.. а какой это класс? не могу найти этот метод.
ну вот теперь нас двое) если никто ничего не подскажет буду копать, а то не порядок)
Это не класс, это пример кода, делаешь минимальный плагин и в нем данную статичную функцию, и собственно вызываешь где нужно.
{$settings = shopMypluginPlugin::getThemeSettings()}
Вы довольно глубоко копнули, не хватило самой малости:
{$theme_id = waRequest::getTheme()} {$theme = waTheme::getInstance("$wa_app/themes/`$theme_id`")} {$theme_settings = $theme->getSettings()}По моему необязательно делать плагин. Можно хелпер сделать и разместить его в classes приложения.
Я уже привел пример как обойтись без создания класса. Размещение своих классов в папках приложений это не самое удачное решение, лучше добавить свой класс в автозагрузку и разместить в отдельной папке.
Я видел... не сразу понял просто. А почему не самое удачное решение? Из-за того, что при обновлении может затереться? А ну да еще же в одном месте все свои классы будут лежать...
Затереться как при обновлении так и при переустановке. + Так классы будут доступны из любого приложения.
{$theme_id = waRequest::getTheme()} {$theme = waTheme::getInstance("$wa_app/themes/`$theme_id`")} {$theme_settings = $theme->getSettings()}не работает теперь, кстати :)
Ага, wa от большого ума заблокировали вызов статичного метода getInstance для всех классов.
Как заблокировали? в Smarty чтоль?
Ага, https://support.webasyst.ru/25302/izmenenie-v-poli...
Поддерживаю, было бы неплохо, если бы разработчики упростили доступ к настройкам темы или вынесли некоторые сущности по-другому.
Зачем странице знать настройки темы, которые у всех тем разные?
Чаще всего используется одна тема т.ч. особых проблем нет.
Зачем странице знать настройки темы?
Ну, например, в теме задается id формы подписки, а на странице выводится форма с этим id. Или на странице выводится список товаров, его id и порядок сортировки по умолчанию задаются в настройках темы.
Ситуаций можно придумать множество, я уже не помню ситуацию в которой это понадобилось именно мне, но точно помню по другому не решалось.
можно для этого использовать дополнительные параметры страницы
Зачем использовать доп.параметры страницы на самой странице? Проще тогда уж сразу значение в коде прописать))
Удобнее и логичнее хранить все настройки в одном месте, а именно в настройках темы.
А как ты собираешься получать доп.параметры страницы? :)
А как ты собираешься получать доп.параметры страницы? :)
Конечно же через мой плагин)))))
Тема может записать в глобальную область видимости параметры, оттуда их можно забрать вроде.
Я больше всего не люблю эти комментарии с припиской "вроде". Не уверен? Не пиши.
При чем тут область видимости и smarty шаблоны?
Ну проверил я все! Все верно! Не пишется потому что сначала происходит рендер контента страницы, а уже после все готовое отдается на обработку в тему, соответственно тема записывает значение позже чем чем происходит рендер.
Но все равно ваша идея бред!
С тем же успехом тогда давайте объекты моделей бд в шаблоны пихать и напрямую данные получать!
Не надо путать мягкое с тёплым, объект используется только потому что другого способа получить эти настройки нет.
Страница никак не должна зависеть от настроек темы, если тему сменить, все накроется. Как говорят в ООП- избегайте зависимостей
Если клиент, так хочет, то это уже его проблемы.
Если клиент так хочет, то надо ему объяснить что так делать нельзя! Программирование не ресторан, клиент конечно всегда прав, но есть рамки куда клиент лезть не должен!
А еще говорят что не стоит работать с мудаками....
Так что если клиент хочет сделать произвольные запросы к бд стоит задуматься, а надо ли с таким работать и какие проблемы принессет такое сотрудничество!
Интересная у тебя позиция по данному вопросу) Вот тут ты предлагаешь делать как хочет клиент, а не как нужно)
Лично я в использовании настроек темы на страницах не вижу никаких проблем, к сожалению теперь придется реализовать это как-то по другому.
Там я хочу обеспечить защиту от дураков и отловлю ошибок на системном уровне, чтобы было легче работать с ошибками как разработчикам, так и самим клиентам, чтобы сайты не падали!
Защита от дураков это блокировка удаления плагинов, используемых в активных темах, а то что вы предлагаете это как раз идти на встречу дуракам.
Ты предлагаешь сделать мега анализатор кода тем дизайна ,блоков, страниц и тд??????? Вперед!
Готов лично вложить 5000 р от себя в твой анализатор, если он будет хорошо работать!
Какой-то там мега анализатор не требуется, ведь речь о выявлении в шаблонах вызовов статических методов плагина т.е. по сути нам нужно проверить упоминается ли класс плагина appMypluginPlugin.
Сам класс я могу тебе за пару часов написать, вопрос только в том кто его в фреймворк добавит.
Ты не видишь всей картины! Почему только в темах? Не забудь про блоки, страницы и шаблоны плагинов, например в моем плагине есть вывод методов плагина картинка как на али, текстура к характеристикам и также можно вставить любой плагин для продукта!
Так что задача шире чем тебе кажется!
А я разве об этом где-то написал?
Если твой плагин или приложение будет реализовывать интерфейс с методом проверки на наличие вызова стороннего плагина, то без проблем.
Вот в темах как раз и должна быть эта самая проверка!
Эта проверка должна быть вызываться при удалении\отключении плагина т.е. в инсталлере.
1 вопрос: Ты видел магазины где стоит порядка 120 плагинов и 40 тем?
2 вопрос: Ты же в курсе что шаблоны могут в базе храниться?
1. Я не представляю зачем магазину 40 тем, поведай))
Проверить 100 плагинов не проблема - можно использовать waLongActionController
2. Я уже писал: если плагины\приложения будут наследовать интерфейс с методом проверки на наличие вызова плагина в шаблонах, то конкретная реализация плагина\приложения значения иметь не будет.
Если хочешь обсудить эту тему, то создай отдельный пост.
Если очень хочется делать костыли, то можно делать так https://support.webasyst.ru/13923/sovmestnye-khelp...
А если сайт в облаке WA? :D
да, проблема, но супер плагином набора хелперов решается)
Его вначале нужно в магазин добавить, а это не так быстро - клиент пару недель ждать не будет. Это и привело к созданию данного костыля.
Ну короче все ясно, из-за одного неадекватного клиента, вебасист должен реализовать хотелку... Не будет такого!)))
При чем тут вообще вебасист? я по этому поводу ничего им не предлагаю)
Получится один большой супер костыль!
Если нужно достать vk, twitter, instagram на страницах магазина, то делаем следующее:
1) создаём файл shopCustom.class.php в папке /wa-apps/shop/lib/classes
2) помещаем в файл следующее содержимое
<?php class shopCustom { public static function getThemeSettings() { $theme_id = waRequest::getTheme(); $theme = new waTheme($theme_id, 'site'); return $theme->getSettings(true); } }3) на странице магазина в самом вверху добавляем
{$theme_settings = shopCustom::getThemeSettings()}4) далее как обычно