Forum Replies Created
Glad you figured it out! I felt like it had to be something simple, as you were doing everything correctly as far as I could tell.
Happy coding! 🙂
Thank you for reporting this! Just want to let you know we have a fix in process that will be rolled out shortly: https://github.com/piklist/piklist/pull/101
Bummer, I was hoping it was as simple as that.
So, to wrap my head around this, it looks like you’re creating a custom REST API endpoint, correct? Are you extending any of the existing endpoints (i.e. WP_REST_Posts_Controller)?
Does that exact query work outside of the REST API? Have you checked the output of the function via XDebug or something to see if the query is working but something else is the issue?
Hello again, @Sara! 🙂
Hmm… that’s interesting. I work with the REST API quite a bit on my agency’s projects and use relate queries — in fact, I’m developing a React + REST component right now.
Looking back on our previous thread, I think the issue is that event post type belongs to the city post type. So your
'relate' => 'has'should be
'relate' => 'belongs', or use the
'post_belongs' => $post->IDshorthand. Early in our last discussion I see I made this distinction, but then at the end I used the
post_hasshorthand for an even query, so that may be the source of the confusion. If that’s the case, I apologize for flipping that on you!
Hope this helps! 🙂
Wanted to throw in here that I took this opportunity to improve the Relationship documentation, per our discussion: https://docs.piklist.com/tutorials/relationships/working-with-field-relationships/
Glad that was helpful! 🙂
Let’s talk about how relate data is stored for a moment. In your case you have an event post type relating to a city post type. As mentioned, in this case the event owns the city; that is to say, when creating an event the user selects which city it will be in — makes sense!
The way Piklist stores this is that in the city’s meta it adds a
__relate_postmeta key wherein the value is the ID of the event that owns it. This is later used when performing relate queries.
So if you look at the event’s meta, you won’t see anything added about the city. Why? Because it’s not designed to put anything there. Look at the city’s meta. You should find it there. For this reason, you don’t need to specify a field, as relate fields are a special type which store in their own way.
And, yes, if you only want one then remove the multiple line.
To debug this, first check the city’s meta to see if the relate data is being stored.
Next, double-check your query. Is $post a WP_Post object as you’re expecting? Is the ID what you’re expecting? Make sure you have
'suppress_filters' => false, otherwise WordPress will restrict WordPress from adjusting the query for the relate parameters (annoying that true is the WP default for that function, but is false for WP_Query queries).
If that doesn’t work, zip up the related files and shoot them over to [email protected] so we can take a closer look. I’m quite sure it’s something simple, though, and if you can figure it out you’ll be the better for it!
Since you’re doing a simple query, you can do a shorthand relate format like this:
$related_events = get_posts(array( 'post_type' => 'event', 'numberposts' => -1 'suppress_filters' => false, 'post_has' => $post->ID ));
Much easier to read and is great for simple queries. 🙂
Happy to help you with this. 🙂
First, did you happen to see this in the documentation? https://docs.piklist.com/tutorials/relationships/working-with-field-relationships/
Let’s break down your first query:
'field' => 'city_event',
You shouldn’t need this. If you do need it for some reason then the relate field isn’t working.
'choices' => piklist(get_posts(array( 'numberposts' => -1, 'post_type' => 'city', )), array('ID', 'post_title')),
What’s happening there is that get_posts() is retrieving an array of WP_Post objects that contains all of your city posts. From there, the piklist() function is “plucking” the array, meaning that it’s creating a new array from the WP_Post array wherein the new array key is the
IDand the value is the
post_title. For a relate field to work it needs the value stored (key) to be the object
ID, and the
post_titleis so the user knows what they’re looking at when selecting an option.
'relate' => array( 'scope' => 'post' ),
This is the “magic” line that sets the field up as a relate field. The scope here would either be ‘post’, ‘user’, or ‘comment’, based on what you’re connecting to. Since you’re connecting two posts, the scope would be ‘post’. If you see
'scope'in the context of the root field parameters, that’s for non-relate fields and most times doesn’t need to be worried about.
Here’s a working example of how I would structure what you’re doing:
piklist('field', array( 'type' => 'select', 'label' => 'Accociated City' 'choices' => piklist(get_posts(array( 'post_type' => 'city', 'numberposts' => -1 )), array('ID', 'post_title')), 'relate' => array( 'scope' => 'post' ), 'attributes'=> array( 'multiple' => 'multiple', ) ));
$related_events = get_posts(array( 'post_type' => 'event', 'numberposts' => -1, 'post_belongs' => $post->ID, 'suppress_filters' => false, 'relate_query' => array( array( 'id' => $post->ID, 'relate' => 'belongs' )) ));
For this, you did get just a bit mixed up. Here’s what it should be structured like:
$related_events = get_posts(array( 'post_type' => 'event', 'numberposts' => -1 'suppress_filters' => false, 'relate_query' => array( array( 'id' => $post->ID, 'relate'=> 'has' ) ) ));
First, I put
'suppress_filters'in the root level parameters where it belongs.
Next, I changed
'has'. The reason is that since the city selection is on the event page, the event has the cities, not the other way around. And since we’re querying an event, we’re saying we want to limit the events by which cities the queried event has.
Hope this helps! I think the example in the docs should help, too!
Thanks, @conkid! We appreciate the feedback! If you find any ways to improve the documentation we’d love to have folks contribute! 🙂
We just fixed this issue which will be in the next version of the 0.10 beta. We’re also pretty excited because in fixing this bug we got to do some really good optimization with revisions. It’s the little things. 🙂
Thank you for reporting!
Hi @Koa Liber!
All you need is ‘=’, not ‘==’. 🙂
Also, if this code is using the pre_get_posts hook, keep in mind that given the current restrictions, it will change the arguments of every single query that isn’t admin-side. You probably will want to do more things such as
$_GETis a superglobal and will always exist. You don’t have to check if it’s falsey — i.e.
if ( $_GET ). It will also always be an array, even if empty, so the foreach alone is harmless. 🙂
So, just to be clear, the CPT’s are connected using the related fields? Unless you want it to be bi-directional, that may not be necessary. Also, it won’t work as you’re hoping because you’re using titles/slugs in the query parameters (e.g.
color=white), but relationships are stored/retrieved by their ID. So unless the query parameters are using numeric IDs, which doesn’t look as nice, this won’t work.
Assuming you just need to know if this post type is related to them, however, then you could just use simple fields admin-side and store the meta based on the title or slug of the other post. This idea would then work pretty easily.
Hope this helps! 🙂June 2, 2017 at 12:57 pm in reply to: Anything Piklist-specific to prevent this site hack? #8270
To be clear, files should be set to 644 and directories to 755 as file permissions.June 2, 2017 at 12:57 pm in reply to: Anything Piklist-specific to prevent this site hack? #8269
The most common method for causing file permissions issues that I’m aware of is loading files via FTP. It’s up to the server to apply the right permissions, but it’s not good to assume this. So when files are added via FTP, there’s a good chance the permissions aren’t what they ought to be.
I personally use WP Engine for hosting in my business, and their security is solid. They have a partnership with Sucuri, which gives us access to them when resolving hacks. Otherwise, I’ve heard good things about Wordfence.June 2, 2017 at 11:32 am in reply to: Pretty Powerful Framework but when can we expect the stable version #8267