Support

Account

Register Login

Forum Replies Created

  • Hi Elliot,

    I just found out more. Both the values of the key and reference fields are correct in the database. But because I’ve manually created the fields, the values of the reference field in the acf_ post type didn’t correspond. I was thinking the values didn’t match because I was looking at the ‘key’ value in the admin side of ACF instead of directly in the database.

    I’ve tried editing the values of the reference field directly in the database, but that breaks the group admin side stuff of ACF. So I’ve tried exporting the field groups, editing the reference values in the XML and then importing. It worked for some fields, but others have now disappeared.

    It seems that my sloppy import/export actions and manually creating the fields have messed things up and this conversation did bring up the actual problem at hand so I’ll mark it as solved.

    I can let you know if I fixed everything for if you like to write something on migration in the future or if other people encounter the same problems.

    Thanks again!
    Joost

  • Hi Elliot,

    Yes I did… That’s not so smart of me, but luckily we’ve got it figured out now.

    One question though so I fully understand; in the database both value and reference fields are there: eg f_city and _f_city. So why can’t get_field('f_city') find the value?

    Does that mean that there’s another table with information on the reference field? I don’t really understand why information is in the DB, also viewable on the admin side but not queryable on the front-end.

    Thanks for you time,
    Joost

  • Hi Elliot,

    Yes this was WP export data and then WP import data (xml).

    All the custom field values exist in the database and for each value there’s a hidden value with the same field name with an underscore before it.

    But because you pointed this out, I’ve just compared values of the reference field (by turning on ‘key’ in the screen options) and they don’t match. I don’t know why, I guess the import and/or export screwed up.

    Should everything work if I update the values of the reference fields? We’re talking 700+ custom posts, so then I’d make a loop which goes through all the posts and then use update_post_meta($post_id, '_f_city', 'field_correct_value');.

    Thanks,
    Joost

  • Hi Elliot,

    Everything is clear now, thanks a lot for your help!

    Would be awesome if I could to the complex coding, unfortunately I can’t :-).

    It seems that I should go with the relationship field on the root level. Because when I’d use p2p, I’d have to do the same (since p2p can’t be in a repeater field). On the other hand I think the p2p query will be faster due to the architecture of having a separate DB for connections, do you I agree?

    I’ll mark this question as solved.

    Cheers,
    Joost

  • I just gave p2p a shot and it indeed does exactly what I want.

    Going through the documentation, I’ve found this (see here):

    // Create connection
p2p_type( 'YOUR_CONNECTION_TYPE' )->connect( $from_id, $to_id, array(
	'date' => current_time('mysql')
) );

// Delete connection
p2p_type( 'YOUR_CONNECTION_TYPE' )->disconnect( $from_id, $to_id );

    It is possible to use ACF with my setup as described above (artists custom post types as relationship fields in repeater fields) and then add the above p2p code when I’m adding and deleting artists?

    Because then I can:

    • Use my preferred ACF setup (relationship fields in repeater fields)
    • Which results in that I don’t have to use the p2p admin box for adding artists
    • I can use the p2p queries which solves my querying problem!

    The only question that remains is: what happens when I add an artist in one repeater block, and then add the same artist in another repeater block? The documentation of p2p says about the code above: ‘The advantage of using this API is that it enforces all the rules you set when defining the connection type, such as ‘prevent_duplicates’ and ‘cardinality’.’ So I guess it will check for duplicates? The link to this p2p documentation here.

    I think we’re almost there :-).

  • Hi Elliot,

    Thanks for your reply. I had another question on this forum where you also suggested to use posts2posts. It looks like it’s the solution, but I don’t want to rely on another plugin (which has cancelled support). So I’m trying to find a solution with only using ACF.

    I have about 700 events and 8000 artists, so changing the relationship field to a post_object field isn’t an option. Then I’d have to select an artist out of a drop-down with 8000 artists…

    Every event can have more than 100 artist, so I hope my whole concept won’t be limited by performance issues.

    I did notice that I can put the Return Format from Post Objects to Post IDs. So on an event page, for each artist I can do:

    $artist = get_field('artist');
foreach ($artist as $artist_id) {
	echo get_permalink($artist_id);
        echo get_the_title($artist_id);
	etc...
}

    If I look at the way all the artists are stored in the DB for each event, it is:

    Array ( [0] => 10001 [1] => 10002 [2] => 10003 [3] => 10004 [4] => 10007 [5] => 10008 [6] => 10009 [7] => 17497 )

    Which looks much leaner than when I put the relationship setting to the return format Post Objects (because than it saves a lot more artist postdata in the array, which I don’t really need since I can get all postdata with just the ID).

    If I make a repeater field, in which I put a relationship field which has Return Format set to Post IDs, would that simplify my query? Is it then possible to find all events which have one particular artist post ID?

    Thanks in advance!

  • Hi Elliot,

    I understand. Thanks for your help!

    Joost

  • Hi Elliot,

    Thanks for the reply. Would you consider implementing this? If so; I can add it as a feature request. I think it would make the relationship field a lot more powerful!

    Cheers,
    Joost

Viewing 8 posts - 1 through 8 (of 8 total)