Сообщение о проблемах и их разбор

Отчёты об ошибках и запросы функций для MODX обрабатываются через issues на GitHub. Основные трекеры:

• modxcms/revolution: сам MODX Revolution (2.x и 3.x), основное место для сообщений о проблемах.
• modxcms/xpdo: xPDO.
• modxorg/Docs: проблемы с содержанием документации.

(Extras обычно имеют свой репозиторий или трекер. Не сообщайте о них в репозиториях ядра.)

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

1. Сообщайте об ошибках достаточно подробно и в нужном месте. Обсуждение на форуме полезно, но если речь об ошибке в ядре, оформите issue. Тогда у разработчиков будет одно место, где они увидят задачу.
2. Triage issues: проверяйте, что issues в трекере валидны и достаточно детализированы. Многие issues расплывчаты или на самом деле являются запросами поддержки. Triage помогает держать список полезным.

Ниже подробнее о каждом действии.

Сообщение о проблемах¶

Когда вы нашли ошибку, важно сообщить о ней в правильном месте. Так вы повышаете шанс, что её исправят.

1. Выберите правильный репозиторий. Для ошибки в Extra найдите трекер этого Extra.
2. На вкладке Issues воспользуйтесь поиском, чтобы убедиться, что проблема ещё не известна. Попробуйте другие варианты написания (например, «acl» или «permission»). Ищите части текста ошибки. Вы в первую очередь ищете Open issues, но быстрый просмотр Closed может показать issues, уже исправленные в dev-версии.
3. Если дубликата нет, нажмите зелёную кнопку New Issue справа вверху на вкладке Issues.
4. Выберите подходящий шаблон.
5. Заполните всю информацию, которую запрашивает шаблон. Не удаляйте шаблон и не заполняйте поля иначе. Для bug report важны чёткие шаги воспроизведения, наблюдаемое поведение и окружение. Указывайте конкретные номера версий, а не «последняя».
   • Если видите сообщение об ошибке, приложите полный текст и backtrace, если он есть (пути и другую конфиденциальную информацию можно скрыть).
   • Если при сообщении об ошибке текста ошибки нет, постарайтесь его найти. Проверьте журнал ошибок MODX (System → Reports → Error log), консоль разработчика браузера и серверные логи (часто через панель хостинга). Текст ошибки сильно упрощает исправление.
   • Если на форуме было обсуждение, связанное с bug или feature request, приложите ссылку на тему. Это даёт контекст.
6. Отправьте issue.

После отправки issue обычно быстро проходит triage: кто-то с доступом добавляет метки, назначает milestone или запрашивает дополнительную информацию.

Triage issues¶

Triage это проверка issue на полноту и применимость. При наличии доступа сюда входят метки и milestones для организации работы.

Если вы не опытный core-разработчик, самое полезное это подтвердить воспроизводимость. Выполните шаги из issue и убедитесь, что поведение совпадает с описанием. Если можете добавить детали (например, issue проявляется или нет на других версиях PHP или MODX), это помогает найти причину.

Если issue не воспроизводится по предоставленным данным, вежливо попросите автора уточнить информацию. Иногда проблему уже исправили (проверьте связанные issues и pull requests в activity). Иногда не хватает условий воспроизведения.

Если issue явно решена, её можно закрыть. Напишите @modxbot close (если есть доступ к modxbot) или предложите закрыть issue, чтобы это сделал кто-то с доступом.

Получение доступа к @modxbot¶

Через @modxbot отдельным участникам выдают доступ к управлению issues. Доступ предоставляют Jason (@opengeek) и/или John (@theboxer).

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

Когда вы регулярно принимаете верные решения по issues, вы показываете, что понимаете процесс и критерии хорошего issue. Это предпосылка для расширенного доступа. С хорошей репутацией доступ часто предлагают сами, без запроса.

Сообщение о проблемах безопасности¶

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

Сообщайте об уязвимостях ответственно по email: [email protected]. Письмо попадёт в закрытую группу core integrators (security team). Они проверят отчёт и начнут работу над патчем, если он валиден.

Следующее не считается уязвимостью:

• (Не)правильная конфигурация сервера
• Ввод скриптов в менеджере (ресурс, шаблоны) с последующим выполнением на фронтенде. MODX это CMS. Управление контентом и шаблонами её основная функция. Это feature, а не bug.

Вы можете сообщить security team об уязвимостях в extras, но обычно их отправляют напрямую maintainer'у extra. Security team, как правило, не исправляет проблемы в extras.

На данный момент формальной bug bounty программы нет.

Создавайте issues для соответствующего проекта в разделе issues на GitHub: https://github.com/modxcms/

Сообщество может инициировать или помогать с:

• ошибками в MODX и некоторыми Extras
• запросами функций для MODX и некоторыми Extras
• отчётами об ошибках или проблемах с сайтами MODX или их частями

Многие feature request и bug report начинаются с обсуждений на форуме. Если вы оформляете issue по теме с форума, приложите ссылку на тему.

Диалог вокруг bugs и features полезен, особенно когда решение неочевидно. В итоге contributors и команда интеграции кода используют issue tracker как первый и часто единственный источник информации. Без ссылки на дополнительный контекст эта информация может не попасть в работу над исправлением или новой функцией.