Add back() support to the response redirect API and align redirect helpers around it
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 48/100
Research direction
Start by reading src/Http/Response.php, src/Http/Traits/Response, src/Http/Helpers/http.php, and src/App/Enums/ReservedKeys.php to understand existing redirect and old-input behavior. Trace the current referrer fallback usage and define the response-level API and no-referrer fallback before changing helpers. Done means back-navigation support exists, helper behavior remains coherent, and redirectWith() still preserves old-input/session behavior.
Written by the indexing model from the issue text.
Description
Summary
Add first-class “go back” support to the HTTP response redirect API.
The goal is to stop repeating manual referrer fallback patterns such as redirect(get_referrer() ?? base_url()) and provide a cleaner redirect-back flow through the response layer.
Why
The current HTTP helper surface already supports:
redirect(string $url, int $code = 302)redirectWith(string $url, array $data, int $code = 302)get_referrer()old(string $key)
But the codebase repeatedly uses manual “back” logic such as:
redirect(get_referrer() ?? base_url())redirectWith(get_referrer() ?? base_url(), $data)
This creates repeated fallback logic in controllers, middlewares, and templates, and it exposes redirect implementation details at call sites instead of making “go back” a first-class response capability.
Goal
Introduce a clear back() redirect flow at the response/API level and align helper usage around it.
Proposed Direction
Add response-level back redirect support
Add a response API for redirecting back, with a defined fallback behavior when no referrer is available.
The exact shape can be decided during implementation, but it should support a response-first flow such as:
response()->back()- or
response()->redirect()->back()
Preserve helper convenience where appropriate
If helper compatibility is desired, provide helper-level support that delegates to the response API rather than keeping manual fallback patterns spread throughout the codebase.
Examples of the intended cleanup direction:
redirect(get_referrer() ?? base_url())redirectWith(get_referrer() ?? base_url(), $data)
should become a cleaner first-class back-navigation API.
Define fallback behavior explicitly
The implementation should define what happens when no referrer exists.
A sensible default appears to be current behavior:
- fallback to
base_url()
but this should be an intentional contract rather than repeated ad hoc logic.
Keep old-input behavior aligned
Current redirectWith() behavior stores previous request data in session for later retrieval via old().
The new back-navigation flow should be designed so old-input redirect behavior remains coherent and can fit naturally into the redirect API.
Acceptance Criteria
- response-level back-navigation redirect support exists
- manual referrer fallback patterns are no longer required for common “go back” redirects
- fallback behavior when no referrer exists is explicitly defined
- helper-level redirect behavior remains coherent with the response API
- current old-input/session redirect behavior remains supported
- the resulting API is suitable for follow-up cleanup of templates and generated module code
Notes
Relevant code:
src/Http/Helpers/http.phpsrc/Http/Response.phpsrc/Http/Traits/Responsesrc/App/Enums/ReservedKeys.php
Examples of current repeated usage exist across module templates, controllers, and middlewares.
This ticket should come before the follow-up cleanup ticket that updates templates to prefer the new response redirect style.
- Dominant language
- PHP
- Stars
- 36
- Forks
- 22
- PR merge metrics
- No merged PRs in 30d
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from quantum-php/framework
-
routing testing
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
quantum-php/framework#547 ·
-
view
Difficulty 1/5 Under an hour Newbie friendliness 75/100
quantum-php/framework#542 ·
-
enhancement http
Difficulty 5/5 Over a week Newbie friendliness 35/100
quantum-php/framework#565 · 1 comment ·
-
components view
Difficulty 5/5 Over a week Newbie friendliness 42/100
quantum-php/framework#551 ·
-
Add explicit @version special route token support for API major versioning within a single module Openrouting
Difficulty 5/5 Over a week Newbie friendliness 45/100
quantum-php/framework#550 ·
All issues in quantum-php/framework
Similar issues
-
a11y admissions.uiowa.edu needs grooming SiteImprove best practice
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
Save States Menu Open
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
pluginsGLPI/datainjection#673 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
octobercms/october#6130 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
getgrav/grav-plugin-form#656 ·