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?

  • Or maybe by weight. I mean the terms could be reordered in the reference field, no? But honestly this probably is more of a problem that only leads to opinion-based answers. – leymannx Jun 11 '20 at 19:16
  • Thanks for the suggestion of using weight. It's clever but doesn't quite meet the spec I have. I may investigate it since it would reduce the number of fields needed by one. I edited to make it more clear that I invite sharing experiences rather than opinions. – lolcode Jun 11 '20 at 19:40
  • Is the only difference between primary terms and secondary terms that primary are boosted in search results while secondary aren't? – sonfd Jun 12 '20 at 0:35
  • @sonfd Yes. So far that is it. – lolcode Jun 12 '20 at 12:04
  • Are you using the standard Drupal search in core, or something like Search API / Solr? – Patrick Kenny Jun 12 '20 at 12:45

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.)

  • This is a pretty decent UX considering the effort. Thank you for reminding me too that in Drupal a "sub-entity" can be just a "field" because of course field types have structure. – lolcode Jun 12 '20 at 14:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.