Илья Уткин

Я больше про сам сниппет chunk — он ведь всё равно на каждой странице вызывается, но единственное, что сниппет делает — проверяет, есть ли данные в кеше и, если есть, выводит их.

1. Если не указывать свой раздел, то твой кастомный кеш будет находиться в папке default и он будет очищаться каждый раз, когда очищается кеш сайта. То есть при сохранении любого ресурса, чанка, плагина в админке, а так же когда пользователь нажимает «Очистить кеш» в админке. Если указать любой другой раздел, нестандартный, тогда твой кеш не будет очищаться стандартными средствами MODX и он будет «вечным», либо конкретно до истечения указанного времени жизни.

2. В стандартном механизме MODX время жизни у кеша указывается в системной настройке cache_expires. По умолчанию там ноль, то есть кеш хранится до тех пор, пока его кто-то не очистит.

3. Сниппет на странице кеширует свой вывод только для конкретной страницы. То есть если сниппет вызывается в шаблоне кешированным (без восклицательного знака), то он все равно будет выполнятся по одному разу на каждой странице. Поэтому если внутри сниппета ты добавишь своё кеширование, то ты можешь это поведение исправить. Вот так — ilyaut.ru/tips-and-tricks/site-optimization-on-modx-revolution/

4. Хранить его так же в базе данных или написать своё кеширование внутри этого сниппета или «снаружи» — https://docs.modx.pro/komponentyi/pdotools/parser#Управление-кэшированием

Я думаю, вряд ли примут)

А зачем ссылка на Яндекс, если компонент и так бесплатный?)

Прошу прощения за оффтоп, но… Они что, все статьи Боба Рэя с 2013 года публикуют как свеженькие в 2022 году? modx.com/blog/ten-essential-extras-to-make-modx-yours — свеженькая статья, которая рассказывает о таком чудесном дополнении, как getResources =)))

Ну так теперь же всё как раз хорошо раскрыто — теперь вы можете разрабатывать дополнение, которое повторяет функциональные возможности существующих пакетов. Статья ведь про то, что ограничение сняли, теперь об этом не надо думать.

Этим правилом решается проблема несправедливости. Всё мы понимаем, что сделать аналог какого-то дополнения будет проще, чем придумать его с нуля. И такие аналоги могут начать демпинговать — пострадает и автор, и магазин. Так что это правило защищает в первую очередь авторов. И вы как разработчик можете быть уверены, что после размещения компонента будете защищены от демпинга.

Ну на самом деле вы придумываете несуществующую ситуацию. Если дополнение включает в себя только 30% функционала «похожего» дополнения, а на 70% состоит из нового функционала, то это явно претендент на размещение и ни у кого не будет никаких претензий. У нас есть msDiscount и msPromoCode. И то, и другое — скидки, но всем абсолютно очевидно, что это разные дополнения и выполняют они разные функции разными способами.

Привет! Напиши, пожалуйста здесь, чтобы мы не забыли поправить — github.com/modx-pro/Community/issues

Теперь можно сделать свой SnowStorm и продавать его за 1000 руб. =))

Нет, он должен стоить БОЛЕЕ 1210 руб.

Да, общение происходит в рамках «треда» — rmThread. Пользователи становятся участником треда, когда создаётся объект rmMember, у которого указан thread_id и user_id. Если открыть ссылку site.ru/messages/id56, то автоматически будет создан тред, в него добавлен текущий пользователь и пользователь с ID 56.

Если создать в базе данных отдельный тред, а к нему несколько участников, то по ссылке site.ru/messages/group1 можно будет общаться всем вместе. Таких групп может быть сколько угодно и составы могут быть разными.

Такая возможность в архитектуре дополнения предусмотрена, но интерфейс так и не был реализован. Ну то есть кнопки «создать группу» с возможностью выбрать участников нет.

• mscarthandler.class.php
• msdeliveryhandler.class.php


• msorderhandler.class.php
• mspaymenthandler.class.php

В новой версии для таких файлов создан отдельный каталог.

В качестве идеи, как упростить обновление существующих магазинов. Где-то я такое видел, мне кажется логичным:

Можно добавить в новую версию файлы по старым путям, но в коде файлов делать просто include правильных файлов. И в комментариях пометить эти файлы как deprecated. А потом, в версии 3.1 или 3.2 убалить эти файлы. В итоге если человек обновлялся с версии 2.х до 3.0, у него файлы будут существовать и ничего не сломается, а на новых установках, начиная с 3.1 файлов deprecated не будет.

Да, продолжаем пользоваться, всё хорошо работает

Ну, значит надо обновляться вручную, обычным способом

Это просто бомба! А тем более бесплатно, вообще огонь! Спасибо.

Я готов записаться. Раз тут выходит MODX3, надо и свой уровень подтягивать, изучать новые подходы. Предлагаю создать либо отдельный телеграм-канал, чтобы потенциальные участники могли подписаться на новости и не пропустить начало курса. Либо просто сделать рассылку новостей на сайте с той же целью.

Ну и по количеству подписчиков будет ясно, кому это надо.

Добрый день! Напишите, пожалуйста, в техподдержку — помогу с настройкой пакета.

Есть же метод parsePropertyString — он как раз составит массив из MODX-синтаксиса. То есть что-то типа такого

<?php
$parser = $modx->getParser();
$html = '[[!pdoResources?
	&parents=`1`
	&depth=`0`
	&tpl=`ListRowTpl`
	&tplWrapper=`@INLINE [[+output]]`
	&includeTVs=`image`
]]';

$properties = $parser->parsePropertyString($html);

Там же можно подсмотреть, как MODX определяет тип элемента — в методе processTag