[Resolved] Posts or Field Groups?

[Author]

Posts

[Ljuba]

Tell us what you are trying to do?

I have essentially same topic with two scenarios and I need advice how to do it.

1) First is hierarchical administrative subdivision.

2) Second is Climate types.

So, Sites, Places, Business and Events belongs to MAIN POST TYPE - Destinos (Destinations). If I set subdivisions by selection fields, I can nesting them in repeatable groups RNG and at fron-end disable repeating fields, what will fulfill requirements ans solve issue. For such reasons, is more indicative second scenario and probably than I should to stick to principle (or it is no reasons for that). Here, obviously desirable option will be to choose posts, as than I can create posts when province or whatever I will need, what is significantly less than MUST TO DO Field Values (ie - only parishes are 1500).

One Destino can get more than one (of 46) climate type. Example, Canoa have 2 types, but every Site (or other child post types) can get only one and should to be able to choose from parent (2 types, not from all 46 types). Here, if I will not work with quite complicated relationships with other divisions of post types (ie - above administrative subdivisions), I will not get to be limited to 2 climate types (or I will be? - this is one question). To simplify, if Destination belongs to one Parish and Parish have parent post type Climate Types (belongs to 2 types), than Destination should to have available only 2 climate types, right?

QUESTION

It is (at least, for me) much more simple to do within RNG, but I cannot see options in my (ie) Site Post. Is it problem regards the BUG in current development, or get wrong concept in my mind?

Is there a similar example that we can see?

Yes, Beda and Minesh knows for URL.

What is the link to your site?

Beda and Minesh knows for URL.

[Minesh]

Hello. Thank you for contacting the Toolset support.

Well - first of of, you should go with relationships, the simple reason is that it will later allow you to display related posts and you can query them as well with custom search.

To simplify, if Destination belongs to one Parish and Parish have parent post type Climate Types (belongs to 2 types), than Destination should to have only 2 climate types, right?
==> So, I would like to know where exactly you are aiming to display such posts - in wp-admin when you edit post with post relationship box? There is no such filter available to display such filtered posts with post relationship box.

[Ljuba]

You confuse me (or I wasn't clear).

Destination is post type and it belongs to some Parish (it is or parent post type or selectable field). So, first important fact is that Destination can be many thinks. Destination can be (ie Coastal) Region, Province, Canton, Parish, sometimes also Neighborhood.

If Destination is Parish, it can to have ie 2 climate types as parish can get Coastal sites and Inland sites (2 different climate types - of totally 46 for entire Ecuador). So, Destination child post Site can be Beach, it have coastal climate type, but if it is some eco Farm, it have inland climate type. Also, Business (Destination child post) can be situated on the coast (Surf school) or could be Gasoline Station (inland climate type).

This is the case (2 climate types of 46), here in this one Parish, but some other destination can get even 9 climate types (all different that this 2, in example).

So, my question is how to get (in CRED, not back-end) option that regards the selected Climate Type in Destination, creating child post types (Sites, Business, Places and Events), I have available ONLY CLIMATE TYPES available for that destination (and not all 46 types)?

1) Destination selectable fields (Climate Types) or

2) Destination child post type (Climate Types)

In other words, only Destination selected options should to be choice for child posts and not all options.

I ask this as I'm not yet on CRED and/or Views. I'm still struggle with Types vs BUG on Repeating Fields. Until it is solved, there is no sense to work on CRED and Vies. However, I want to finish settings of Types (posts and fields). That's why I ask it.

[Minesh]

So, my question is how to get (in CRED, not back-end) option that regards the selected Climate Type in Destination, creating child post types (Sites, Business, Places and Events), I have available ONLY CLIMATE TYPES available for that destination (and not all 46 types)?
1) Destination selectable fields (Climate Types) or
2) Destination child post type (Climate Types)
In other words, only Destination selected options should to be choice for child posts and not all options.
===> I understand what you are saying but there is no native feature available using which you should filter the posts displayed with the parent dropdown select.

However - If you can share problem URL and access details and share all required details which posts should be displayed with parent dropdown as a test case example - I would like to give a try by adding one custom hook.

If the custom hook will not work - I will take this as a new feature request.

*** Please make a FULL BACKUP of your database and website.***
I would also eventually need to request temporary access (WP-Admin and FTP) to your site. Preferably to a test site where the problem has been replicated if possible in order to be of better help and check if some configurations might need to be changed.

I would additionally need your permission to de- and re-activate Plugins and the Theme, and to change configurations on the site. This is also a reason the backup is really important. If you agree to this, please use the form fields I have enabled below to provide temporary access details (wp-admin and FTP).

I have set the next reply to private which means only you and I have access to it.

[Nigel]

Hi Ljuba

I've been asked to take over this, and I want to understand your requirements before getting into implementation details.

Let me first make one observation. Where Minesh recommended implementing this with post types and relationships because that would allow you to display related posts and query them, I would clarify that this is also possible when using repeatable field groups.

However, repeatable field groups are not helpful for your project because they are not currently supported in Toolset Forms, you can only add them in the back-end. We plan to support them in Forms, but I honestly can't say when.

So, you will need to base your solution on related custom posts.

Here's what I have understood about your issue from reading the above.

You have a custom post type "Destinos" and this is a parent for various other post types such as Sites, Places, Businesses etc.

You also have something else, a "Parish". (We are talking a la parroquia here, yes, which is effectively some geographical region?)

And Parishes have a range of possible Climate types (from 46 possible climates).

One particular Parish might have 2 possible climate types.

Then, if a Destino is "connected" to that Parish then that Destino should be known to have the same 2 possible climate types, and any child post of the Destino (e.g. a business) would also be known to have those same 2 climate types.

Is that an accurate summary of the problem?

And the question is one of implementation?

It is normal to avoid duplication of data, so is it a requirement that the business stores the climate types, or is it sufficient to infer them from the relationships when you display a business?

Or, maybe what you are asking is that when a Business is added to a Destino the Business must choose which Climate type it has (e.g. coastal or inland) and that the list of possible Climate types for such a Business should only include the two Climate types of its Destino parent rather than being presented with a list of 46 Climate types to choose from?

[Ljuba]

Hi,

Thanks to take it.

P.S. "However, repeatable field groups are not helpful for your project because they are not currently supported in Toolset Forms, you can only add them in the back-end."

Wooov. Extremly valuable information and I can't understand how I never before get it (I waited for RG for nothing). Actually, here you now triggered one very important issue.

Is it better to downgrade to Types 2 (as I opened several tickets with main and collateral BUGS related to RG and functionality of fields)? Issue is that I'm not sure how migration to Types 3 will work well, as my previous working sites are broken after upgrade (also your ticket with 'horario').

INITIAL REMARKS

1) Destinos (Destination) are exactly that. They can be anything within hierarchy (ie - administrative division). So, Destino (Destination) can be Region, Province, Canton, Parish (mostly, but not exclusively > City) and/or Neighborhood (totally 20000+ Destinations). As well, Gastronomy Destinations (totally 4) (second field group or custom post type - what is the topic). Finally, Altitudinal Destination (over 40), Hydrographic Slope Destination (over 12), Idiomatic (over 40), Ethnographic (over 20), Touristic (6) or Climate Zone (here, 46 totally).

2) EXCLUSIVE purpose of Destinations are Search/Filtering. Briefly, where you want to go? What should be your destination? .... So, you will look for Sites (attractions), Places (non commercial spots), Businesses, Events within area of Huaroani indigenous people (Ethnically destination area), as you want to experience there culture, language, gastronomy, sites, .....

It mean that any characteristic of Destinations (mostly) will not be part of the POSTS (ie - Business will not show at front-end Climate Type, or Huaroani ethnic are).

3) MAIN characteristic is that any front-end post type will not be possible to get more than ONE Destination types (ie - it belongs ONLY to one Canton, ONLY to one Climate Zone, ONLY to one Hydro Slope, ....), as every one of FIVE MAIN POST TYPES are very limited regards physical size (they are basically - PHYSICAL SPOTS within Destino in sense of Destinations like wider physical space).

4) FINAL Obviously, Entire Destination structure (posts, field values, taxonomies, I will create in Backend as administrator (no CRED) as well the Archives and single.php views (what mean some Climate Zone). Obviously, main division will be Administrative Division Destinations (they are also Destino types) and all above destination types will be classifieds within administrative division. Example, one Canton can get as many is Climate types (1 - 46), as well Parish or even Neighborhood, but any of FIVE frontend post types can get ONLY ONE. From other side, some destination types can be within THOSE FIVE - UNLIMITED (ie. idiomatic destination > languages, ethnics, gastronomy, ...).

So, there is no really uniform scenario.

PROBLEMS/QUESTIONS of topic

I tried several scenario's and I always have unexpected outputs. Per moments I left it as it is on added links (you have access).

Example with Administrative Division, I tried with conditional logic selectable fields and it come out without any logic. Destino is parent post of Sitio and if I selected Province > Canton > Parish, I expected that I have those selections available in Sitio, but that is not the case as I have all Provinces and Cantons. Same is with Slopes or Climate. If Parish have only 2 climate zones, Sitio shoudl have the choice only within that 2 and not within all 46.

Hopefully, I was clear. If not, Ii will try again to do better.

[Ljuba]

I realized that one think can confusing you. For me is clear that if I will 'nest' CPT for Administrative Divisions, I will obviously save a lot of work (queries, as well), as I will need to create post (value) only if I will need it (if I will use Parish ie). In such way I will avoid Selectable Field values (about 2000) and maybe will get just couple hundreds. Mix (mess) of too many Cantons and Provinces will not appear.

But my goal was to show you scenario (easy to understand).

So, goal of topic is - what is to use > posts, fields, taxonomies.

Issue is that multiselect (fields checkboxes and Taxonomies) are not available for BACKEND conditional logic (only frontend), otherwise, solution will be those multiselect (fields or taxonomies).

Basically, I'm confused how to control conditional logic if I will use multiselect instead of nested posts (as RG are now out of option).

Example, in one hotel if I have 3 rooms types and I set Room Services Types as taxonomy of Room child post, can I call same taxonomy 3 times (for each room type) for same parent post type (Hotel), but different Rooms (child post), dependently is it Free or Paid (than if it is paid > how much > keep chain)? All in Frontend (CRED) and display it correctly.

Internet > WiFi/Cable > Free/Paid > Price + Currency Type + per Hour/Day/Mb (all conditional logic)

Now, it looks that I should make Internet CPT as it is available for all business, places, sites (events) and mix it between Hotel and restaurant of same Business (page)/company.

It is easy with conditional logic in backend (and lot of queries), but it is obviously not great approach.

Question about Climate Types is basically same.

If this was helpful.

[Ljuba]

OK, to simplify topic, I will open another topic for Top > Bottom issues (questions) and here we will stick with 'parent' issues (as I started).

1) REDUCTION So, Country have 46 Climate Types > 'Manabi' Province have 12 (should to be reduced selection to 12) > Canoton 'San Vicente' have 4 (reduction of choice to 4) > 'Canoa' PArish have 2 (reduction of choice to 2) > Site ('inland' attraction) 'Rio Muchacho Waterfall' have 1 (inland) Climate Type and:

should to be displayed on post single/php frontend
should be subject of Archive Pages Filtration (and search) (so, Destinations and ALL CHILD POSTS (Sites, Places, ....)

2) RELATIONSHIPS Same, but another Destination Type 'Gastronomy' should to do all as Clymate Types, but also should be part of Gastronomy Child Page (Destinos > Negocios > Gastronomía). So, Restaurants should be capable to choose Destination specialties as ie 'Featured Dishes', not just to display it as it is with Climate Type. But, same Gastronomía child post (specific restaurant) should to be capable in Filtrations/searches and Archive Displays as (ie) Restaurants in 'Ceviche de pescado' Gastronomy destination.

PROBLEMS (another way to try to explain) - Parent/Child posts fields cannot be subject of backend conditional logic, as well as checkboxes and Taxonomy (within post). At this point, probably is the best to explain you contrary example (what I will now ask in other post - but here is just for understanding issues).

Payment Gateways (about 6 in Ecuador and .... worldwide). If owners have unified approach to expenses (no additional fees or equal for all), no problem, but if they have practice to make it different - problem (as child post is needed). But problem starts when owners start to change policy, as fields are not 'chained' (they remain in database, as Beda explained in other post)..... and that's how we found BUG's with Types 3 and probably will be similar with Types 2.

CONCLUSION As child posts are hard to set to be destroyed, it is better to avoid them as more is possible. Certainly, that's not the case with all situations (ie - Administrative Destinations should be done via child posts).

QUESTION How to handle it via taxonomies (as there is similar situation), as they could be via CRED subject of conditional logic (but changing taxonomy selection will left the 'garbage' in database what lead to breaks, soon or latter)? Same is with checkboxes.

CONSEQUENCES A part of potential breakage, it is essentially impossible to predict users behaviors during the time (read - changes of values), what obviously lead to incorrect Content Template Values display. Not clear? If I use Taxonomy (or checkboxes) for selection, I can set conditional logic for prices, ingredients, ...per dishes, but if user unchecked specialty, everything will remain visible, as it cannot be removed from database. Yeap, I can go further and try to make 'supernova' (read, huge) Views conditional logic's, but it never can be perfect and it will be HUGE JOB. However, issues of remain 'garbage' values and potential issues, remain.

In other words, never filed values are not displayed in frontend by default (that's great and simple), but leftovers will be displayed, so, additional codes are needed and nobody can predict all scenario's.

PRACTICAL EXAMPLE (a part from restaurants and prices, ingredients), let's go back to Climate Types. Owner choose one climate type (if we have child post for Climate Destinations), than he remove location to another Province. He will not be faced with selection of 2, he should to be faced with complete different options (if that is not on coast - ie). Child post will remain(or not?) and new child post will be created, but both will be available for search/filtration and visible, as well on business page (or extended coding is needed for View).

Hopefully, this will help.

[Nigel]

Hi Ljuba

I have read and re-read the above, let me give you my thoughts.

First, regarding the question of Types 2 or Types 3, I would encourage you to use Types 3 if possible. If you have specific problems with Types 3 that are bugs, these will be fixed. My advice might be different if there is something you used to be able to do with Types 2 that you can no longer do with Types 3 (I'm aware of only one such thing, from a different user's thread that isn't under consideration here). If you stick with Types 2 you will find that after the end of the year it is no longer supported, and bug fixes and feature enhancements will only happen in Types 3. If you create a site with post relationships in Types 2 and don't want to change to how relationships work in Types 3 you can upgrade to Types 3 and not run the migration wizard, which means the relationships will continue to work as before, and you'll be using Types 3 so benefit from ongoing updates.

Now, regarding your site.

The obvious things which are post types are Sites, Places, Businesses, and Events, so you would create custom post types for each of these.

The rest of the information is largely about how to categorise those posts.

Generally, and for large sites such as this in particular, you should use taxonomies wherever possible to group and categorise posts rather than custom fields, because taxonomy queries are optimised for search and post meta queries are not.

Sometimes what to choose is obvious.

You must use custom fields where the information is unique for a post, e.g. the telephone number of a business.

But what about if the business offers free WiFi? You could add a checkbox or radio custom field for that. If you only ever used that field when outputting the post (i.e. getting the post meta of a post) then that would be fine.

But if you wanted users to be able to search for businesses and only include places with free WiFi, for example, you should use a taxonomy instead. It doesn't really matter on small sites, but on yours it can potentially make a big difference.

I initially understood Destino to be a post type, but it's not, the Sites, Places, Businesses and Events are the destinations, and they are categorised according to:

- location (region > province > canton > parish > neighbourhood)
- climate zone
- ethnography
- language (idiomatic)
- gastronomy
- altitude (not sure what this is, doesn't matter)

Now, if I am understanding this correctly, the issue is that some of these categorisations are related to each other.

So a business that is in a particular location ( ... > neighbourhood) will naturally be in a particular climate zone (or a small sub-set of all the available climate zones).

You as the administrator will set up these connections.

Then "publishers" who add content to the site using front-end forms need to be presented with the minimal options appropriate, so if they start out by specifying where their business is, when they come to choose other options such as climate zone they will only see the relevant options and not the full range of options.

Finally, the site "visitors" should be able to search this content according to these various categorisations (as well as individual fields such as the business name, perhaps).

Which boils down to, what combination of taxonomies and/or custom fields and/or post relationships can be best used to categorise the Sites, Places, Businesses and Events post types according to the above conditions.

Have I summarised that right?

(Preferred answer is "yes" 🙂 , but if it is "no" please try to be as short and clear as possible with your reply.)

I need to know I have understood the problem correctly before trying to answer it.

[Ljuba]

First thanks a lot for clearings about Types 2/3 and (much more) for Taxonomies (search optimization - as you 'shot' the center/goal).

As life is not black and white, general answer is yes and no. But, you get 90% correct and more important (for me), you exposed some extremly usefull informations for me.

To start with NO (and YES):

1) Destinations are not Sites, Places, Businesses and Events (SPBE), as I certainly need Post Type Destination. Why, because Destination can me many things (including SPBE, but not limited only to them). Issue is that site (portal) should to cover country and be managed by Editors (per those Destinations). Editors will create and publish Sites and Places (as they are informatives - by nature), but also approve Events and Businesses (posted my members/clients).

2) Any of SPBE can belongs to more than one Destinations Type, as destinations are Territorial, Climate, .... Typical Destination is City (but here, could be Parish or Canton). So, I guess, that this could be Taxonomies.

3) Any of Members should NOT BE in situation to choose ANY OF PARENT ELEMENT (climate, altitude, ....), as this is the job of Editors in level of Destinations. Clients can only choose - Parish (but, Provinces and Cantons must be available, as well, to avoid ie scrolling to 1500 country Parishes). Any of Destination elements will not be displayed on the page of BE (possibly on SP - if count). In other words, extremely valuable information by you is that all those Destination elements I must set as TAXONOMIES as main purpose is FILTERING DISPLAY (Archives).

A) PROBLEM (Topic)

How I will set it as they can't be subject of conditional logic? I know. Categories are sort of substitution for conditional logic as they have levels, but .... How to disable Editors to choose in some levels more than one option and in some levels to allow tham to choose more than one??? (that's why I from begin avoided that option/scenario)

B) PROBLEM (Topic too)

I will have similar scenario also in 'upper' levels (Destination), but problem is much easier to explain in 'lower' levels - ie Business > Accommodation > Hotel > Amenities > Parking.

In that level (but could be one up or down, as well), I should to have some sort of Conditional Logic choices. Yes/No - Free/Paid - Indoor/Otdoor - OnSite/Public - Public/Private - ..., but not all the choices for all 'Amenities' (as depend of the nature) and not always ONLY TWO choice and not always EXCLUSIVE (ie Radio, could be checkboxes).

So, if Parking is set via Taxonomies, how to set Conditional Logic Group (Post Type or what)?

P.S. - In Destination I have same problem in principle, but less complicated, but as Destination is 'upper' level of Main CPT's (SPBE), issue is how to assign selections/values to SPBE? In other words, if I create CPT 'Conditional Features Group' - how to manage/apply it on Taxonomy choice (Parking) of 'upper' CPT (SPBE)? Yes, easy for you to understand as you did it - how to apply Opening Hours child CPT of SPBE to Accommodations > Hotel > Massage Service or Parking (should be Taxonomy, right?)?

[Ljuba]

And ... made kind of small mistake. SPBE should be assigned to Neighborhood (here - Comunidad or Barrios). So, Destination is not actually 'lowest level' as Destination Quito (City) is Canton and contain 32 Parishes and xxx Barrios.

Some Business is located in Barrios, but belongs to Destination "Quito" and Parish "XY", not to "Barrios" "ZY". All regards the Display and Searching on site/portal.

But, issue is that all should to be 'dropped down' in level of "Barrios" regards some categorizations as "Climate" because only Barrios" can get only one climate type (but could be assigned more than one Gastronomy Dishes). So, confusing even for me.

However, EXCLUSIVE purpose of Destination CPT is SEARCHING/CLASSIFICATION.

[Ljuba]

Nothing better than image of practical example. It is Booking.com example of Facilities (Amenities) - ideal for taxonomy, but ....

I opened some simple example for you to see, but pay attention on RED rectangle and Restaurant (ie taxonomy checked value). There are TWO NESTED AND CONDITIONAL GROUPS of values (count fields or taxonomies - whatever).

First is Opening Hours and second is (parent CPT) "Add Another Restaurant". It looks how by checking taxonomy value, it open CPT.

How to do it (as by Toolset, taxonomies don't support conditional logic)?

[Ljuba]

I set new test site at hidden link...o.com/ with same credentials.

It is now just about original question, as it actually looks as solution to set Destinos all with Taxonomies (Categories). To not extend see yourself.

So, (initial) question was:

How to set limited choices of values in child post type (ie Climate Type)?

Example is Sitio. You have created Sitio "Playa de Canoa" that belongs to Destination "Canoa" (as Parish - see Taxonomy). Parish Canoa have selected 2 (from 46) climate types, but beach obviously can get only one (coastal).

Administrator in backend will set available Destinations and Editors should to post via CRED Sitios.

However, here also now appear now question (as taxonomies are used) - how to display ie parent Administrative Division of the Site in Sitio single.php. Before it was mess with repeated nested field groups, but now is all taxonomy.

P.S. - I guess that for previous reply I should to open new ticket (Restaurant > taxonomy - conditional), right?

P.S. - 1 - Destinos altitudinales basically determinate what Flora and fauna are available (full description is in taxonomy).

[Nigel]

Hi Ljuba

Sorry for the delay in getting back to you sometimes, your threads are time consuming to work because the issues are quite complex (I understand the importance of designing the data structures correctly before you get too far), and so it depends how busy I am with other threads as to how quickly I can respond.

I had one other very complex issue which I think (hope) I have killed, so I can return to this next.

The booking.com screenshot is a helpful illustration, but I would just point out that it is (surely!) not built on WordPress, and so does not necessarily have the same issue regarding superior performance of taxonomy queries vs custom fields.

Don't open anymore tickets about this, it doesn't make sense for someone else to go through trying to understand the set up, I'll do my best.

[Ljuba]

Hi,

No problem for waiting as important for me is to get solved and not a lot supporters can get me well (you and Beda at first place and Christian and Shane per case).

I know about Booking, but I thought that screenshot will help. Fact is that I should to be closest is possible to way how it is done on Booking, OpenTable, Expedia, Yelp, as that is how clients are used to use memberships, as well how visitors are used to use places search. Fact is that this project is different as it is primary informative (easy for use search capabilities are main). Project should to live from publicity, not from commissions. also, if it will succeed, it will be moved from WordPress.

I already opened other ticket (https://toolset.com/forums/topic/taxonomy-and-conditional-logic/) and it will help if you can overtake from Luo (BTW - I asked you when I posted, but .....), especially as I don't think that we started well. He is focused on CRED and View and I tagged post ONLY under Types.