How can I allow editors to manage many taxonomies while choosing which terms to boost and which to make visible?

Question

The system I am working on has about 15 taxonomies. It may have 30 or more eventually. We didn't want to add a field for every taxonomy since the editors would have hated that. Initially we went with one field called "Search term(s)" aka field_search_terms that lets editors reference multiple taxonomies.

Now the editors also want to be able to

1. Mark some terms as primary and others as secondary (Let them control which terms to boost in search)

2. Mark some terms as visible tags on the page while most will be hidden.

I can think of two options:

• Make separate fields on the nodes for primary, secondary and visible_terms. Unfortunately the editors will have to select visible terms/tags twice.

• Make a custom "search_term_reference" entity with fields: {field_search_term, is_primary, is_visible} and then provide something like inline entity form to edit them.

Can anyone offer any practical guidance based on experience with the issue of allowing editorial control of search boost for individual terms? Feedback on how much custom code was needed for example?

Answer 1

My preference is to use 3 fields. I'm not sure I think it's ideal, but I think it's actually an easier UX and a better data structure than 1 field (or subentity) with taxonomy ref plus additional checkboxes for primary and display with each tag.

On the surface, it may seem like 1 field would be better, but I think that's actually an illusion. The two main users I'd consider here are developer and editor, and I think one complicated field is bad for both of them. For developers, it's going to be more difficult to determine the search terms or display terms when you try to get them in code with one complicated field vs 3 separate fields. It's also going to be more difficult for editors, they won't be able to scan and see all search terms or all display terms easily.

Field 1: Tags This is the master field, it has all the tags that would be in either of the other two fields. If you're generally checking if the content has a tag, you'd check here.

Field 2: Display Tags This field is a subset of Field 1 tags and its only purpose is determining which tags display.

Field 3: Search Boost Tags This field is also a subset of Field 1 tags and its only purpose is boosting search results.

Custom Field Widget Create a new field widget to be used with the display tags and search boost tags fields. This widget displays tags with checkboxes and is limited to only the tags in the first, master tags field. Also have the widget update its options via ajax whenever the first tag field changes.

This approach creates an easy interface for editors, keeps all the data easily accessible for developers, and limits special custom coding to just the field widget. (Bonus: you now have a cool field widget in your collection that you can use elsewhere in similar situations.)