Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Regression in CE admin/backend route handling after `lupus_ce_renderer` 2.6.0 (`406` + "Client error" instead of backend redirect flow)
Project
- `lupus_ce_renderer`
Environment
- Drupal 11
- Decoupled Nuxt frontend consuming CE API routes
- `lupus_decoupled_ce_api` enabled
- CE API requests via `/api/drupal-ce/...` (rewritten to `/ce-api/...` in middleware)
Known-good versions
- `drupal/lupus_ce_renderer: 2.5.0`
- `drupal/lupus_decoupled: 1.4.1` (or `^1.2`)
Problematic versions
- `drupal/lupus_ce_renderer: 2.6.0` (also observed with newer dev combinations)
Summary
After upgrading `lupus_ce_renderer` from `2.5.0` to `2.6.0`, backend action routes requested through CE API no longer follow the previous redirect flow. Instead, requests return `406 Not Acceptable` / CE `"Client error"` payloads, causing frontend navigation failures (Nuxt `"Page not found"`).
Steps to reproduce
1. Enable `lupus_decoupled_ce_api` and `lupus_ce_renderer`.
2. Use frontend routes that trigger backend action URLs:
- `/admin/content`
- `/node/{id}/edit`
- `/node/{id}/export`
3. Observe CE API requests such as:
- `/api/drupal-ce/admin/content`
- `/api/drupal-ce/node/{id}/edit`
- `/api/drupal-ce/node/{id}/export`
Expected result
- Backend/admin action routes should reliably resolve to redirect behavior that allows users to continue in Drupal backend context.
Actual result
- HTTP `406` responses and CE error payloads (`"Client error"` / `"This page is not available in custom elements format."`).
- Frontend breaks instead of reaching Drupal backend route.
Impact
- Admin/editor flows fail from decoupled frontend.
- Core backend actions become unusable through existing CE navigation patterns.
- Production risk for decoupled sites relying on backend-action links.
Evidence from code-path changes (2.5 -> 2.6)
- `CustomElementsViewSubscriber` changed behavior from direct redirect response for unsupported CE routes to throwing `NotAcceptableHttpException` and delegating to `on406`.
- `CustomElementsHttpExceptionSubscriber` added new `on406` admin/theme detection logic; when admin detection fails, it serves `4xx` CE payload instead of redirect.
- `CustomElementsFormatSubscriber` tightened HTML response blocking in CE-enabled requests.
Likely root cause
- `on406()` admin-route/theme detection misses valid backend action routes in some route/theme/proxy combinations, so requests fall back to CE `4xx` payload instead of redirect flow.
Proposed solution (upstream)
Option A (targeted, low-risk)
- In `on406()`, add explicit backend route/path fallback handling for known backend action patterns (for example: `/admin/*`, `/node/{id}/edit`, `/node/{id}/export`) when CE API context is active, returning redirect behavior instead of `4xx` payload.
Option B (compatibility-focused)
- Restore 2.5-style redirect behavior for unsupported CE routes in backend/admin contexts, while preserving loop-protection for CSR-only frontend routes.
Option C (hybrid)
- Keep current 2.6 architecture, but broaden `"admin-like"` detection criteria:
- `_admin_route`
- negotiated admin theme
- backend action path heuristics
- CE API request carrying original backend path intent
Temporary workaround
- Pin `drupal/lupus_ce_renderer` to `2.5.0` until upstream fix is released.
Issue fork lupus_ce_renderer-3580608
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
glynster commentedComment #3
glynster commentedComment #4
fagodo you have a configured admin_theme? I guess this fails if there is no configured admin_theme that differs from the default_theme.
In a fully decoupled setup this might be quite common. So maybe we should skip the admin_theme check and always redirect 406 errors if we have a decoupled-frontend configured. Technically lupus_ce_renderer does not know it.
Problem is we might end-up in redirection loops if we are on a frontend-route that results into a 406.
Comment #6
fagook, I found the problem. We were not redirecting admin-routes when no admin_theme is configured that differs from the dfeault theme. That's wrong, we should always redirect admin-routes. I added a test to ensure this + documented behavior.
Please make sure to have the setting "use administration theme for content editing" under appears on (which is on by default). Then it should work with the fix. I'll release it as 2.6.1
Comment #8
fagoComment #10
glynster commented@fago. Thanks so much for the quick response everything works as it should again!