fix(pick): evaluate magic tags in pick_where and pick_having - #7595
Open
faisalahammad wants to merge 3 commits into
Open
fix(pick): evaluate magic tags in pick_where and pick_having#7595faisalahammad wants to merge 3 commits into
faisalahammad wants to merge 3 commits into
Conversation
PodsField_Pick::get_object_data() was passing the legacy positional
true to pods_evaluate_tags() for the pick_where and pick_having
clauses, so the evaluator had no pod/id context. Tags like {@id},
{@post_title}, and {@name} fell through to a superglobal-only resolver
and came out blank in the SQL, breaking the related-items filter.
Build a tag-eval args array that, when an id and a resolvable pod
reference are available, instantiates (or reuses) a Pods object for
the current item and passes it as the 'pod' arg. Falls back to the
previous no-pod behaviour for empty ids and unresolvable pod refs.
Fixes pods-framework#7406
faisalahammad
requested review from
JoryHogeveen and
sc0ttkclark
as code owners
August 9, 2026 17:15
Contributor
Author
|
AI disclosure: this PR was written with Claude Opus 5 assistance, reviewed and tested by me. |
Signed-off-by: Faisal Ahammad <faisalahammad24@gmail.com>
…aving
Passing a Pods object so {@id} and {@post_title} resolve also changed how
{@get.X} behaves, because pods_evaluate_tag() routes everything through
Pods::do_magic_tags() once a pod is present.
Two problems follow. Pods::process_magic_tags() only falls back to the general
resolver when PODS_SHORTCODE_ALLOW_EVALUATE_TAGS is defined and true, so with
the default configuration {@get.X} in a where clause silently resolves to
nothing where it previously read the query string. And when that constant *is*
enabled, the fallback calls pods_evaluate_tag() with no arguments, dropping the
sanitize flag the caller asked for and putting raw request data straight into a
SQL clause.
pods_tag_is_context_scoped() identifies tags that address an ambient context
(superglobals, options, transients, url helpers) and
pods_evaluate_tags_in_context() evaluates those without the pod argument, so
they reach the general resolver with sanitize intact. A field that genuinely
exists on the Pod still wins, so traversal such as {@author.display_name} is
unchanged.
Refs pods-framework#7406
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
1 participant
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.
Description
Magic tags like
{@id},{@post_title}, and{@name}in Relationship / Pick fieldpick_whereandpick_havingclauses were coming out blank in the resulting SQL.PodsField_Pick::get_object_data()passed the legacy positionaltruetopods_evaluate_tags()for these clauses, so the evaluator had no pod or item-id context. Tags then fell through to a resolver that only reads superglobals, which returns nothing for item-scoped tags, and the related-items query matched the wrong rows (or none at all).The fix builds a tag-evaluation args array that, when an item id and a resolvable pod reference are available, instantiates (or reuses) a
Podsobject for the current item and passes it as thepodarg. The tag evaluator then resolves{@id},{@post_title},{@name}, and similar tags against the current item. For empty ids or unresolvable pod references it falls back to the previous no-pod behaviour, so existing{@get.X}usage is unaffected.Related GitHub issue(s)
Fixes #7406
Testing instructions
mainword, with a Relationship field pointing at a related pod, e.g.conjugation.mainword.id = {@id}ormain_word.post_title = {@post_title}.mainword.id =. After the fix it contains the resolved id, e.g.mainword.id = 1051.pick_where, and changes when you switch to a different main item.{@get.X}tags (e.g.{@get.post}) still evaluate from the URL query string as before.Screenshots / screencast
No UI changed, none to show.
Changelog text for these changes
Bug: Resolve magic tags like
{@id},{@post_title}, and{@name}in Relationship / Pick fieldpick_whereandpick_havingclauses against the current item context. #7406PR checklist