By @kamiyang
What is your idea about?
A TYPO3 site has exactly one 404 page. Larger sites with clearly separated page-tree branches (news, products, recipes) cannot offer context-aware error pages: whoever follows a dead link into /news/ lands on the same generic error page as every other visitor. The TYPO3 core’s built-in error handling supports a single 404 page per site (one errorHandling entry per error code in the site configuration). The error-page extensions currently maintained in TER (static_error_pages, nxerrorhandler, sierrha) also serve one error page per site and error code; none of them resolves the error page based on the requested path. Extensions that supported per-domain error pages (custom_error_page, error404page) target TYPO3 8 and are no longer maintained.
This project delivers an open-source extension that makes 404 handling path-aware, managed entirely by editors in the page tree:
You create a page of the new page type “Path-specific 404” inside a branch:
A page with the slug /news/page-not-found catches every 404 request under /news/, served with a real 404 status code. The same works for /products/, /recipes/ and any other path.
Nested paths work too: /recipes/breakfast/page-not-found wins for requests under /recipes/breakfast/, while /recipes/lunch/some-old-recipe falls back to /recipes/page-not-found, because the longest matching path prefix applies.
If nothing matches at all, the site’s normal 404 page is used, so nothing changes for existing setups.
Technically this is an implementation of PageErrorHandlerInterface, registered as the site’s 404 handler. It resolves the right 404 page by longest matching slug prefix (cached, language-aware) and reuses the core’s own page content rendering for the response.
What must be achieve by 30th of November 2026?
A released, documented and tested extension:
- The extension, open source on GitHub, released on TER and Packagist
- The “Path-specific 404” page type, the error handler, caching, multi-language support
- Functional tests for prefix matching, fallback behaviour and localization
- Documentation in docs.typo3.org format, including an editor guide and known edge cases
- Compatibility: TYPO3 v13 LTS, v14 LTS & 15-dev
What is the potential impact of your idea for the overall goal?
Every site whose page tree is split into distinct branches benefits: visitors who hit a dead link stay in the part of the site they came from and receive context-aware content instead of a generic error page. Editors set this up themselves by creating a page in the page tree. No site configuration changes, no integrator involvement, no deployment.
How does your Idea align with the TYPO3 Association Strategy
The job of maintaining meaningful error pages is moved to the people who own the content, the editors, without requiring technical knowledge or integrator support. This makes TYPO3 more approachable for non-technical users.
Budget for this idea?
3.000 Euro
My Name
Jan Stockfisch