Hi Jé,
For older posts/products created before activating TSF, when no primary term has been set for them, it should default to the primary term selected by WordPress/WooCommerce. By default, this is the term that has the lowest term ID. When you edit such a post/product, TSF will automatically assign and select that term as primary.
When you create a post or product, TSF automatically selects a primary term based on the first term you’ve assigned to the post. When you unassign a term that’s primary, TSF will look for an assigned term with the lowest term ID.
I don’t believe adjusting its lookup logic would improve things for most of our users. Let me explain.
The feature would sometimes select the first term you’ve activated, and sometimes it’ll look for a hierarchically deeper term. Even if this was optional, where users would have to consciously activate it (I’d bet less than 1% would do), this can ultimately become confusing and frustrating.
To learn why, please refer to this WCAG documentation on accessibility.
Unexpected changes of context can be so disorienting for users with visual disabilities or cognitive limitations that they are unable to use the content. […] Some individuals with low vision, with reading and intellectual disabilities, and others who have difficulty interpreting visual cues may benefit from additional cues in order to detect changes of context.
Do we want to add visual and spoken cues after a term is selected that invokes a change of primary term? How should we even execute that? What happens when the first term selected is the most favorable one, whereafter it erratically changes to another one later? I often ponder for dozens of hours on any single feature, and sometimes they make it in the plugin, and at other times, no one would’ve known I even considered it. Sometimes, it takes years for me to implement a feature because I couldn’t find the correct way to implement it earlier. Perhaps, this will be one of them.
We need to maintain a shallow entry for ease-of-use; the simpler we make it, the more you can use the plugin on “auto-pilot”, whether you have disabilities or not: Repeated patterns, clean interface, instant feedback, no new things to learn, etc. all contribute to this. It is also why I keep TSF so much in line with WordPress’s interface, even when I don’t agree with everything it brings. The stance I take is very much in line with the first five proclamations of WordPress’s philosophy.
With all that, I believe it’s best to stick with the “first selected/lowest ID” logic, and allow the user to select the primary term manually via the selector TSF provides thereafter.
If deactivating TSF yields different results for your primary term selection, then another plugin or theme may be adjusting the breadcrumbs, whereafter TSF overrides that behavior. So, if you wish to deactivate the primary term feature from TSF, you’ll have to implement this snippet — feel free to exclude some of the remove_filter-calls to make it more suitable for your scenario:
add_action( 'the_seo_framework_after_init', function() {
$tsf = the_seo_framework();
// Remove post permalink primary term support.
remove_filter( 'post_link_category', [ $tsf, '_adjust_post_link_category' ], 10 );
// Remove product permalink primary term support.
remove_filter( 'wc_product_post_type_link_product_cat', [ $tsf, '_adjust_post_link_category' ], 10 );
// Remove product breadcrumb primary term support.
remove_filter( 'woocommerce_breadcrumb_main_term', [ $tsf, '_adjust_post_link_category' ], 10 );
// Remove product category widget primary term support.
remove_filter( 'woocommerce_product_categories_widget_main_term', [ $tsf, '_adjust_post_link_category' ], 10 );
} );
Feature requests tend to get lost into the void of these forums real quickly. So, if you have any more feature requests, please forward them directly to GitHub: https://tsf.fyi/support/feature. Thanks!
