Support

Account

Home Forums Add-ons Repeater Field Repeater vs Select Multiple Values

Solved

Repeater vs Select Multiple Values

  • Hello Everyone!

    Is it better to relate multiple users to a post via a ‘User’ field that allows multiple values, or a ‘Repeater’ with a child ‘User’ field?

    I want to use the latter option due to Repeaters seem to clutter the postmeta table and Admin Columns Plugin seems to show each repeaters row as another field, so 2000 users could be very messy. Also WP_Queries are more complex with repeaters.

    I am wondering the pros and cons of these different options for creating relationship of a post with multiple users. Are both do-able?

    Cheers!

  • If you want to do queries based on these values then both are problematic using WP_Query.

    A user field stores a serialized array of user IDs. To query this field you would need to to a “LIKE” meta_query 'value' => '"'.$id.'"', 'compare' => 'LIKE'. This is not a big problem if you want to query by a single user, but if you want to query by several users at the same time then you’ll need multiple meta values, on for each user. Depending on how many users you’re trying to search for at the same time this could significantly impact the performance of your site.

    Repeaters are even more difficult, there have been several discussions here and elsewhere about querying by repeater sub fields. I’m not even going to go into it because, as a rule, I refuse to try to query based on these fields, see my next statement.

    If I needed to build this I would
    1) Built the admin in a way that makes sense for the client that will make it easy for them to add information
    2) In either case I would convert the content of the ACF field into a standard WP custom meta stored the way WP likes it stored in order to make it easier to use WP_Query. This post is about repeaters, but it can be easily applied to a user field or any other type of field that stores information in non-standard ways https://acfextras.com/dont-query-repeaters/

  • Thanks John,

    That was a very informative article you wrote. Sounds like it was good I asked this question to prevent future performance issues.

    If I read everything correctly in your article. You are creating a repeater field that the client gets to use, but than each save of the post converts the repeater field values into a hidden post_meta field. Which than is easy to query.

    I gave this a try and your code works great for doing the duplicate representation of the repeater. But it stores an awful lot of information. And the repeater seems like it should be much more efficient to query since all it stores is the ID of the users.

    Take a look at the 3 different versions of storing 3 users;

    • related_members – ‘Select Multiple Values’ Option on a generic relation field
    • related_trustees – repeater with relation subfield
    • related_trustee_wp – Converted repeaters into generic post meta

    RepeatersComparison

  • Something is wrong in your conversion, you are storing the entire uer object. What you want to store is just the information that you want to search by, for example the ID if that’s what you want to do the query on, or the persons name, or whatever. Then you can do

    
    'meta_query = array(
      array(
        'key' => 'related_trustee_wp',
        'value' => array(1, 7, 2),
        'compare' => 'IN'
      )
    )
    

    The problem with the repeater is not the meta_value, it is the meta_key. Because they are not all the same then you must to a “LIKE” query on the meta_key column. You can find information on doing this here https://www.advancedcustomfields.com/resources/query-posts-custom-fields/. This is what I refuse to do.

  • Yeah when I posted my resulting database I realized I could change the return value in ACF to User ID, my bad. I can definitely see how that will be a lot more efficient in the queries. Are they automatically indexed when the value stored is an ID?

  • There is no indexing on the meta_value column, it does not matter what is in it. “IN” queries are just more efficient than “LIKE” queries on this column.

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

You must be logged in to reply to this topic.

We use cookies to offer you a better browsing experience, analyze site traffic and personalize content. Read about how we use cookies and how you can control them in our Cookie Policy. If you continue to use this site, you consent to our use of cookies.