Forum Replies Created

Viewing 15 posts - 1 through 15 (of 330 total)
  • Author
    Posts
  • in reply to: Relationship and custom rest api #9054
    Jason
    Keymaster

    Hi Sara!

    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! 🙂

    in reply to: [Piklist 0.11.3] Media Upload Multiple Images #9051
    Jason
    Keymaster

    Greetings!

    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

    in reply to: Relationship and custom rest api #9043
    Jason
    Keymaster

    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?

    in reply to: Relationship and custom rest api #9041
    Jason
    Keymaster

    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->ID shorthand. Early in our last discussion I see I made this distinction, but then at the end I used the post_has shorthand 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! 🙂

    in reply to: Select CPT and display it on another CPT #8951
    Jason
    Keymaster

    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/

    in reply to: Select CPT and display it on another CPT #8939
    Jason
    Keymaster

    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_post meta 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!

    Quick tip:
    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. 🙂

    in reply to: Select CPT and display it on another CPT #8928
    Jason
    Keymaster

    Hi @Sara!

    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 ID and 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_title is 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 'relate' to '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!

    in reply to: New Piklist Documentation #8666
    Jason
    Keymaster

    Thanks, @conkid! We appreciate the feedback! If you find any ways to improve the documentation we’d love to have folks contribute! 🙂

    in reply to: class Piklist_Revision issue #8301
    Jason
    Keymaster

    Hi @dameer!

    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!

    in reply to: 'compare' => '==' doesn't work #8300
    Jason
    Keymaster

    Hi @Koa Liber!

    All you need is ‘=’, not ‘==’. 🙂

    in reply to: $_GET, post relations #8299
    Jason
    Keymaster

    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 $query->is_post_type_archive('product').

    in reply to: $_GET, post relations #8298
    Jason
    Keymaster

    Hey Charles!

    Quick side-note, $_GET is 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! 🙂

    in reply to: Anything Piklist-specific to prevent this site hack? #8270
    Jason
    Keymaster

    To be clear, files should be set to 644 and directories to 755 as file permissions.

    in reply to: Anything Piklist-specific to prevent this site hack? #8269
    Jason
    Keymaster

    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.

    Jason
    Keymaster

    Hi @curiousprem!

    While I can’t give you a specific date, I can say it’s our top priority to get 0.10 out, as it’s our most secure version, yet. The more people that help by creating issues and, especially, pull requests, the faster 0.10 will be released!

    Thanks for checking out Piklist!

Viewing 15 posts - 1 through 15 (of 330 total)