Empty widget output after updating to 2.0.6

Patch attached, please review.

the patch fixed the issue

Confirmed: the patch fixed the issue for me as well on Drupal 10.6.15 with SHS 2.0.6. Thanks!

The patch fixed the issue. I tried it with both Drupal 10.6.14 and 10.6.15 and noticed no additional problems. Thanks!

I am getting the exact same error on 3.0.0-beta6. Reverting to 3.0,0-beta5 solved the problem. The patch #4 also applied against 3.0.0-beta6 on Drupal 10.6.15 to solve the issue.

The patch didn't work for me. The only solution is to roll back to version 2.0.5.

I confirm the issue. The patch didn't help, so I had to roll back to version 2.0.5. Please help!

Re-tested this directly against the 2.0.6 tag to confirm the fix.

1. git checkout 2.0.6 in modules/contrib/shs, then drush cr -- confirms the bug: the Category field renders with no select/hierarchy widgets at all (empty output), matching the original report.
2. Downloaded the patch: wget https://www.drupal.org/files/issues/2026-08-02/3613802-empty-widget-output.patch
3. Applied it cleanly with patch -p1 < 3613802-empty-widget-output.patch
   -- patches src/Cache/ShsTermCacheDependency.php and src/Plugin/Field/FieldWidget/OptionsShsWidget.php with no rejects.
4. drush cr, reloaded node/add/article — the Category widget now renders correctly with the full hierarchical select cascade.

Screen recording attached showing the before/after. Since this reproduces and resolves cleanly on the 2.0.6 tag. Happy to rebase the MR if needed.

Thank you for your detailed testing and the video! I really appreciate your work on this issue.

I confirm that I also tested the patch (#4) on my production site, but unfortunately it did not resolve the issue for me. The widget still rendered empty HTML after applying the patch, clearing caches, and even rebuilding the site's container.

Here are my environment details:

• Drupal: 10.6.15
• PHP: 8.4
• SHS: 2.0.6
• Site: Production environment with many custom modules and fields

What I tried:

1. Applied the patch cleanly (no rejects)
2. Cleared all caches (drush cr, also manually cleared OPcache)
3. Rebuilt the container (drush rebuild)
4. Tried on different browsers and with different users
5. Checked the widget settings in form-display
6. The only thing that worked for me was rolling back to version 2.0.5.

I'm wondering if there might be a conflict with another module, or perhaps with the way the field is configured in my setup. Here are the fields I'm using SHS with:

• og_group_ref (entity reference to Content, bundle: Community)
• field_field_community_term (entity reference to Taxonomy term, vocabulary: Community categories)

Could there be a specific configuration or dependency that affects the patch's effectiveness?

Do you think this could be related to Organic Groups? My fields are both OG-related, and the issue only appeared after updating SHS.

Thanks for the detailed environment information, @kovalevm — that's very helpful in narrowing this down.

Since the patch has been confirmed to work for some of us, this may indicate a separate underlying issue rather than a problem with the patch itself.

Could you check whether a plain taxonomy reference field (not OG-related) using the SHS widget renders correctly on the same site? That would help us determine whether the issue is specific to OG or related to a any other configuration issue on your installation.

I updated the module to the latest version 2.0.7 and tested it on other content types. The issue persists not only with the "Community Entry" (Organic Group) content type, but also with all other content types if I select the "SHS" category selection type. Please help!

I confirm, the problem persists and can only be solved by rolling back to 2.0.5.

I can confirm this issue (or similar, maybe because of the same bug) on SHS version 2.0.7.

In my setup, when editing an existing node that already has values saved, the select options themselves render correctly, but the previously saved selections are immediately wiped/reset to empty.

Downgrading back to 2.0.5 resolves the issue completely—the saved values are properly pre-selected on node edit, and the conditional logic works as expected.

Two different bugs in this issue, which is why #4 works for some and not
for others:

1. The D10 fatal in ShsTermCacheDependency - that's what MR !55 fixes.
2. Stored values not preselected (#17) - regression from #3517342 in
2.0.4, not touched by MR !55. Filed as https://www.drupal.org/project/shs/issues/3620147.

Hi,

I think I made a patch for this, together with AI, see attachment.
The problem is ShsTermCacheDependency::getCacheTags() fatal errors on Drupal 10 (undefined method getBundleListCacheTags()).

ince #3613025 (released in 3.0.0-beta6), ShsTermCacheDependency::getCacheTags() calls EntityTypeInterface::getBundleListCacheTags($bundle). This method was only added to Drupal core in the 11.x branch (drupal.org/project/drupal/issues/3501508, committed March 2025) and does not exist on Drupal 10.x, even though shs's core_version_requirement currently declares compatibility with ^10.5 || ^11.1.

Steps to reproduce:

Run Drupal 10.6.x core with shs 3.0.0-beta6 or beta7.
Configure an entity reference field with the shs widget on a taxonomy vocabulary with more than one level.
Open the node edit form. The widget containers render, but every /shs-term-data/... request returns HTTP 500.

attached patch guards the call with method_exists() and falls back to manually building the _list: cache tag (the same format getBundleListCacheTags() produces) when the core method isn't available, so behavior is unchanged on Drupal 11 and restored on Drupal 10.

greetings,

I'd like to wait for the official release to fix the problem.

If it helps anyone, I was able to get 2.0.7 working again and showing the values in the selects. A function was removed that is needed. I know it re-introduces the issue when deleting a taxonomy term that is still referenced by a node may cause an error when that node is saved again, we can live with that for now as an edge case.

I am sharing the patch we applied that fixes the issue until the issue is resolved upstream.

diff --git a/src/Plugin/Field/FieldWidget/OptionsShsWidget.php b/src/Plugin/Field/FieldWidget/OptionsShsWidget.php
--- a/src/Plugin/Field/FieldWidget/OptionsShsWidget.php
+++ b/src/Plugin/Field/FieldWidget/OptionsShsWidget.php
@@ -284,6 +284,17 @@
   /**
    * {@inheritDoc}
    */
+  protected function getSelectedOptions(FieldItemListInterface $items) {
+    $selected_options = [];
+    foreach ($items as $item) {
+      $selected_options[] = $item->target_id;
+    }
+    return $selected_options;
+  }
+
+  /**
+   * {@inheritDoc}
+   */
   public function massageFormValues(array $values, array $form, FormStateInterface $form_state) {
     if (!isset($values[0]['target_id']) || ($values[0]['target_id'] === '')) {
       return NULL;

Hello, when will the official bug-fix update be released?

This is the issue raised in comment 17.

Patch 59 didn't help me; there is no option to select the value. Only version 2.0.5 works. Please fix this in the official release!