Skip to content

[Routing] Allow query-specific parameters in UrlGenerator using _query #60508

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 1 commit into
base: 7.3
Choose a base branch
from
Open

[Routing] Allow query-specific parameters in UrlGenerator using _query #60508

wants to merge 1 commit into from

Conversation

BenMorel
Copy link
Contributor

Q A
Branch? 7.3
Bug fix? no
New feature? yes
Deprecations? no
Issues -
License MIT

This PR adds support for a special _query key in $parameters of UrlGenerator::generate(), that is used exclusively to generate query parameters. This is useful when query parameters may conflict with route parameters of the same name.

Concrete use case:

My application has a route that looks like:

https://{siteCode}.{domain}/admin/stats

And I want to generate this URL:

https://fr.example.com/admin/stats?siteCode=us

With this PR, I can now call:

$urlGenerator->generate('admin_stats', [
    'siteCode' => 'fr',
    'domain' => 'example.com',
    '_query' => [
        'siteCode' => 'us',
    ]
]);

@carsonbot carsonbot added this to the 7.3 milestone May 22, 2025
@carsonbot carsonbot changed the title Allow query-specific parameters in UrlGenerator using _query [Routing] Allow query-specific parameters in UrlGenerator using _query May 22, 2025
@OskarStark OskarStark changed the title [Routing] Allow query-specific parameters in UrlGenerator using _query [Routing] Allow query-specific parameters in UrlGenerator using _query May 22, 2025
@OskarStark
Copy link
Contributor

If someone is using _query already, it could be a BC break, which would need a deprecation first.

@BenMorel
Copy link
Contributor Author

If someone is using _query already, it could be a BC break, which would need a deprecation first.

I agree, unless it is considered that names starting with an underscore are reserved for Symfony, and not covered by the BC promise; I don't know about this, but there's a precedent here with _locale.

@stof
Copy link
Member

stof commented May 22, 2025

The difference is that _locale exists since the beginning of Symfony.

A better example might be to look at how we handled _fragment. I'm almost sure we added it later.

@BenMorel
Copy link
Contributor Author

@stof Good point. _fragment was introduced in 2014, in 6d79a56, PR #12979, and was first released in v3.2.0 — a minor release.

The BC break concern was raised by @Koc back then, but was dismissed by @Tobion:

And the tiny BC break is negligible because it's unlikely.

I'll leave it up to you to decide whether introducing another one in a minor release is still acceptable in 2025; maybe this is something that could be documented in Our Backward Compatibility Promise?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
Feature Routing Status: Needs Review
Projects
None yet
Milestone
7.3
Development

Successfully merging this pull request may close these issues.
4 participants
@BenMorel @OskarStark @stof @carsonbot