Часть данных храниться в modx_user_attributes. Но это наверное не очень правильно туда лишние данные сохранять.

А что в этом неправильного? Атрибуты пользователя могут быть каким угодно.

Лучше это через компоненты все сделать?

Да, так как компоненты имеют документацию и тот, кто после тебя будет работать с сайтом сможет к ней обратиться и быстрее понять как и что работает.

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

Лучше это через компоненты все сделать?
Просто не очень понятно как данные и где будут храниться под пользователя. Часть данных храниться в modx_user_attributes. Но это наверное не очень правильно туда лишние данные сохранять.

как сделать персональную страницу для каждого пользователя?

Если для всех пользователей должны быть доступны одинаковые функции, то страница должна быть одна и задача сводится не к генерации индивидуальных страниц, в к загрузке персональных данных для авторизованного пользователя.
Для вывода данных пользователя в Modx есть модификатор user. В pdoTools есть сниппет pdoUsers. Можно написать свой сниппет.
Так же очевидно, что кроме стандартных полей требуется хранить ещё какие-то данные пользователя. Для создания полей под эти данные имеет смысл использовать компонент ExtraFields версии не старше 2.0.3.
Когда организуешь место для хранения, нужно будет организовать отправку данных на сервер и обработку ответов. Для этого удобнее всего использовать компонент SendIt.

В целом этих трёх компонентов достаточно для создания личного кабинета любой сложности.

Ну там явное отсутствие объявления переменной $skip в функции.

Можешь попробовать в начале добавить

$skip = 0;

.

Но это всего лишь PHP warning, работать должно и так)

А насчет второй — ну вот где-то ему скобочка не понравилась. Пробуйте частями может как-то файлы подключать? Найти эту скобочку.

В моем случае мне подошло данное решение, которое очень костыльное и скорее всего не совсем верное, но для моих нужд работает. Хотя и оставляет в псевдониме точку, если содержит одно из расширений, указанных в массиве. Но это уже, подчеркну в МОЕМ случае, неважно, ибо таких заголовков у меня не будет. Если кто-то предложит работающий универсальный вариант без такого говнокода, думаю буду благодарен не только я.
Меняем код функции translate на такой:

public function translate($title)
    {
        $language = $this->modx->getOption('translitor_language', null, 'ru');
        $separator = '-';

        // Список расширений, которые нужно сохранить, у меня указаны такие
        $extensions = ['jpg', 'jpeg', 'png', 'gif', 'svg', 'ico', 'webp', 'doc', 'docx', 'pdf'];

        // Проверяем, заканчивается ли строка на одно из расширений
        $hasExtension = false;
        $extension = '';
        foreach ($extensions as $ext) {
            if (substr($title, -strlen($ext) - 1) === '.' . $ext) {
                $hasExtension = true;
                $extension = $ext;
                break;
            }
        }

        // Если есть расширение, отделяем его от основной части
        if ($hasExtension) {
            $titleWithoutExtension = substr($title, 0, -strlen($extension) - 1); // Убираем точку и расширение
            $title = $titleWithoutExtension;
        }

        // Транслитерируем текст
        $title = $language ? $this->ascii($title, $language) : $title;

        $flip = $separator === '-' ? '_' : '-';
        $title = preg_replace('!['.preg_quote($flip).']+!u', $separator, $title);
        $title = str_replace('@', $separator.'at'.$separator, $title);

        // Удаляем все символы, кроме букв, цифр, разделителя и пробелов
        $title = preg_replace('![^'.preg_quote($separator).'\pL\pN\s]+!u', '', $this->lower($title));

        // Заменяем последовательности разделителей и пробелов на один разделитель
        $title = preg_replace('!['.preg_quote($separator).'\s]+!u', $separator, $title);

        // Обрезаем разделители по краям
        $title = trim($title, $separator);

        // Если было расширение, добавляем его обратно
        if ($hasExtension) {
            $title .= '.' . $extension;
        }

        return $title;
    }

да, данное решение фиксит вопрос с файлами, но тем временем ломает вырезание точки из урла.

Вопрос будет ли он работать с шаблоном ultron.pro/311-shablon-sayta-gruzoperevozki-transportnoy-kompanii.html

С новым патчем будет исправлено, плюсом мелкие косяки исправлю, по возможности до конца этой недели уже будет 1.1.4 версия.

При указании чистого css-файла проблема пропадает, но хочется воспользоваться указанным функционалом)

Переключалка есть, а вот пути абсолютные… буду ждать

Создать сниппет или плагин.

Тоже самое

Добрый день! При формировании данных, поле picture выводит ссылку такого плана. sitename.ru/catalog/category/nameimage.jpg. а нужна sitename.ru/assets/images/catalog/category/nameimage.jpg

Где то можно в настройках указать полный путь?

Очень вовремя — как раз делаю кабинет на сайте))
Кайфую от того как все продумано, раньше для такого функционала пришлось бы долго «женить» несколько приложений.
Спасибо!

Да всё верно! Читать доку да, но её не обломно читать когда подготовкой данных занимаешься, а когда верстка разъезжается или js-компоненты шаманишь, оформляя чанки — читать бекендовую доку уже может головы не хватить :)

Очень рад, что смог донести идею! Спасибо за внимание! Желаю успехов, тебе и компоненту!

Я в 90% случаев использую поиск через Crtl+F

Есть встроенный поиск:

Аналогично тому, как например в mFilter2 можно указывать кастомные чанки row и outer для любых полей,

Я об этом даже не знал. Чтобы что-то узнать, все равно нужно читать документацию, а если нужно универсальное решение — использовать феном.

Из пожеланий, всё-таки не терять MODX-style и дать возможность использовать систему чанков полноценно, не прибегая в foreach циклам в коде шаблонизатора.

Теперь я понял, о чем ты. Нужно добавить параметры, как в mFilter2. Например:

'tpl.outer.list' => 'tpl_outer_name',
'tpl.row.list' => 'tpl_row_name'

где list — название переменной.

Но ведь все равно придется читать доку))
Но идея хорошая. Сделаю

Ну да, лучше, причем намного, если искать по первым буквам глазами. С группировкой будет ещё лучше, но это уже. Я в 90% случаев использую поиск через Crtl+F, но это когда знаешь название, а когда не знаешь — только вычитывать, и ровные колонки тут выигрывают у любых мясных кнопок))

Вот так? Я подумаю, куда можно вывести стилизацию списка блоков.

… возможно к каким-то JS-библиотекам и т.п.)

Короче говоря последнее, что я хочу (и могу) делать на этом этапе, это снова заниматься программированием — разбирать данные из массивов, сверяться с документацией по бекенд-технологиями (таким как PageBlocks, искать там кастомные модификаторы) — мне хватает того, что для простых преобразования в стиле (:lowercase или :ellipsis) у меня открыта документация по фильтрам вывода (в плюс к тому набору выше).

Поэтому использование в вызове чанка специализированный модификатор (:pbJson) — это прекрасно, что такая возможность в принципе есть, но пока не освоишь инструмент очень глубоко (и не забудешь через год, когда на поддержке вернешься к проекту и надо будет добавить присоединение какой-то таблицы) про это в нужный момент не вспомнишь и встрянешь — это совсем не то же самое, что в сниппет pbResources передать нужные параметры для полноценной подготовки данных для их последующей верстки и оформления. Потому что при любом раскладе, когда работаешь с данными, ты пойдешь в документацию (или код) сниппета и посмотришь возможные параметры, отвечающие за подготовку данных и раскладывание по чанкам. Так почему бы не дать возможность избавиться от программирования в чанке и как альтернативу перенести вызов этого модификатора в подхватывающиеся по шаблону (префиксу) параметры вызова сниппета — тогда вся подготовка данных будет происходить в одном месте (вызове сниппета), а всё оформление — в другом (в чанках). Аналогично тому, как например в mFilter2 можно указывать кастомные чанки row и outer для любых полей, просто добавляя их в параметры вызова прямо по именам, задаваемых в этом же вызове — это почти также красиво и понятно в коде, как твоё @Aleksandr Huz описание содержимого табов в PageBlocks))

А тот момент, что у одной задачи есть несколько вариантов решений, как раз и делает инструмент по-настоящему гибким!