Mutually exclusive subcategories

That should be by default: selecting one subcategory does not automatically select any sibling subcategories.

If this is not the case at your end, then some plugin is likely causing this.

@gappiah Uhm, maybe I didn’t explain myself well, sorry. I want to prevent the user from selecting multiple subcategories of a particular category.

• This reply was modified 2 months, 3 weeks ago by islp.

Ideally the subcategories would be radio buttons instead of check boxes. Redoing the category meta box to do that can get rather messy. It might be feasible to alter the meta box HTML with JavaScript after the editor page loads, but WP will not be able to process the change in data structure. You’d need to also alter how category assignments are processed.

It’s also feasible to have JavaScript automatically uncheck other sub-categories when any one is selected. Setting up JS to do so for any arbitrary set of sub-categories now or in the future would be pretty involved, but having it only address certain fields as they exist now is feasible. However, being able to search for categories makes this approach much more difficult.

The simplest solution AFAIK is not very user friendly, but effective. You can modify the category assignment routine so that it un-assigns all others when assigning the current one. This will prevent users from assigning multiple sub-categories, but it will not prevent them from trying. They can assign multiple sub-categories, but when the editor reloads they’ll see that only one assignment worked. To end users, the editor will appear to malfunction, but it’s achieving your end goal.

Use the “add_term_relationship” action hook to do so. If the passed term object is any of the sub-categories, remove any others that are already assigned or queued to be assigned.

@bcworkz thanks!

In the meantime, I found a way to avoid using subcategories and code less (consider I’m coding for the classic editor in a ten years old unsupported commercial theme, modified many times. And I really don’t want to skill up in React, anyway). ??

Basically, at a certain point in the life of a news widget, I had to modify its behavior, eg. some news title needed to be highlighted, some other needed to display a particular icon, etc. Since this behavior is always temporary (because the old news go out of page and because a meteo alert is not important a week after a tornado), I simply invented a couple of post categories: when the category is set, the title of the new is formatted in a particular way. When it is not useful anymore, the category is unchecked. I know this is a somewhat “creative” usage of the categories, but it worked fine and the users are happy.

Problem is they liked this so much that they started proposing other title colors, fonts, and so on, for other news cases. So, my initial idea was to have a main category with subcategories where the users could eventually select their styles.

But then I found I could eventually use custom fields: when the special category is active, I simply set a meta related to a css. The frontend checks for the presence of the category, then it looks for the related css.

If you have a wide variety of different styles associated with individual posts, relating post meta to specific CSS is probably a better approach anyway. The default custom field meta box leaves a lot to be desired in many cases. If one was so inclined, one could create a custom meta box that includes radio button selections so users can only pick one of many for any given post. One can either code their own or utilize one of the custom fields plugins which may already provide a radio button dialog.

If for any reason a taxonomy like categories still makes more sense, you could create a custom taxonomy for the purpose and specify a custom meta box be used instead of the default. Thus you could get a radio button dialog for taxonomy terms just as we might do for post custom fields. The custom taxonomy would allow for this. The trouble with a radio button dialog that I alluded to earlier only applies to default taxonomies.

@bcworkz

The metabox idea seems to me the best idea, but I discarded it for a number of reasons: for example, I don’t know how much longer the site can afford to use this old theme. This means that 1. the new theme maybe won’t support this behavior, 2. I would have to get my hands on something that is no longer needed in a few months, 3. in a short time I would certainly be plagued by the idea of making a version that supported Gutenberg. ?? All these thoughts advised my traditional laziness to simply use custom fields: they were ready to use and I had to develop very little; so, for example, since custom fields don’t seem to allow selection from a <select>, I had to put in some server-side checks to verify that the CSS class names entered by the user were the right ones (or absent, etc.).

I hadn’t really thought about the custom taxonomy instead.

Thanks!

• This reply was modified 2 months, 3 weeks ago by islp.

Ya, know, you could implement any of this as a plugin so it carries through regardless of what theme is used. And custom meta boxes still work in the block editor. I don’t blame you for not wanting to go down the custom meta box path, but you’re not getting away with the “but Gutenberg” excuse ??

@bcworkz Of course I could, but they could completely change theme and I don’t know if the hypothetical new theme would still need this feature! This makes me lazier and lazier ??

• This reply was modified 2 months, 2 weeks ago by islp.