🇧🇪Belgium @vodde83

There's more, if you look closely the default selector is > .view-content ( notice the 'greater than' arrow ).
So your row wrapper also has to be a direct descendant of the whole View wrapper! Easy to miss but in our case the issue, as we had additional HTML in-between.

interx → credited vodde83 → .

interx → credited vodde83 → .

We definitely don't want people to get stuck using pretty much a somewhat default configuration, so you've raised some valid points.

I'm not exactly sure yet what the best default API-version should be, so I'll have to look into that. I think if all the issues you raised are addressed, changing the default might not be needed anymore.

I'll likely disable the 'Search captions' altogether if the API-version doesn't support it though, in addition to an updated description. This makes the whole thing somewhat more bulletproof.

vodde83 → created an issue.

This hook was exactly what I needed in my case, as on Nodes in a Group, a GroupRelationship entity was picked up by metatag_get_route_entity().
And not the actual Node itself. This resulted in the incorrect Metatags being generated.

This seems to be due to this change : https://www.drupal.org/node/3375748 →

This seems to be due to $bundle_entity_type = $this->entityTypeManager->getDefinition($entity_type)->get('bundle_entity_type') in TaxonomySetLineageForm returning NULL.

This subsequently causes the next line : $entity_bundle = $this->entityTypeManager->getStorage($bundle_entity_type)->load($bundle_id); to fail.

For now, I fixed it locally by adding an IF-statement around it.
Basically, replace this block of code:

        $bundle_entity_type = $this->entityTypeManager->getDefinition($entity_type)->get('bundle_entity_type');
        $entity_bundle = $this->entityTypeManager->getStorage($bundle_entity_type)->load($bundle_id);
        $options_bundles[$bundle_id] = $entity_label . ' - ' . $entity_bundle->label();

        $options_fields[$instance->id()] = $instance->label() . ' <small>(' . $instance->id() . ')</small>';

with:

        if ($bundle_entity_type = $this->entityTypeManager->getDefinition($entity_type)->get('bundle_entity_type')) {
          $entity_bundle = $this->entityTypeManager->getStorage($bundle_entity_type)->load($bundle_id);
          $options_bundles[$bundle_id] = $entity_label . ' - ' . $entity_bundle->label();

          $options_fields[$instance->id()] = $instance->label() . ' <small>(' . $instance->id() . ')</small>';
        }

I do seem to have some other - likely unrelated - issues with the module, but at least that will grant you access to the configuration form.

True that @ras-ben, an additional check $node->hasField('moderation_state') would be even better.

I can confirm that the solution by @ras-ben does indeed fix the issue. I also agree that this shouldn't be required, as the 'Draft' option before the fix was completely unusable.

However, I did update the fix slightly to this:

/**
 * Implements hook_form_BASE_FORM_ID_alter() for Node Forms.
 *
 * Fix an issue with previewing moderated Nodes, due to the moderation state not
 * being properly relayed.
 *
 * @see https://www.drupal.org/project/workflow_buttons/issues/3155336
 */
function MY_MODULE_form_node_form_alter(&$form, FormStateInterface $form_state, $form_id): void {
  // No need to do anything if the 'Preview' action is not available.
  if (!array_key_exists('preview', $form['actions'])) {
    return;
  }

  /** @var \Drupal\node\NodeForm $node_form */
  $node_form = $form_state->getFormObject();
  $node = $node_form->getEntity();

  // If the Node is a moderated one, relay the current moderation state to the
  // 'Preview' action.
  if ($moderation_state = $node->get('moderation_state')->getString()) {
    $form['actions']['preview']['#moderation_state'] = $moderation_state;
  }
}

vodde83 → created an issue.

vodde83 → created an issue.

I still cannot update from Core 9.2 to - in my case - 9.5, but it likely won't go past 9.2 anyway due to Core's ^3 requirement of egulias/email-validator.

Drupal Swiftmailer 2.4 has this in composer.json:
"swiftmailer/swiftmailer": "^6.1.3"

Swiftmailer itself, has this in composer.json (see https://github.com/swiftmailer/swiftmailer/blob/v6.1.3/composer.json):
"egulias/email-validator": "~2.0"

So while Drupal Swiftmailer now doesn't care whether you use ^2 or ^3 , Swiftmailer itself will still not go beyond ^2.

What I believe should fix it, is this is composer.json of Drupal Swiftmailer:
"swiftmailer/swiftmailer": "^6.3"

And actually, the entire egulias/email-validator can be removed from composer.json.

This does however create an issue for people with Core 9.2 or lower. I'm guessing to resolve this in it's entirety, and new major version would be required, only supporting Core 9.3 and upwards?

vodde83 → made their first commit to this issue’s fork.

#16 works great!

However, I did notice the value suffix - and presumably, prefix - doesn't show up in the summary.
My Facet has a suffix of 'm2', and the summary just shows '22 - 60'.

While I don't care much about for example the seperator in between the min & max, I'd say adding the prefix and/or suffix to the summary makes sense.

I think I get what @Kris77 is referring to, I'm seeing this issue as well. That is, unless I misconfigured and/or overlooked something :)

There are basically 3 relevant roles in the website : A, B and X.
The roles A and B are for front-end users, and have their own profile type with specific fields.
The role X is pure back-end, and does not have a profile type.
Through use of https://www.drupal.org/project/multiple_registration → , the roles A and B each have their own registration page. Role X does not, as they're not supposed to go through the front-end to get an account.

But if I - as a superadmin - want to create an additional back-end user with role X, I can't do so without filling in both the profile fields for A and B. All profile forms show up on '/admin/people/create', and some of them contain required fields.
So I can't just leave them blank.

I think that either the respective profile form(s) should only appear when selecting a role that has a profile type connected to it, or the profile forms should not appear on '/admin/people/create' at all.
However, I can see situations where some back-end roles do have a profile type with additional fields that are required.

vodde83 → made their first commit to this issue’s fork.