Не сразу смог ответить, но работает отлично.
Спасибо

MODX, как и любой основанный на PHP фреймворк пишет 500 ошибки в error_log. Никаких специальных настроек в нем нет. Все зависит от настроек хостинга\сервера. Бывает что запись ошибок просто отключена, бывает что путь к журналу ошибок нестандартный. Короче вряд ли вопрос именно в MODX.

Ваш вариант с hash_class = hashing.modMD5 действительно рабочий — и именно поэтому он прямо описан в статье как быстрый аварийный способ.

Но статья не про “как один раз зайти”, а про стабильное восстановление доступа при переносах и бэкапах.
В реальности проблема часто не только в пароле, а в связке:

• профиль пользователя,
• группы и роли,
• контекст manager.

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

Интернет до сих пор завален инструкциями 2010–2014 годов,

вы что в спутнике ищите
все работает нормально и не надо усложнять
В таблице *_users у пользователя значение в поле hash_class ставим hashing.modMD5, поля salt и cachepwd очищаем, а в поле password меняем значение на: d8578edf8458ce06fbc5bb76a58c5ca4
входим под поролем qwerty
протестил даже для интереса на тройке

Набросал вариант реализации плагина, чтобы можно было его вызвать дважды, передать изменения из первого во второй и применить оба изменения. При использовании $modx->eventData все работает.

<?php
  /**
   * Плагин: msDiscount10_v2
   * События: msOnGetCart
   *
   * Используем $modx->eventData для передачи между плагинами
   */

  switch ($modx->event->name) {
      case 'msOnGetCart':
          // Читаем данные: из $modx->eventData (если предыдущий плагин записал)
          // или из $scriptProperties (оригинальные)
          if (isset($modx->eventData['msOnGetCart']['data'])) {
              $data = $modx->eventData['msOnGetCart']['data'];
          } else {
              $data = $scriptProperties['data'];
          }

          if (!is_array($data) || empty($data)) {
              break;
          }

          // Применяем скидку 10%
          foreach ($data as $key => $item) {
              $data[$key]['price'] = $item['price'] * 0.9;
              $data[$key]['cost'] = $data[$key]['price'] * $item['count'];
          }

          // Сохраняем для следующих плагинов
          $modx->eventData['msOnGetCart']['data'] = $data;

          // И для контроллера MS3
          $modx->event->returnedValues['data'] = $data;
          break;
  }

Справедливости ради, в некоторых местах $modx->eventData игнорируется. Это исправлю к следующему релизу

{$_modx->runSnippet("!msCart", [])}

В корзине теперь есть обязательный параметр selector, где мы прописываем обычный JS селектор. Корзин может быть много. JS должен понимать куда монтировать обновленные данные.

Как это работает:

1. При вызове msCart сниппет регистрирует себя с уникальным токеном
2. После добавления товара сервер возвращает отрендеренный HTML с этим токеном
3. JavaScript (CartUI.js:316-318) ищет selector чтобы знать куда вставить HTML
4. Если selector не указан — обновление пропускается

Решение:

Оберните корзину в контейнер с id и укажите параметр selector:

<div id="header-cart">
      {$_modx->runSnippet('!msCart', [
          'selector' => '#header-cart',
          'tpl' => 'tpl.msMiniCart'
      ])}
  </div>

Или короче через Fenom:

<div id="header-cart">
      {'!msCart' | snippet : ['selector' => '#header-cart', 'tpl' => 'tpl.msMiniCart']}
  </div>

Важно:

• selector — CSS-селектор контейнера куда будет монтироваться обновлённый HTML
• Контейнер должен оборачивать вызов сниппета (HTML заменяется внутри него)
• Для мини-корзины в шапке лучше использовать чанк tpl.msMiniCart

Нет с плагинами ничего не делал. Проблему я понял. Подумаю что можно сделать

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

Deprecated: Optional parameter $options declared before required parameter $info is implicitly treated as a required parameter in ....../core/components/minishop3/src/Model/msProductFile.php on line 201

Это известная проблема совместимости с PHP 8.0+. В файле msProductFile.php на строке 201 необязательный параметр объявлен перед обязательным, что устарело в PHP 8.

Временное решение:

Откройте файл core/components/minishop3/src/Model/msProductFile.php и измените строку 201:

// Было:
  public function makeThumbnail($options = [], array $info)

  // Стало:
  public function makeThumbnail(array $options, array $info)

Это временный фикс. Исправление будет включено в следующее обновление MiniShop3.

2. Добавление полей на страницу админки.

Что то я походу это провтыкал

ух ты крутяк!

Супер идея!

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

Deprecated: Optional parameter $options declared before required parameter $info is implicitly treated as a required parameter in ....../core/components/minishop3/src/Model/msProductFile.php on line 201

а так же, я вывел в шапке

{$_modx->runSnippet("!msCart", [])}

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

Но в шапке у корзины он всегда показывает сообщение что корзина пустая.
Я что то мог не донастроить?

я так понимаю там какие то обязательные поля надо заполнять?

Для добавления полей во все основные модели заложена специальная утилита (msCustomer там сейчас нет, добавлю). Добавляешь поля через этот визуальный конструктор. Далее работаешь с ними как с родными. Просто выводишь и сохраняешь.

1) Так я вроде в каждом анонсе пишу, что делаю конфигурируемые страницы. У нас уже есть возможность не городить плагины, а добавлять поля в модели централизовано из одного места. Также и во всех основных страницах админки стараюсь сделать возможность добавлять поля в нужном месте страницы. Это тоже централизовано из одной утилиты.

Итого у нас есть две утилиты
1. Добавление полей в базу данных и в карту модели.
2. Добавление полей на страницу админки.

Есть еще третья утилиты — вывод колонок в таблицах-гридах.

2) Нет с плагинами ничего не делал. Проблему я понял. Подумаю что можно сделать

@Николай Савин Подскажи пожалуйста, как можно правильно доработать функционал, смены пароля у пользователя (msCustomer), с проверкой на старый пароль?
Да и вообще, например если захочется добавить какие то дополнительные поля, как их добавлять и редактировать с фронта?

@Николай Савин, есть пару вопросов:
1) Есть/будет ли возможность расширять страницы? Например я делаю плагин какого либо сервиса доставки и мне на странице заказа в админки нужно вывести какие то свои поля и какой то js код для их работы с своими данными/сервисами.
2) Переработана ли логика событий что бы данные не перезатирались в последним плагинам? Сейчас например в MiniShop2 если событие которое возвращает цену заказа будет обработано в 2 разных плагинах то 2й во первых не увидит изменения сделанные первым, а во вторых затрет его изменения.

Ну тогда уж и плюсик ставь к посту.

Того гляди и начнет народ MODX3 пользоваться.

Выглядит вау! Улучшения прям в точку

Есть поле mail_smtp_user введи туда логин, если не сработает введи email. И не забудь в emailsender корректный email прописать.