ryanwelcher
Post meta query placeholders for dynamic values
There has been a few requests for the ability to use a dynamic value in post meta queries. We'll need to add the placeholder values in into the Meta Value field and define an easy way for users to use them. Perhaps an autocomplete style field similar to how we're handling the meta keys would work.
Non-comprehensive list:
- Current Post ID
- Author ID
- User ID ( if logged in )
- Current Date
- Last 1/3/6/12 months from current date.
Related: #38, Support forum topic 1
That would be a great addition to AQL, enabling e.g. ACF relationship field queries.
Meta queries, where not my list, but 3/4 of this non-comprehensive list are already implemented in my fork (of this great plugin).
Please have a look at https://github.com/carstingaxion/additional-advanced-query-loops/tree/contextual-query-loop and some images at https://github.com/carstingaxion/additional-advanced-query-loops/issues/10
For sure we could share some (more) code to make things work for your & and my use-case.
... but 3/4 of this non-comprehensive list are already implemented ...
4/4 Done !
Querying posts by the currently logged-in user, was nothing I had planned before, but with my existing code it was just a little copy-paste & and minor changes.
https://github.com/ryanwelcher/advanced-query-loop/assets/198883/31c1b824-0d5a-4d3d-b630-b8abb60aa856
@carstingaxion, I would love to see a PR for this to add it to the plugin.
@carstingaxion, I would love to see a PR for this to add it to the plugin.
Cool thank you @ryanwelcher and yes, I would appreciate that.
But which part are you referring to? The whole contextual-query-block or just the 4 aspects mentioned here?
I thought about forking, contributing and re-publishing just recently and am wondering, if we - you and me - should publish the contextual-query-block as separate plugin to the repo. The thought came from the realisation, that I disabled more and more of your controls within my plugin, because they didn't made any sense, when querying by context. What do you think (more in general)?
In addition, when we both put all our controls within slots, we could and should be able to merge all in, because this would allow me to just unregister your controls from the block, instead of commenting them out in code.
But which part are you referring to? The whole contextual-query-block or just the 4 aspects mentioned here?
I'd be interested in any feature you'd be wiling to create a PR for. Keep in mind that smaller changesets are easier to review and test so perhaps a PR for each feature is best.
I thought about forking, contributing and re-publishing just recently and am wondering, if we - you and me - should publish the contextual-query-block as separate plugin to the repo. The thought came from the realisation, that I disabled more and more of your controls within my plugin, because they didn't made any sense, when querying by context. What do you think (more in general)?
While you're welcome to do so, I'm going to stick with adding features to AQL directly. I'd rather users who have the plugin installed can keep using it and benefit from new features as they become available.
Current Post ID
+1 for ability to use a placeholder for Current Post ID in meta queries.
My scenario is to display a list of the Tracks on a Recording (CD, DVD, vinyl ) where the Tracks post type has a postmeta field that refers to the Recording's post ID. I'd prototyped the query in a Recording's post.
<!-- wp:query {"queryId":1,"query":{"perPage":10,"pages":0,"offset":0,
"postType":"oik-track","order":"asc","orderBy":"meta_value_num","
author":"","search":"","exclude":[],"sticky":"","inherit":false,"parents":[],"format":[],"include_posts":[],
"meta_query":{
"queries":[
{"id":"e8f5c5bb-80af-48f4-845e-242cb8a093df",
"meta_key":"_oikt_track","meta_value":"","meta_compare":"\u003e="},
{"id":"72dc05fc-9065-4684-b189-6419bc8cd14b",
"meta_key":"_oikt_recording","meta_value":"1624","meta_compare":"IN"}],"relation":"AND"}}
,"namespace":"advanced-query-loop"} -->
To make it work I hard coded the post ID 1624. But in order to be able to use this query in a single recording post template I need the meta_value to be replaced by the current post ID.
For the time being I'll implement a filter hook for the aql_query_vars filter.
we would be open to sending coffee to get this going. Current Post ID and Current Date would be very useful
