Skip to content
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.

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

Post meta query placeholders for dynamic values #54

Open
ryanwelcher opened this issue Apr 30, 2024 · 8 comments
Open

Post meta query placeholders for dynamic values #54

ryanwelcher opened this issue Apr 30, 2024 · 8 comments
Labels
enhancement New feature or request

Comments

@ryanwelcher
Copy link
Owner

ryanwelcher commented Apr 30, 2024

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

@ryanwelcher ryanwelcher added the enhancement New feature or request label Apr 30, 2024
@philbraun
Copy link

That would be a great addition to AQL, enabling e.g. ACF relationship field queries.

@carstingaxion
Copy link

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 carstingaxion#10

For sure we could share some (more) code to make things work for your & and my use-case.

@carstingaxion
Copy link

... 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.

Bildschirmaufzeichnung.vom.26.05.2024.12.37.17.mp4

@ryanwelcher
Copy link
Owner Author

@carstingaxion, I would love to see a PR for this to add it to the plugin.

@carstingaxion
Copy link

@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)?

@carstingaxion
Copy link

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.

@ryanwelcher
Copy link
Owner Author

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.

@bobbingwide
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants