спасибо, что находите время и силы на улучшения. Это круто и заслуживает уважения.

Так делал

{$characteristics | print}

Что показывает?

Попробуйте в таблице config очистить value у поля session_handler_class и очистить кэш в папке core/cache. Тогда сессии будут храниться в файлах.

А вообще просто обратитесь к хостеру хотя бы с этой ошибкой

Пытаюсь удалить записи в modx_session но выскакивает ошибка #1036 — Table 'modx_session' is read only
joxi.ru/eAObzEjtGjMgG2

это явно нездоровое поведение.

Сделайте разные шаблоны, для разных контекстов.
{($_modx->config.cultureKey=='ru')? tpl.topMenuRU: tpl.topMenu}

&tpl=`tpl.topMenu`

Вообще я бы для pdoMenu использовал &tpl=`@INLINE `

Если у вас отличие только в контенте, то зачем понадобились контекст, почему не PolyLang?

Посмотрите в конфиге mysql innodb_force_recovery = 1, нужно поменять на 0, либо проверьте, сколько свободного места на хостинге, может быть закончилось, и поэтому ничего не пишется.

Яндекс: Ключевые слова могут учитываться при определении соответствия страницы поисковым запросам.
yandex.ru/support/webmaster/controlling-robot/html.html

Дело в том что нет, там сайт не большой, я уже решил его делать с нуля, просто копируя, но я походу уже понял. Я в БД не нашел плагина ajaxForm, а он был до переноса, куда он пропал так и не понял.

Да, действительно. Спасибо, чуть подправил описание, надеюсь, теперь будет понятнее.

Судя по ошибкам у вас идет обращение к не найденному компоненту modFormCustomization — вы о таком знаете? Существует он на сайте?

Код нужно помечать специальным тэгом для лучшей читаемости

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

P.S. Кто-то выше писал, что это невозможно, а оказалось что для счастья нужны лишь две строчки.

Не нашел для себя ответа нормального потому просто оставлю это здесь:

1) Создаем поле вот такого типа

<input type="text" name="extended[organization_name]">

2) Ищем файл \core\components\office\controllers\auth.class.php
3) Ищем метод «formRegister», и в ней добавляем поле extended, должно получиться вот так:

return $this->_createUser(array(
            'username' => $username,
            'email' => $email,
            'mobilephone' => $mobilephone,
            'password' => $password,
            'fullname' => $fullname,
            'extended' => @json_encode($data['extended']) // вот об этой строке речь
        ));

4) Дальше ищем метод в том же файле "_createUser" и правим переменную $parrams

if (empty($data['extended'])) { // тоже будет не лишним, но добавлять не обязательно
       $data['extended'] = '[]';
}

$params = array(
            'username' => $data['username'],
            'fullname' => $data['fullname'],
            'mobilephone' => $data['mobilephone'],
            'email' => $data['email'],
            'extended' => $data['extended'], // добавляем эту строку
            'active' => !$this->modx->getOption('office_auth_activation'),
            'blocked' => false,
            'groups' => $this->config['groups'],
        );

5) Проверяем и радуемся

Отлючил почти все плагины, проблема не в них.

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

• Не у каждого компонента есть достоверное описание, не всегда понятно для чего он, что умеет, где можно применить и какую пользу получить
• Не о каждом компоненте есть более менее приличная заметка здесь. Не удивлюсь если о половине вообще ничего не написано, или написано очень кратко
• Какие-то компоненты заброшены, и есть смысл составить список тех, чье обновление требуется
• По каким то компонентам здесь на форуме много заданных, мало раскрытых вопросов. Можно составить контент-план по раскрытию вопросов. Необязательно самому писать. Для начала можно просто составить список тем, которые было бы неплохо раскрыть. Уверен ребята заметят активность и подключатся

Я опять немного пофилософствую. Мне кажется, что у компонентов, которые представлены на modx.pro есть одна практически общая проблема. И проблема эта звучит так — по описанию компонента практически невозможно догадаться для чего он и какую задачу можно с его помощью решить.

Я прекрасно понимаю почему это происходит. Когда разработчик сделал что то новое и готов им поделиться, он «живет это разработкой», он работал над ней несколько дней (недель, месяцев) и ему кажется, что в ней и так все понятно. Вот ему же все понятно и логично, значит и другим будет понятно тоже. Но это не так.

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

Может я один такой глупый, но прочитав 5 раз описание customExtra я так и не понял что он делает. И может это именно то, что я бы хотел, но из-за сжатых, странных формулировок в описании я пройду мимо и не куплю, просто потому что не пойму зачем этот компонент.

modstore.pro/packages/utilities/customextra
Под самым название компонента видим — Дополнительная табличка в админке MODX. Уже честно говоря сбивает с толку, потому что не понятное слово «табличка» еще и в уменьшительно ласкательном варианте. Это про таблицы в базе данных? Это про таблицы генерируемые extjs? Что за «табличка..»
Ниже по тексту читаем

Компонент позволяет гибко кастомизировать табличку и формы создания / редактирования объектов из админки.

Снова ступор. Ведь выше написано, что это для создания дополнительных (тоесть новых ) табличек, а это предложение говорит «кастомизировать» (то есть изменить существующую.)
И ниже идут скриншоты, простите но очень невнятные, на которых предлагается создать какой- то предмет. Что за предмет, не известно.

В итоге, дочитав описание до конца, я все еще остаюсь в состоянии полного непонимания, что же конкретно делает и какие задачи этот компонент решает.

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

По крайней мере для моего мозга справедливо все то, что я описал) Возможно другие люди прекрасно понимают такие вот краткие и сумбурные описания.

Нужно расширять Tickets.window.UpdateComment
assets/components/tickets/js/mgr/comment/comment.window.js
Что-то типа такого, нужно тестировать.

$controller->addHtml("<script>
		Ext.override(Tickets.window.UpdateComment , {
			getFields: function (config) {

Хм. При такой бизнес логике реализация имеет смысл. Но из коробки ее нет. Я даже не слышал, об упоминании подобного решения.

Я всегда рассматривал связь по аналогии modUser + modUserProfile

Совершенно верно. + На самой странице тикета есть вкладка с комментариями (надеюсь это тоже самое)