I'm building a WooCommerce site - versteckter Link - for a jazz music label to sell both tracks and albums. There are three product categories - Downloadable Tracks, Downloadable Albums, and CDs. These three kinds of products have different custom field groups and need to have distinct Content Templates - is there a way to accomplish this?
Hello, it sounds like you want to apply a different Content Template to the single Product page depending on the Product Category taxonomy terms applied to that Product. Is that correct? If so, there's not a simple way to set this up in wp-admin but you can use some custom code with our Views Filters to programmatically change the Content Template for a single Product page based on terms from the Product Category taxonomy. We have documentation for the wpv_filter_force_template API here: https://toolset.com/documentation/programmer-reference/views-filters/#wpv_filter_force_template
There's another ticket in the forum that discusses this approach, and provides some sample code:
https://toolset.com/forums/topic/content-template-for-single-page-of-different-taxonomy-3/#post-1357307
Note that the slug for the WC Product Category taxonomy is "product_cat". You can add the custom code in a child theme's functions.php file, or in a new code snippet in Toolset > Settings > Custom code. Let me know if you have questions about that and I will be glad to provide some guidance.
Thank you, Christian. I added the suggested code, editing it for my current situation, and at first I thought this met the need, as test products in different product categories are displaying with their appropriate templates. However, when I try to edit these templates to add elements from Custom Fields Groups that are connected to the Products custom post type, it seems a convoluted process where I have to change the 'usage' of the template I want to edit and select 'Single Page > Products', making sure that 'Apply to existing Product items' is _not_ checked, and then if I want to edit another template, make sure to do the same with that (which automatically unselects the first). Am I missing something again?
I'm not sure I understand, but even if a template is applied to the product in wp-admin the API will override that template programmatically. So don't worry if a different template is assigned to the product retroactively.
Thank you for assuring me that inadvertent clicking of 'Apply to all' buttons won't do any harm. Still, the routine as captured in the attached screenshots is tedious, but I guess unavoidable. I'd like to make the case that a lot of folk using Toolset and WooCommerce with multiple product categories would love to be able to use different templates, and it would be great if Toolset could provide a somewhat friendlier way to accomplish this in the future.
• screenshot 1 — no post type selected for template
• screenshot 2 — so no Custom Field Groups and Custom Fields are available to be selected
• screenshot 3 — Single Page post type 'Products' selected
• screenshot 4 — Yay! Custom Field Groups and Custom Fields available now!
Selecting the post type, updating the template, then refreshing the page has to be done every time a different template has to be edited.
I see the issue more clearly now, thanks for the screenshots. I agree this is a bit clunky as an editing experience. Just to be clear it's not required to select a field group. The custom field input is still usable even without selecting a field group, and you can use auto-suggest to find the field you want to use. However, it does seem that being able to select a field group would make it easier to use. I can escalate your concern to my 2nd tier team to see if they think its a usability issue or a new feature. I will let you know what I find out. In the meantime, you can try using the Custom Field select field without selecting a Field Group.
After a bit more discussion with the team, it seems that there is one other current workaround, and another option that would require some development as a new feature.
1. In the Post Source field, choose "another post", then select some Product post. This would set the "context" for the single field block, and allow you to more effectively choose field groups and fields in the existing block editor interface.
2. Another way to set the context would be to utilize the "Preview with this post" selection at the top of the page more effectively. This would allow you to temporarily set the context for a Content Template during editing without the need to actually apply the CT to some post or post type. This context setting would enable the field groups that correspond to the selected post type, and make selecting a specific field in the single field block more intuitive. If you agree, our developers have asked that you add your vote for incorporating this feature by submitting the feature request form here: https://toolset.com/home/contact-us/suggest-a-new-feature-for-toolset/
Our 2nd tier support team has filed the feature request internally, but adding User votes from the link above will increase the priority of this request and let our management team know you'd like to see this one added. As more people request the same feature, priority for its implementation will continue to increase.
Hi Chris - sorry that I haven't responded for a couple of days; I've not been well, and after handling regular business tasks haven't had the energy for development work.
I am unable to accomplish what you described back on the 13th at all - without field group context selected the slugs of other custom fields are not recognized.
Your first suggestion yesterday - choose 'another post', etc. - does indeed work, so I can and will use that going forward.
I did try your second suggestion yesterday as well but regrettably that doesn't work, at least not for me.
I'm happy to provide you with access if you'd like to look around for yourself.
I did try your second suggestion yesterday as well but regrettably that doesn't work, at least not for me.
Right, this isn't currently in the software. If you'd like to see it added, file the feature request as I suggested.
The first suggestion from yesterday is the best current workaround.
My issue is resolved now. Thank you!
