#typo3
#typo3
Вопрос:
В настоящее время возможно добавить только один обработчик ошибок для каждого кода состояния HTTP в конфигурации сайта, например, для 404 или 403. В качестве альтернативы вы всегда можете написать свой собственный обработчик ошибок. Но это делает его немного негибким.
Представьте себе следующий сценарий:
- по умолчанию обработкой 404 будет определенная страница, например, 12
- в пользовательском обработчике ошибок у меня есть кэш сопоставления URI-to-page. Если это попадет в цель, должна отображаться страница из этого. Если нет, страница общей ошибки 12
- какая страница отображается, должно быть настроено в конфигурации сайта
или
- для 403 у меня есть обработчик ошибок, который может перенаправлять на страницу входа в систему
- однако это может не сработать в некоторых случаях, когда по умолчанию должна использоваться стандартная страница 403
Было бы неплохо, если бы вы могли настроить это для сайта, чтобы у вас было что-то вроде этого:
404
| - custom error handler 1
| - custom error handler 2
| - page error handler
Сохраняя ваше расширение с пользовательскими обработчиками ошибок, вы можете просто заменить «обработчик ошибок страницы» гибким шаблоном для последнего шага через конфигурацию сайта.
Однако модуль сайта допускает только один обработчик ошибок для каждого кода состояния (например, 404).
Я думаю, было бы полезно изменить это в ядре TYPO3.
Но хотелось бы знать, как другие решат эту проблему в первую очередь.
Комментарии:
1. Я бы решил это с помощью промежуточного программного обеспечения PSR-15. Но для некоторых случаев использования может потребоваться перепрограммирование с помощью .htaccess или модуля перенаправления.
2. Мне бы понравилась такая возможность (каскадный обработчик ошибок). Это позволит ie. установить обработчик ошибок, поставляемый расширением TER, и добавить также пользовательский для того же кода ошибки.
3. Регистрация обработчика ошибок может быть выполнена так же, как и регистрация промежуточного программного обеспечения (с приоритетом до / после). Сложная часть может позволить сделать цепочку обработчиков ошибок редактируемой в конфигураторе сайта BE.
4. @Tobias — Я не уверен в .htaccess / redirect (поскольку это не охватывает все варианты использования), но предложение с промежуточным программным обеспечением PSR-15 хорошее — там у вас очень похожее приложение, одно выполняется за другим — где это уже возможно, что я имел в видуобработчики ошибок.
5. @dogawaf — моя интуитивная идея заключалась в том, чтобы снять ограничение на наличие только одного обработчика ошибок для каждого кода состояния — тогда у вас могло быть несколько, и один мог выполняться после другого, вы могли бы легко добавить их в графический интерфейс. Я не знаю, будет ли это самым элегантным и лучшим решением с точки зрения производительности. Кроме того, это определенно потребовало бы изменений в ядре.