🇳🇱Netherlands @jaapjan

Also using this patch on my project because the queue is full of simple_sitemap_elements. Any plans on implementing a solution in the module?

Argument for password also done.

The argument for user roles is added to the command in the merge request.

Argument for password selection still to be done.

It makes sense to remove that logic from the construct method.

Also can confirm that voting still works as expected after applying the changes on a Drupal 10.2 installation. RTBC (test failure is not related to this change)

jaapjan → created an issue.

I can confirm this works. Since it's already merged to the dev branch I think this can be marked as Fixed right?

Also it would be great if a new release can be made of this module with this change.

Confirmed it works as expected. Note that the file_cron removes unused files marked as temporary in the private directory by default.

jaapjan → created an issue.

Patch works for me as well. Any chance of merging and tagging a new release?

It seems I introduced a type error in the last patch when the account is not set. Updated patch. (Only addition
$account = $account ?: \Drupal::currentUser(); in CommentFieldItemList.php).

Attached a patch for 10.1. Patch is based on 01ed69c2. Slightly adjusted for D10.

Thank you. Works for me in D10. Approach is also good. Marking as RTBC.

Thank you Eirik!

Works for me and test is passing again, would be great if this could be packaged into a new release.

This is also solved in https://www.drupal.org/project/vppr/issues/3336179#comment-15049923 📌 Drupal 10 compatibility RTBC which might be a more straight-forward approach.

Let's mark this as RTBC and perhaps create a separate issue for #9?

Patch from #8 is the most straight-forward approach to support D10.

Would be great if a maintainer could take a look at this and create a D10 compatible release accordingly.

This is related to the fact that categories are now a multiple value field. I assume that makes it not logical to sort by categories anymore.

See also the related issue. The specifier and field key have been removed from the categories definition in the buildHeader method which is causing the field to not be sortable anymore.

I can also confirm it is working on Drupal 10. It would be great if one of the maintainers could merge and create a new D10 compatible release.

It would be greatly appreciated if the maintainer could tag a new release.

On this commit for 5.x
https://git.drupalcode.org/project/twig_extender/-/commit/8666e0e3c21bb3...

And perhaps for this commit for 4.x
https://git.drupalcode.org/project/twig_extender/-/commit/43ad310caa7198...

Agree with comment #136. Fastest way forward seems to be to mark story as fixed and tag new release on current dev branch. Considering Drupal 9 is EOL in a few weeks it would be extremely helpful if a maintainer could tag a new release.

For now one could use version constraint dev-2.x#2fa71b6196c64b93e8377f02e2e6d827bbe67ec8.

It seems that this solution was not fully complete yet. In the latest dev version of the module the Upgrade status is still giving 6 problems related to the deprecated jquery.once library. Please see this issue before releasing a new D10 version: https://www.drupal.org/project/private_message/issues/3391546 📌 Replace deprecated core/jquery.once for Drupal 10 support Needs review

Changes are in the merge request. Would be great if this can be reviewed.

Patch file here: https://git.drupalcode.org/project/private_message/-/merge_requests/72.p...

jaapjan → created an issue.

No need to add code for this. I think you can remove the field "Clear history link" from the private message display settings, e.g. on this page:

/admin/structure/private-message/private-message-thread/display

Note that the MR already solves this. The patch in #11 works but I think it is better to rely on the methods provided in the Duration Field module.

See:

$duration = $this->durationService->getDurationStringFromDateInterval($duration);

jaapjan → created an issue.

jaapjan → created an issue.

Which version of the patch did you use before? In our site we used https://www.drupal.org/files/issues/2019-01-17/extra_field-using_in_form... → . Here you can see (in ExtraFieldFormManager::entityView) that the plugin element was always returned inside a new form field of type container with a widget. Like so:

$element = $plugin->formView($form, $form_state);
if (!empty($element)) {
  $form[$field_name] = [
     '#weight' => $extra_field['weight'],
     '#type' => 'container',
     'widget' => $element,
   ];
}

But in the new 2.x version the element is printed directly. See FormManager.php::entityFormAlter, line 133:

$form[$fieldName] = $plugin->formElement($form, $formState);

Going back to your example extra field plugin (ExampleMarkup):

Current code is:

  /**
   * {@inheritdoc}
   */
  public function formElement(array &$form, FormStateInterface $form_state) {

    $element['markup'] = ['#markup' => '<p>Hello world 1</p>'];

    $element['container'] = [
      '#type' => 'container',
      '#markup' => '<p>Hello world 2</p>',
    ];

    $element['item'] = [
      '#type' => 'item',
      '#title' => 'Greeting',
      '#markup' => '<p>Hello world 3</p>',
      '#description' => "A common line of example output.",
    ];

    return $element;
  }

It will fix the problem if you change this to:

  /**
   * {@inheritdoc}
   */
  public function formElement(array &$form, FormStateInterface $form_state) {

    $element['markup'] = ['#markup' => '<p>Hello world 1</p>'];

    $element['container'] = [
      '#type' => 'container',
      '#markup' => '<p>Hello world 2</p>',
    ];

    $element['item'] = [
      '#type' => 'item',
      '#title' => 'Greeting',
      '#markup' => '<p>Hello world 3</p>',
      '#description' => "A common line of example output.",
    ];

    return [
      '#type' => 'container',
      'widget' => $element,
    ];
  }

I think this means that we have two options:

1. Developer is responsible for adding a type to your extra_field element. We should probably add this in the examples if we go down this route.
2. Restore the way the element is added to the form, like in patch 24 or add a fallback when there is no #type provided we add type 'container' to the render array. This may have some impact on existing installations using the 2.x branch of this module.

Curious to hear what the maintainers think of this.

Works here as well, seems like a relatively small change. Is it possible to create a Drupal 10 compatible release?