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

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

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

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

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

В моем случае мне подошло данное решение, которое очень костыльное и скорее всего не совсем верное, но для моих нужд работает. Хотя и оставляет в псевдониме точку, если содержит одно из расширений, указанных в массиве. Но это уже, подчеркну в МОЕМ случае, неважно, ибо таких заголовков у меня не будет. Если кто-то предложит работающий универсальный вариант без такого говнокода, думаю буду благодарен не только я.
Меняем код функции 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;
    }

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

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

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

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

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

Тоже самое

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Спасибо за отклик!

Ну хоть что-то, хоть это и немного не то ;)
Попробую пояснить: Когда я занимаюсь интеграцией макетов с админкой, я включаю «режим разработчика» — открываю документацию (или справку/код других проектов), хожу по шаблонам и расставляю вызовы сниппетов, где в этот момент я полностью работаю с данными — их выводом, преобразованием, разбором массивов и прочим, и раскладываю данные по чанкам. Может даже где-то пишу свои модификаторы вывода для сложных случаев. В этот момент я почти не смотрю на фронтенд, меня мало интересует верстка и стили, главное вытащить нужные данные из админки (из БД, конечно).

Далее, я иду в чанки, и там уже добавляю к данным оформление. В этот момент я «включаю режим фронтендера верстальщика»: меня в большей тепени беспокоит как выглядят данные, какие отступы, сходится ли с макетами, у меня открыта совсем другая документация (MDN, возможно SASS, дока к моему фронтенд-фреймворку, возможно к каким-то