Best way to setup CPT and with when large amount of fields and search facets

Support General Best way to setup CPT and with when large amount of fields and search facets

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • #50015
    TomTom
    Participant

    I am creating a directory website using Bricks that will have a number of different listing types (12 to start). There are about 200 fields (a variety of types but mainly text and select fields) that can be grouped in 35 different groups.

    Depending on the listing type certain groups of fields will not be used or displayed.

    There is also a CPT called reviews which will be related to the Listing CPT.

    I know this is a lot of fields so I am trying to build this to make adding new listings easy while still considering performance.

    Listings when displayed on the front end could also be filtered by search facets. There will also be a taxonomy for Categories.

    Considering all this what is the best way to build this out?

    I am planning to use custom tables with the field groups.

    I was thinking for the Listing having one CPT and one Listing Field Group. The fields are organized using tabs. I am assuming this offers the best performance? My one issue with this is that I have to use conditional logic on any field that needs to be hidden depending on what listing type is selected (which will be a lot). I also have to hide tabs using a code snippet.

    I was going to use Groups field and then add sub fields to make the conditional logic much easier as I can just hide the group. The problem I assume with this is that the Group and it's sub fields are just stored in one column of the table correct? Will this lead to a great decrease in performance? Will doing it this way also limit what I can use search facets on?

    I had also considered splitting the fields into different custom field groups and then creating 1 CPT for each listing type...

    I would then assign the field groups to the appropriate CPT (there by not having to worry about conditional logic on individual fields or the group field inside a field group). This way feels much messier though as listings are split apart in the Admin. While in some ways I think performance would improve since the group field is not being used I wonder about performance when combining multiple tables to display the listings in one list and with using search facets.

    Thoughts on this? Anyone see where I can approve things?

    #50017
    PeterPeter
    Moderator

    Hello Tom,

    Thanks for reaching out.

    I have some suggestions that might help you get a better way to manage fields:

    1. The group field should be used to store values. It shouldn't be used to query posts by subfield value because the subfield value is stored in a serialized array in the database. Refer to this article
    https://metabox.io/create-group-of-custom-fields-with-meta-box-group/

    2. Having too many fields on an editing page with conditional logic would impact the loading time. You can use the extension MB Include Exclude to load certain field groups when editing a post. Please follow this documentation to get more information
    https://docs.metabox.io/extensions/meta-box-include-exclude/

    If you want to use the filter or search form to get posts by field value, I think you can use top-fields (not in a group field) only. Split them into more field groups for easier management.

    #50019
    TomTom
    Participant

    Thanks for the info. I actually did decide to follow your point 1 and point 2

    So just to review in case anyone is interested or has other recommendations.

    Everything is being done using 1 CPT and 1 custom table with 35 field groups and no sub-groups. Conditional logic is on the field groups only.

    I also made the listing type a taxonomy instead of a custom field. It is my understanding this will be easier for the search facets.

    One thing I notice Peter is that I am using the taxonomy custom field to control the taxonomy as every listing needs just one. I have the switch "Remove default meta box" enabled for the field but the Gutenberg Editor still displays the Taxonomy in the side bar. It did not remove it. I am assuming this is a bug...

    I can hide it myself manually by using the following code so I am not sure why the switch doesn;t work for the MB taxonomy custom field.

    
    add_filter( 'register_taxonomy_args', 'wp_hide_taxonomy_in_gutenberg', 10, 3 );
    function wp_hide_taxonomy_in_gutenberg( $args, $taxonomy, $object_type ) {
        if ( 'listing-type' === $taxonomy && in_array( 'listing', $object_type ) ) {
            $args['show_in_rest'] = false;
        }
    
        return $args;
    }
    
    #50023
    PeterPeter
    Moderator

    Hello Tom,

    It isn't a bug. We have a note about this setting in the documentation https://docs.metabox.io/fields/taxonomy/#settings

    it doesn't work with Gutenberg (block editor) only works with the Classic editor.

    If you want to remove the default taxonomy meta box of WordPress, when editing the taxonomy: Meta Box > Taxonomies > Edit the taxonomy > Disable the option "Show on edit page". Please follow the documentation
    https://docs.metabox.io/extensions/mb-custom-post-type/#taxonomy-settings

    #50024
    TomTom
    Participant

    Sorry I missed that. I got it to work with your instructions. Thanks!

    BTW a tooltip by that setting for the taxonomy field would be helpful or changing the label to something like

    Remove default meta box from classic editor

Viewing 5 posts - 1 through 5 (of 5 total)
  • You must be logged in to reply to this topic.