Add option to specify filter URL type - #1558
Merged
Merged
Conversation
fix issue #139
discordier
approved these changes
May 6, 2026
discordier
left a comment
discordier
left a comment
Member
There was a problem hiding this comment.
LGTM - need to tackle the FIXME in a later release
Contributor
Author
|
fixed #139 13 years later... |
zonky2
added a commit
that referenced
this pull request
May 12, 2026
zonky2
added a commit
that referenced
this pull request
May 12, 2026
Fix PR #1558 - Update filter URL handling to support slugNget type
zonky2
added a commit
that referenced
this pull request
Aug 6, 2026
The URL parameter type ("URL type for the parameter") introduced with #1558 and
fixed up in #1563 was only honoured for filter rules that render a frontend filter
widget. ListControllerTrait::getFilterParameters() obtained the type from
getParameterFilterWidgets(), which returns nothing for rules without widget - the
usual detail page rules. Those parameters fell back to "slugNget" and were accepted
as slug as well as GET, no matter what was configured.
The type is now obtained from the filter settings themselves:
* Simple::getParameterTypes() reports the configured param_type for all parameters
of a setting, WithChildren and ExpressionRule merge the types of their children
and Collection::getParameterTypes() aggregates all settings of the collection.
* ParameterTypes::fromSetting() provides the backwards compatibility layer for
filter settings not implementing getParameterTypes(). They are treated as
"slugNget" and trigger a deprecation. The method becomes part of ISimple in
MetaModels 3.0 - adding it now would break implementations not extending Simple.
Render\Setting\Collection::buildJumpToUrlFor() builds the jumpTo URL of the detail
page as slug or as GET according to the configured type - it always used slug
before, so a rule configured as GET produced links that did not match its own
configuration.
A parameter passed via another type than the configured one now results in a 404
instead of silently rendering the unfiltered list under an URL that looks like it
is filtered. This is limited to rules without frontend filter widget; for widgets
the frontend filter handles the URL (see #1563) and a value of the wrong type stays
unused as before.
As a side effect the expensive getParameterFilterWidgets() call is gone from the
regular rendering path. It is only performed when a mismatch was detected, that is
on the path ending in a 404 anyway.
(cherry picked from commit c89ad6d)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
fix issue #139