[Bug] Не работает подтверждение email в демо ЛК: мёртвая кнопка и неверная ссылка в письме

[Ibochkarev]

Описание проблемы

Сообщение от пользователя демо: после регистрации не удаётся подтвердить email из личного кабинета. Поведение воспроизводится на 1.10.0-beta1.

• Письмо с токеном/ссылкой приходит, но переход по ссылке ведёт на главную и не обновляет статус верификации (по ощущению, не вызывается verifyToken).
• Кнопка повторной отправки/подтверждения в кабинете не работает (клик не инициирует сетевой запрос, в DevTools/консоли явных ошибок нет).
• Параллельно отмечено, что нет/неочевиден «forgot password» в UI (см. тред-обсуждение).

Шаги воспроизведения

1. Установить/использовать демо MiniShop3 (по отчёту: баг остаётся на 1.10.0-beta1).
2. Зарегистрировать покупателя в режиме, когда требуется подтверждение email.
3. Открыть личный кабинет.
4. Нажать кнопку(и), связанные с отправкой/повторной отправкой письма подтверждения.
5. Перейти по ссылке из письма.
6. Проверить, что статус email подтверждения обновлён, а UI отражает «подтверждён».

Ожидаемое поведение

• Кнопка в кабинете инициирует ожидаемый API-вызов (resend) и/или показывает явную ошибку при сбое.
• Ссылка из письма попадает в обработчик верификации и подтверждает email (а не ведёт на главную).
• Статусы/поля, связанные с верификацией, обновляются без ручных SQL-вмешательств.

Фактическое поведение

• Ссылка из письма не ведёт к verifyToken (фактически: уходит на главную, статус не меняется).
• Повторная верификация из кабинета не инициирует запрос (симптом: «кнопка мёртвая»; сетевых запросов нет).

Анализ причины (проверка исходников)

1) Ссылка в письме не совпадает с публичным API верификации

• В EmailVerificationService::sendVerificationEmail() URL собирается как site_url + verify-email?token= + токен (файл core/components/minishop3/src/Services/Customer/EmailVerificationService.php, строка с $verificationUrl).
• Фактический HTTP-эндпоинт Web API: GET /api/v1/customer/email/verify?token=..., маршрут в core/components/minishop3/config/routes/web.php → CustomerEmailController::verify().
• Вход для фронта: assets/components/minishop3/api.php?route=... (см. api.php и группу /api/v1 в web.php).
• В пакете нет готовой страницы MODX с алиасом verify-email, которая бы проксировала запрос к API или дергала верификацию. Если на сайте/демо нет ресурса verify-email, переход по ссылке из письма не попадает в api.php / verify() — типичный итог: редирект на главную или «пустая» страница, статус в БД не обновляется. Это объясняет симптом «verifyToken не вызывается» без поломки самого метода.

2) Кнопка resend в шаблоне не подключена к фронтенд-коду

• В elements/chunks/ms3_customer_profile.tpl есть кнопка #resend-verification-email, но:
  • в assets/.../js/web/core/CustomerAPI.js нет метода для POST /api/v1/customer/email/resend-verification;
  • в assets/.../js/web/ui/CustomerUI.js нет обработчика клика по resend; в init() подключаются формы, отмена заказа, адреса, но не resend;
  • в assets/components/minishop3/js/web/core/Selectors.js нет селектора для кнопки resend.
• Поэтому клик не инициирует сетевой запрос — «мёртвая кнопка» подтверждается кодом, а не только догадкой.

Вывод: корневая причина — интеграционный разрыв (URL в письме ≠ маршрут API / отсутствует лендинг; нет JS для resend), а не обязательно ошибка внутри EmailVerificationService::verifyToken().

Предлагаемое решение

1. Письмо (обязательно):
   • либо менять дефолтный $verificationUrl на прямой вызов Web API, например
     {site_url}assets/components/minishop3/api.php?route=/api/v1/customer/email/verify&token=...
     (с учётом слешей site_url и при необходимости rawurlencode для route/token);
   • либо ввести системную настройку (шаблон URL верификации) и/или документированный ресурс verify-email в установочном пакете: страница читает ?token=, редирект/fetch → API, затем редирект в ЛК с сообщением.
2. Личный кабинет (обязательно):
   • добавить в CustomerAPI метод resendVerificationEmail() → POST /api/v1/customer/email/resend-verification;
   • в CustomerUI — инициализация клика (и при необходимости селектор в Selectors.js, например data-ms3-resend-email-verification);
   • показ успеха/ошибки через существующий message + лексиконы.
3. Документация / демо: явно описать, что либо в письме должен быть URL на API, либо на сайте должен существовать дружественный URL, совпадающий с тем, что подставляется в письмо.
4. (Отдельно от этой issue) Forgot password — в Selectors.js уже есть authForgotPassword: '#forgot-password-link', но это не закрывает верификацию email.

Скриншоты

• Исходная переписка (скрин): переписка Ольга ↔ Иван Бочкарев (см. вложенный тред-скрин в обращении).
• Публичный тред на MODX.Pro: MiniShop3: итоги февраля и версия 1.6.0 — комментарий #146439

Окружение

• MiniShop3: 1.10.0-beta1 (по сообщению; воспроизводилось в демо)
• MODX: [не указано]
• PHP: [не указано]
• MySQL: [не указано]
• Браузер: [не указано]

Логи ошибок

Логи из core/cache/logs/error.log

(при доразборе полезны: HAR/Network, точный href из письма, сравнение с путём GET /api/v1/customer/email/verify, был ли POST /api/v1/customer/email/resend-verification при клике по кнопке)

Дополнительный контекст

• Первичное публичное обсуждение: modx.pro — комментарий #146439
• Справка по коду: серверный resend/verify — core/components/minishop3/src/Controllers/Api/Web/CustomerEmailController.php; процессор MiniShop3\Processors\Api\Customer\VerifyEmail используется в другом контуре (connector), ориентир для фронта — Web API в config/routes/web.php.