🇳🇿New Zealand @davidwhthomas

The patch in #29 fixed the issue I was having with line endings being stripped in mail headers, preventing html email being sent, in Drupal 7.102
The email headers would show all on one line and the email body shows the plain text html tags.
After the patch, the headers are formatted correctly and the email comes through HTML formatted, with thanks.

You're welcome. I've added another commit to the MR to tidy up those PHPCS suggestions, with thanks for the useful module.

Good idea, if possible could the OR conjunction be supported via the search string, at the level of a particular search?

That way the client could specify the operator, such as "match all keywords" or "match any keyword" etc..

As a related note, it seems at the moment including a logical operator, such as "OR" in the search query fulltext parameter will return a bad request error.

I added a patch via merge request that only adds support for the exposed items_per_page pager without other code updates.

Thanks for adding this patch, it's needed.

However, after applying on the latest `drupal/views_ef_fieldset:^1.10` release, exposed filters that include exposed operators, such as date fields, do not show inside the configured fieldsets.

Thanks ayalon!

Thanks for working on this.

After adding this patch, the form to select the target term to merge into also shows pagination and the select box doesn't show all values.

Attached MR with patches:

1. Against the 8.x-2.x-dev branch and also
2. Against the 8.x-1.x-dev branch (backport).

MR pipeline error regarding composer dependencies is unrelated to this update.

davidwhthomas → created an issue.

Thanks for your reply.

I was looking into the insert implementation to try and extend the allowed html filter attributes in a separate task.

It sounds like the insert module html and attributes are rendering as expected for now and ok.

I will keep in mind the source view behaviour for now, thanks again.

davidwhthomas → created an issue.

Adding a screenshot of filter settings

Thanks for the efforts in this area. It's quite tricky to add allowed HTML tags and attributes to CKEditor5!

However, despite adding the Insert module's CKEditor plugin button and the image plugin button to the ckeditor toolbar, the additional insert module allowed HTML tags and attributes are not preserved in CKEditor.

For example, if I click "Source" and add any of the custom attributes to the HTML, the attribute is removed when I click back to the HTML or click to view Source again.

e.g <a data-insert-attach="test">test link</a> or <span class="example">test span</span>

Am I missing something? It should be possible to add those allowed attributes?

Using:

• Insert version: 3.0.0-beta7
• Drupal core: 10.3.0

I specified the text_format during migration of the body field with this migration template yaml:

body:
  -
    plugin: sub_process
    source: body
    process:
      value: value
      format:
        plugin: default_value
        default_value: newsletter_html

Thanks for adding this. You are absolutely right. The current ban expression does not support multiple cache tags and also has other spurious matches. I've tested your updated ban expression and it works well.

I just encountered the same issue with vertical tabs showing another fieldset inside the tab pane.
For my case I was configuring the user view display mode to use vertical tabs (not an input form)
Running the latest field_group module 8.x-3.6 and (not sure if Claro or Gin issue), but Gin 8.x-3.0-rc13

The fix for my case was a bit simpler, without needing a preprocess function, I manually added the vertical-tabs__item class in the field group config settings, then the display appears as expected (see screenshot)

The current MR version fixed the issue I was having where date filters with exposed operators were not grouped inside the fieldsets, with thanks.

Thanks for the update!

I can confirm eca_cm is working with eca.

To update I ran

composer require 'drupal/eca_cm:^1.0'
composer require 'drupal/eca:^2.0'
drush cr

and then resaved my ECA models

Tested ECA invoke and working, thanks again for the quick update.

I'll also checkout the BPMN modeller in the near future, all good for now.

davidwhthomas → created an issue.

Just noting I also hit this issue after the Drupal core 10.3.0 upgrade today. It caused significant noticeable site slowdown with many similar log entries.
The workaround approach in #14 🐛 Fix access checks for bundle permissions to avoid triggering a config validation error Fixed helped to fix the issue for now, with thanks.

Tested and working here too, with thanks for the WSOD fix.

I'm not sure if it's the same for your case, but I had to choose the "full" pager in the view and not the "mini" pager. Then the pagination data was correct.

I ended up implementing a token refresh workflow using the session cookie as the refresh token.

It has some benefits, such as

• The /jwt/token path accepts cookie auth
• The session cookie as the refresh token is created automatically on login and removed on logout.
• The session lifetime settings control the refresh token validity period.
• To revoke the refresh token, the session can be closed or deleted.

Thanks for this patch. Tested and working.

Just noting the session cookie name is a hash based on the site host name and base path or cookie domain setting.

the details can be found here. https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Session%2...

Just noting, another way to get a pseudo-random item is, if you get or know the total number of items, you can add a random page "offset" value within that item count to return random item from the set.

Adding some screenshots to illustrate, with thanks for the useful module!

davidwhthomas → created an issue.

Thanks, confirming this fixed the same pager error I was having in D10

davidwhthomas → created an issue.

Just noting the entity_view_mode is available via the REST API.

For easy endpoint visibility and configuration, install  https://www.drupal.org/project/restui → first

Then enable the "Entity view display" resource

It can be requested, for example, at: https://example.com/entity/entity_view_display/node.article.default

davidwhthomas → created an issue.

Just noting I used this patch #51 to successfully migrate node domain data into Drupal 10:

I added this to the migration yaml:

id: custom_d7_node_domain_access
# Other migration yaml then
source:
  # Needs this plugin
  plugin: d7_node_domain_access
  # Example node type
  node_type: article
process:
  # Other node fields then domain fields
  field_domain_access:
      -
        plugin: sub_process
        source: domain_access_node
        process:
          target_id: target_id
  field_domain_all_affiliates:
      -
        plugin: get
        source: domain_all_affiliates
  field_domain_source:
      -
        plugin: get
        source: domain_source

and ran the migration with drush:

drush migrate:import custom_d7_node_domain_access