ClientConfig + Fenom в разных контекстах

Заметил, в одном контексте (web) в документе и шаблонах переменные из настроек ClientConfig выводятся, а в другом контексте (в любом, отличном от web) — нет. Т.е. если это настройки системные — все норм, а если ClientConfig — то пусто — UPD -это происходит кратковременно при очистке кеша ресурсов и обновлении URI- ссылок.

{$_modx->config.may_mail_1} или {$_modx->config['may_mail_1']} — переменные из ClientConfig в контексте web, в ресурсах все норм, в других контекстах проблемы — пусто
[[++may_mail_1]] переменные из ClientConfig, но стандартный тег- все норм во всех контекстах
{$_modx->config.site_name} — системная настройка, все норм во всех контекстах

~~В шаблонах все нормально.~~ — UPD те же проблемы

У кого то еще есть такие проблемы?
(~~MODX Revolution 2.5.2-pl и pdoTools 2.7.5-pl.~~ MODX Revolution 2.5.4-pl, pdotools-2.7.5-pl)

UPD 09.01.2017, создал объявление о работе

Владимир

24 декабря 2016, 07:33

6 568

Комментарии: 28

Здоров Александр

24 декабря 2016, 13:10

только что на сайт с несколькими контекстами поставил clientconfig и вывел тестовую переменную, отобразилась везде, но правда выводил по классике:

[[++perem_name]]

P.S. вот так тоже вывелось

{$_modx->config.perem_name}

Владимир

24 декабря 2016, 13:14

по классике

— вот у меня стандартными тегами все норм, а феномом -нет ((, и ошибок нет в логе.
Т.е. у вас феномом вывод переменной ClientConfig в конексте отличном от web все нормально, точно? Важно, это только вопрос по ресурсам, не шаблонам и не чанкам.

Здоров Александр

24 декабря 2016, 13:17

{$_modx->config.primer}

вставил сейчас это в содержимое страницы контекста docs и вывел значение тест
и в содержимом и в шаблоне, сейчас даже чанк проверю, вот даже в чанке во всех контекстах вывел переменную из конфига

Владимир

24 декабря 2016, 13:21

Спасибо, Александр!
Буду тогда искать источник чудес…
Кстати, я не написал, у меня MODX Revolution 2.5.2-pl и pdoTools 2.7.5-pl. У вас так же?
ClientConfig — в репозитариях одна версия.

Здоров Александр

24 декабря 2016, 13:30

нет, админка пока 5.1, обновлю отпишусь по результатам, pdotools свежий
P.S. обновился, все на месте и все прекрасно себя чувствует, ошибок в логах нет

Владимир

24 декабря 2016, 13:32

2. 5.1 уже пора бы обновить), а то «гости незваные» прямо пешком нагрянут.

Владимир

07 января 2017, 13:03

Вернулся к данному вопросу, увы, задрал он меня. Ни как не найду где источник проблемы.
Сделал на clientconfig панель управления выводом нужной инфы для менеджеров (т.е. то что и является назначением clientconfig, они указывают ID разделов, минусуют ресурсы, включают разные блоки и т.п.), в web — все прекрасно, но стоит сбросить кеш или обновить URI- ссылок — страницы в контекстах отличных от web теряют все настройки. Это минуты на две- три. Потом восстанавливается.

PS думал это связано с ошибкой

model/modx/modx.class.php : 991) `` is not a valid integer and may not be passed to makeUrl()

, да, оно связано, но не как причина, а как следствие, ибо там есть передача ID из clientconfig в шаблон для создания ссылки

{$_modx->config['qwerty_id'] | url : ['scheme' => 'full']}

, ну, соответственно все параметры передаваемые через clientconfig оказавшись пустыми и вызывают такую ошибку…
А вот как устранить причину, не пойму :(

Максим Кузнецов

07 января 2017, 13:28

{$_modx->config.название}

— мне помог такой вариант. Работает в любых контекстах, как с кэшем, так и без него.

Владимир

07 января 2017, 13:33

Вчера только все {$_modx->config.название} переписывал на {$_modx->config['название']}, ибо сначала именно как будто стабильно работало, но после очередного обновления URI- ссылок все оказалось одинаково. А сайт сейчас активно переделываю и сброс кеша и ссылок частая процедура.
PS Буду на модхосте на тестовом пытаться повторить эту же проблему.

Владимир

07 января 2017, 13:42

Андрей П

07 января 2017, 13:46

У меня работает так {'название'|option}

Владимир

07 января 2017, 14:01

Так, кстати, не пробовал. Проверю.

Владимир

07 января 2017, 14:37

Проверил, увы, только родной тег MODX [[++название]] — вот так всегда работает и в контекстах отличных от web тоже. А хочется что бы работало с феномом. Чищу кеш, обновляю uri — через раз обязательно отваливаются настройки clientconfig вызванные феномом {'название'|option}, {$_modx->config.название}, {$_modx->config['название']} — все «отваливаются», независимо от передаваемых данных.

Владимир

09 января 2017, 10:12

создал объявление о работе для решения данного вопроса

Кирилл

09 января 2017, 11:31

А такой вариант не пойдет?

{$_modx->getPlaceholder('+название_опции_клиентконфиг')}

Владимир

09 января 2017, 12:19

Привет полностью вопрос решает предложенное Володей, т.е. просто указать приоритет 1 для плагина ClientConfig. Все гениальное просто, а я панику поднял :))
НО! вот этот

{$_modx->getPlaceholder('+название_опции_клиентконфиг')}

синтаксис, как ни странно, работает наряду с родными тегами MODX, т.е. это тоже годное решение.
С меня магарыч!)

Sergey (Sentinel)

04 апреля 2018, 10:58

Подскажите, для какого события Вы ставили приоритет 1?
У меня такая же проблема, я ставлю для OnMODXInit приоритет 1 и все равно не работает…

Владимир

04 апреля 2018, 11:05

приоритет для плагина ClientConfig

Sergey (Sentinel)

04 апреля 2018, 11:07

А можете подсказать где именно это прописывается?

Владимир

04 апреля 2018, 11:12

если установлен AdminTools, то в древе, в плагинах есть кнопка типа «гамбургер», жми и откроется окно, там все понятно.
Вот такой синтаксис, как выше упоминалось, тоже помогает решить эту проблему

{$_modx->getPlaceholder('+название_опции_клиентконфиг')}

, если что.

Sergey (Sentinel)

04 апреля 2018, 12:59

Еще ответьте пжл на вопрос, у вас выводится к примеру pdoMenu если берет parents из другого контекста?

Владимир

04 апреля 2018, 13:04

вообще нет проблем с контекстами, ну для пдоменю можно в вызове сниппета конекст конкретно указать

Abu

24 января 2017, 18:04

Заметил ещё один неприятный баг при работе Fenom с Clientconfig. При включенном плагине Clientconfig не обрабатываются любые вызовы Fenom в контенте ресурса или вложенных в контент чанках.

Причем проявляется это только если браузер не авторизован в контексте mgr, случайно обнаружил в приватном режиме не работает, прям мистика. Отключаю clientconfig всё работает, поигрался с приоритетами, пока безрезультатно.

Владимир

24 января 2017, 18:43

нет такого, проверил, ни чего подобного не наблюдаю

Abu

24 января 2017, 19:48

Спасибо за фидбек, Clientconfig не виноват. Его удаление удаляло элемент вызова Analytics, который как раз-таки не вызывается в mgr отсюда и магия, всю голову сломал. Где-то Analytics там в общем мешается.

Шаблон чистый

<!doctype html>
<html lang="en">
    <head>
	 [[!Analytics?
        	&setAccount=`111`
        ]] // или через runSnippet
    </head>
    <body>
        {$_modx->resource.content}
        </body>
</html>

И в контенте fenom уже не парсится. Удаление Analytics решает проблему, над его копать, чего он там хочет.

http://s8297.h7.modhost.pro/
login: s8297
pass: z6S4FguioEzx

Abu

24 января 2017, 20:24

А феном как обычно жаловался на фигурные скобки, которые надо изменить путём изменения (создания) чанка ua_tracking (ga_tracking), пробелами перед после { } и т.п.

Валентина Павлова

26 февраля 2022, 12:40

Может, надо переустановить дополнение под контексты?

Андрей

26 февраля 2022, 13:00

Какой смысл отвечать на пост почти 6-летней давности? =)

p.s. Была проблема с плагинами переключения контекстов и событиями, это было давно исправлено в ClientConfig 2.3.0, плагин теперь срабатывает на OnHandleRequest. До этого было достаточно переназначить события.

Client config not working with multiple contexts?

Если версия CC актуальная, переустанавливать не нужно, есть системная настройка — clientconfig.context_aware

Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.