Tell us what you are trying to do?
I'm in the setup stage. Looking for Best Practices on a world event calendar directory. I'm wondering is this setup would cause performance issues later on or if I should go about a different way of setting this up. At first I was going to set it up via Taxonomies but thinking about setting it up with Custom Posts with Post Relationships.
Continent (custom post type (max 6 posts))
+Country (custom post type (about 100-150 posts) with one to many relationship from Continent)
++State (custom post type (about 1000 posts) with one to many relationship from Country)
+++Event (customer post type (roughly 2000-3000+ post) with one to many relationship from State)
Would I incur performance issues down the road because of this setup (ignore hosting)? Would it be difficult for organizers to provide the location (Continent, Country, State) when submitting an event via a front-end form? Would it be better to do this with Taxonomies?
Is there any documentation that you are following?
Not really.
Is there a similar example that we can see?
Haven't found one.
What is the link to your site?
On my local laptop.
Hello, in general taxonomies are more performant than post relationship or even custom field queries, because of how WordPress' database design is implemented. Taxonomy queries are indexed more efficiently, and require fewer table joins. Toolset's post relationship queries have been vastly improved over the last couple of years, but they cannot compete with a simple taxonomy query.
Let's review the post relationship approach pros and cons. When adding Events using a Form, your Users would be able to select a parent post (but only one parent post) in the Event creation Form. There is no built-in system for selecting hierarchical ancestors, so they could not first select Continent, then Country, then State hierarchically. That type of system would have to be constructed using generic fields and some type of Forms Conditional logic. It would not be straightforward. Another limitation is you can only add one post relationship custom search filter to a custom search View. You could show all the ancestors in filters, but you would not be able to add any other post relationship filters. For example, if you connected Country to another post type Language in a many-to-many relationship, you would not be able to add this filter to a search for Events that includes the Continent > Country > State filters.
With post relationships, each Continent, Country, State and Event post gets its own post URL. That may or may not be desired.
Now the taxonomy pros and cons. First of all, there is no Form to add or edit taxonomy terms directly. You can add terms to any post while you create that post. However, taxonomy queries are faster in Views and you can add multiple taxonomy filters to the same custom search View. Each term does not get its own custom post URL, but does get an archive URL automatically. It is also somewhat easier to manage a post's terms in wp-admin, since you get typeahead options and checkboxes in the taxonomy metabox.
Let me know if you have additional questions about that.
Thank you for the input, much appreciated. I might have to go back to the drawing board again...
Both have pro and cons and I'd rather have the built-in performance on my side anywhere I can get it.
If I pre-populate the taxonomies (Continent, Country) can I load the values into a dropdown field for the front-end form?
Yes, when you create a custom taxonomy search filter in a custom search View, the existing terms will be automatically loaded into the filter options for you. There's nothing you need to do manually to make the terms appear in the filters. Assuming you use separate taxonomies for Continents and Countries, you will add two separate taxonomy filters to the View. If you choose the option to "only show available options for each input" in the View configurations, selecting a Continent filter on the front-end will trigger an update in the other filters so only the terms in posts that contain the selected Continent term are available in the other filters. Note that for complex sites, this can have a performance impact, but it makes searching more intuitive on the front-end (e.g. you cannot select the Country term "Mexico" when the Continent term "Africa" is selected). Turning off this option is more performant, but will not prevent User from selecting search filters that produce empty result sets.
I went back and forth on setting this up, tried a couple of options. In the end I ended up with 1 taxonomy and 3 CPT with post relationships. It would be cool if there was a video or more documentation on this topic since I think it's a common reason for people using Toolset.
My issue is resolved now. Thank you!
