Василий Наумкин

Нормально.

Каждая страница сохраняется в кэш и загружается оттуда быстрее, чем из БД. Если кэш не нужен — его всегда можно отключить в системных настройках.

Ошмётки могут пропасть после очистки кэша, наверное.

В общем, в репозитории сейчас минимально активная версия — 2.2.0-pl, все багрепорты ваши.

Ну тогда нужно не вопросы задавать, а копать самостоятельно. А потом писать всем познавательные заметки, мол смотрите как надо!

А так непонятно, зачем спрашиваешь?

Конечно, например вот добавление и изменение кучи полей при установке Tickets.

В общем, этот конкретный недостаток — суть продолжение достоинств Fenom.

Все ajax запросы eventsCalendar2 отправляются на текущую страницу, где сниппет должен их словить, обработать, выдать ответ и прервать работу парсера. В общем, как написано в этой статье.

И всё отлично работает, за исключение того, что при компиляции шаблона Fenom он прописывает вывод всех данных не в переменную, которую покажет в конце, а выводит их сразу через echo.

Соотвественно, в ответ ajax запроса попадают все сниппеты, обработанные до eventsCalendar2 — и ты видишь их на странице. Это косяк старой архитектуры eventsCalendar2, ведь по уму нужно бы отправлять все запросы на отдельный коннектор или плагин, как в mFilter2 и miniShop2.

Но можно выйти из ситуации и сейчас:
1. Нужно вызывать eventsCalendar2 в шаблоне, перед всеми другими сниппетами, и сохранять его вывод в переменную.
2. А переменную уже выводить на странице. Но не в контенте, а тоже в шаблоне или в чанке, потому что ресурс обрабатывается перед шаблоном и переменная там еще будет пуста.

Тогда при обычной загрузке страницы сниппет отработает, данные сохранятся в переменную и выведутся в нужном месте страницы. А при ajax запросе сниппет отреагирует первым и выдаст чистый ответ, без других сниппетов.

Примерно так:

{set $calendar = $_modx->runSnippet('!eventsCalendar2', [
	...
])}

{$calendar}

Кстати говоря, можно так сохранять и вывод других сниппетов, чтобы вызывать их в одном месте, а показывать в другом.

eventsCalendar2 сам ловит и отвечает на ajax запросы, так что кэшированным его вызывать вообще нельзя.

А так, он очень старенький и его нужно переписывать — у меня пока ни времени, ни желания. Поэтому пока придётся вызывать его как тег MODX, не зря же такая возможность при использовании Fenom предусмотрена.

И вообще, я с понедельника в отпуске на 2 недели и уже вообще ничего делать не хочется!

mFilter первый давным-давно не поддерживается. Использовать его можно только на свой страх и риск.

Так что, с ним от меня помощи не жди. В магазине лежит надёжный и проверенный mSearch2.

Ну а теперь загляни в исходный код страницы и посмотри, где у тебя вызывается minishop2/js/web/default.js, а где пишется miniShop2Config и подумай, в правильном ли порядке они идут?

Григорий, ну ты бы хоть ссылку дал, где посмотреть на ошибку.

Я уже молчу про подробное описание вызовов сниппетов и чанков на странице — этого вообще ждать не приходится.

Думаю, пора просто сделать в репозитории версию 2.2.0-pl основной — сразу будет больше тестеров.

Как только Виталий примет вот этот патч и обновит версию в репозитории — можно отключать 2.1.12-pl.

miniShop2Config — это не mFilter выдаёт ошибку.

А это 90% хостингов, если не больше.

Я все свои дополнения заставляю работать на 5.3.

2 варианта:
1. Вставить прямо в теле статьи вызов чанка\сниппета вручную, если автор текста понимает, что делает и разрешены теги в контенте.
2. Написать простенький фильтр вывода, который будет вставлять вызов чего надо через n тегов p в тексте, и вызывать контент примерно так:

[[*content:advertising]]

Сделал, отдал заказчику, получил оплату — всё хорошо.

Я правда не знаю, как сделать электронные товары красиво и универсально, поэтому не делал готового решения. Однако на конкретном сайте это пишется за пару часов, никуда не спеша.

Если после установки или обновления pdoTools на сайте белый экран — значит на хостинге PHP 5.2.

Нужно обновить как минимум до 5.3.

Стандартный загрузчик, не поверишь, не генерирует превьюшки. Он только загружает файлы.

Как видно на твоём скриншоте, Tickets тоже загрузил файл нормально, проблема возникла уже с созданием превью.

В общем, передавай привет своему хостеру.

Ну вот тебе и хостинг пишет, что скрипты пытается сохранить картинку выше директории сайта.

!$this->config_allow_src_above_docroot therefore setting "/tmp/tkt_vfvTqG" (outside "/var/www/site12343/site1234.tk")

То есть, сайт лезет за пределы своей директории и phpThumb в MODX бьёт ему по рукам.

Нужно или разрешить такое поведение системной настройкой allow_src_above_docroot или указать в php.ini директорию для временных файлов внутри сайта, как у нас на modhost.pro.

Выводы, у кого здесь ошибка, делай сам.

косвенно, но подтвердили проблему.

Нет, они сказали что где-то когда-то что-то подобное у них вроде было.

И что мне, блин, с этой информацией делать? Когда мне кто-то покажет эту «проблему» — я смогу её исправить. А рассказы в духе

проблема… все еще актуальна. Перепробовал все возможные версии… пробовал на двух разных хостингах ...

И что? Я пробовал на большем количестве хостингов — и ничего такого не заметил.

Причем, в отличии от вас, я не рассказываю о чём-то, а собираю тестовый сайт, делаю скриншоты и даю на него ссылку. И там всё работает, и я это доказываю.

Ну так и ты мне докажи, что у тебя что-то не работает, блин. Как дети малые, её богу.

С таким-то ником должен был сам давно найти проблему и прислать готовое исправление в репозиторий.

Ты, на данный момент, единственный, кто говорит мне об этой проблеме.

На какие мысли это наводит?

пробовал на двух разных хостингах

Попробуй на modhost.pro

Я вот не поленился еще 2 месяца назад проверить и тебе написать. А ты проснулся только сегодня.

Давай-ка дальше сам разбирайся со своими хостингами, у нас всё работает.