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

Ты про ту документацию, страницы которой лежат на GitHub и любой желающий может их редактировать?

Естественно, никому это не интересно. Поэтому я сейчас, в полтретьего утра, субботу, заморочился и дописал эту страницу.

Ура.

Конечно, он есть только в miniShop2.4+

Ищи, в чём проблема — вот моё исправление.

Поправил, обновляйся.

Да, этот параметр не работает и будет удалён в следующей версии.

Для включения проверки разрешения «section_add_children» нужно:
1. Создать новую группу ресурсов, например Special.
2. Добавить в эту группу нужные секции тикетов.
3. Добавить какой-либо группе пользователей политику TicketSectionPolicy для новой группы ресурсов.

И с этого момента только члены группы пользователей с политикой TicketSectionPolicy смогут публиковать и редактировать тикеты в секциях Special.

Так работает система прав MODX, что пока ни у одной группы нет особых разрешений к разделу, то запретов вовсе нет.

Ну так сделай pull-request — документация открытая.

Почему всё Василий должен делать?

Эта страница — перевод официальных доков.

А модификаторы Fenom в его собственном разделе.

Это баг сортировки картинок, будет исправлен в новой версии miniShop2.

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

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

Пришлось разбить на несколько (у меня 7) таблиц по разделам. По сути поля могут в точности повторять поле из таблицы modx_site_content.

Несколько одинаковых таблиц точно делать не стоит. Задача — вынести данные из modx_site_context, чтобы MODX не пытался их кэшировать в карту ресурсов, и всё.

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

Разные таблицы нужны только для разных сущностей. Например, фоторепортажи и лайки для них — 2 разные таблицы, а распихивать 200 000 фоторепортажей по 7 таблицам бессмысленно.

Попробуй удалить все куки от modstore.pro и сбросить пароль еще раз.

Так он на тех же ресурсах работает — так что нет.

500 000 страниц сайта — это нормально. А вот 500 000 ресурсов — совершенно нет, MODX к такому не готов.

Разница в том, что ресурсы нужны для разделов сайта, служебных страниц и всего такого. Если же сайт продаёт полмиллиона товаров или содержит объявления — нужно это выносить в отдельные таблицы, с нужными колонками и индексами.

Например, вот я делал vrmedia.tv. Ресурсов в дереве там меньше 50, а фоторепортажей и картинок многие тысячи. Всё летает, лайкается, добавляется в избранное — и хранится в отдельных таблицах.

В таком направлении и нужно двигаться, используя MODX как удобную обёртку для своих данных.

Это всё + запуск через vendor/autoload.php, чтобы работали зависимости провайдеров. Например, тот же Facebook требует facebook/graph-sdk.

но очень не очевидно.

Да вообще, особенно, если документацию не читать.

Также доступно быстрое редактирование значений по умолчанию и сортировка свойств перетаскиванием.

Насколько я помню (и в документации так написано), нет, опции там не выводятся.

Можно указать параметр

'return' => 'json',

а дальше дело техники.

Судя по распечатке, у тебя $compl — json строка. А вот с нормальным массивом

{set $compl = ["19","35","18","20","54"]}
{if '19' in $compl}da{else}net{/if}

выводит da.

Ну вот у меня, код с живого проекта работает:

{($product.id in list $favorites) ? 'remove' : 'add'}

Больше идей нет.

Попробуй в скобочках:

{if ('1' in list $compl)}