🇧🇪Belgium @weseze

UPDATE:

So patch #44 was previously working for us. (Drupal 10.1.x through 10.3.x)
Since updating to Drupal 11 (11.2.5 in our case), patch no longer applies.
I tried patch from #49, it did apply, but wasn't working for us. Could not initiate the dragging.

My updated patch from #50 did apply and drag-and-drop was visually working, but the order was not saved.

So, here is an updated patch that actually works for us now.
The trick is to pass the direct parent to the sortable plugin (which is technically not correct, but can be handled in the "dragged" function.

Regarding the comment in #47: I don't think that can ever work correctly since Sortable assumes direct children for the sortable items. Having items in 2 different levels assumes nested sortables. That't something much more complex to implement according to the documentation... (I could be wrong)

Updated patch for 1.7.0 release.

This is expected behaviour when doing DOM manipulations via Javascript.
Drimage only runs on page load, ajax inserts, scroll and resize.
It does not, and also cannot, react to changes made by other Javascripts.

If you are using some technique that output a HTML structure as tabbed content, the invisible tabs containing images will not be handled by drimage.
This is because the calculated width/height in Javascript of hidden images is 0 pixels. Thus, drimage cannot calculate a correct imagestyle and skips.

What you need to do to fix this, is hook into the process that switches tabs and call "Drupal.drimage.init(element_with_the_tabbed_content);" from there.
Replace "element_with_the_tabbed_content" with the actual element that represents the content in the tab that is now visible. (you could also call with no argument and drimage will reprocess everything)

To be 100% technically correct you should also add a class "js-delay-drimage" to your entire "tabbed content" section. This will instruct drimage to skip processing all images in this section so it does not try to process things that are not ready yet.
Once your tabbed content is ready, you can then go ahead and remove this class + call the drimage init function on it.

I hope this helps you fix the issue.
I will leave this ticket open in case you have follow-up questions. Feel free to close if this resolves the issue.

Patch #383 causes issues for me for "weight" fields that are now invalid. Without the patch this is not an issue.

weseze → created an issue.

They should load as soon as the Drupal behaviour is loaded., with a 5ms delay.
On scroll (and also resize) the image dimensions are recalculated and possibly a new source is loaded if the dimensions differ.

None of this should result in a 404 error, since both inline SVG is valid and once an actual image is put as source it should exist on your webserver.

Could you provide more details on the exact weird issues you are experiencing?

Couldn't get the merge request to actually merge, so manually comitted.
Thanks for fixing this!
I will tag a new release shortly.

Also, the issue might be caused by an unstable connection to our servers. Could you please check that on your end?

Not sure how I would check that... Most of our submissions are handled correctly so I would assume the connection to cleantalk servers is working.
We do tend to get a lot of these errors when the website in question is targeted by spam bots, so perhaps the amount of API calls to the cleantalk server is being throttled somewhere beyond our control when this happens...

If for some reason the connection is (temporarily) not working it should be handled better than a fatal error?

No feedback for almost 3 months, so I am assuming this is works as designed. Feel free to reopen if this is still an issue.

weseze → created an issue.

Ran into a very similar issue today, but with a menu block.
Logged in the is-active class was applied, not logged in it was not.

Although probably not a core issue... Once I disabled the big_pipe_sessionless module the problem was fixed.

I understand it is a bit weird, but perfectly possible... And, for us at lease, it is very very handy feature to be able to put html tags with classes in the form without custom code.

Attached is an updated patch that fixes this use case.

Today we ran into this issue, after deploying a Drupal 11.2.5 update. So definitely still a problem.

We experienced this a few moments after deployments and only on very few requests. I would say less than 1 in a 1000.
Also the reported user agents are mostly bots.
The more time passes after our deployment the less of these errors we are receiving.

This lead us to draw the conclusion that it was stale/cached html somewhere that was requesting aggregated CSS/JS assets that no longer exist.

These errors also occurred on websites that have no "minimum cache time headers", nor any sort of external caching infrastructure in front of them at all. So we can rule out things like reverse proxies or misconfigured cache headers.

When inspecting the source of the pages that generates these errors, the referred assets (aggregated file paths) do not exist in the source code at all. So again, we are assuming these errors are coming from stale/cached html pages from before our deploys.

The missing langcode field will also cause issues once core issue 📌 Add langcode from views filter to query metadata Needs work gets resolved.
I am trying to get node access based on language fixed on since forum has its own base table for storing the "nodes", the missing langcode is throwing a fatal error there...

Correct patch, had the path core/modules/node wrong, sorry.

Updated the patch.
Seems that other entities that uses nodes can have their own base_table and do not have to include a langcode. This is possibly a whole other issue, but might as well try and catch that here. So, for now, I only handle node_field_data as base table differently.

I noticed this issue in the forum module, which uses nodes as storage, but a forum_index as base_table and that one does not have a langcode field.
Probably it should have that because access checking will not work correctly for forum nodes bases on my patch... But without the patch it is also not working correctly...
Wondering if nodes using their own base_table should be required to have a langcode?

Not sure why that is needed? Bugs in the module should be handled here?

Anyway, seems the problem is the "src/CleantalkFuncs.php" file, function "public static function _cleantalk_check_spam(", line 680-684:

      if ($send_flag) {
        \Drupal::database()->merge('cleantalk_timelabels')->key(
          ['ct_key' => $timelabels_key,]
        )->fields(['ct_value' => \Drupal::time()->getRequestTime(),])->execute(
        );

Using an IDE with some code checking enabled it clearly states the problem: the "->key()" function expects a string, not an array. See screenshot attached.
I'm not sure how to exactly fix this as it isn't very clear what this code is supposed to to without investing a lot of my time into it.

Also a few lines down there is a call to drupal_mail(): that function does not exist, so fixing the problem above will give a fatal error on that.
The drupal_mail function is a Drupal7 function, never made it into Drupal 8.

Same problem for the function "language_default()" a few lines down, that is a Drupal 7 function, never existed in Drupal 8.

On line 992 there is reference to a non-existing constant, could also give an error:

  public static function ct_die($comment) {
    $err_text = '<center>' . ((defined(
          'CLEANTALK_DISABLE_BLOCKING_TITLE'
        ) && CLEANTALK_DISABLE_BLOCKING_TITLE == TRUE) ? '' : '<b style="color: #49C73B;">Clean</b><b style="color: #349ebf;">Talk.</b> ') . 'Spam protection' . "</center><br><br>\n<center>" . $comment . "</center>";
    $err_text .= '<script>setTimeout("history.back()", 5000);</script>';
    die($err_text);
  }

I would love to help out in getting this fixed, but unfortunately the code is a bit to abstract, undocumented to quickly do so...

Got the same error a few days ago.
The content editor that encountered this error could not remember the steps to reproduce this error. Was able to "work around it".

We are not using "layout_builder_iframe_modal" module, so possibly it's not the culprit here. Or we are running into the same problem from another module with similar code.
Our error trace shows either "layout_builder_at" or "layout_builder_restrictions" is the source of the error.
Are you by any chance using one of these modules?

We are getting hundreds of errors per day now.
It is not happening during updates, our deployment flow put sites in maintenance mode during updates...
The module was installed about 2 week ago, since then nothing that could effect webforms was doen. (only frontend)
Not sure what you mean by the anitspam version? Cleantalk module is running 9.6.1.

Opening again.
We encountered this issue on Drupal 11.2.5 (ckeditor 45) with the linkit module.
The maintainer of the linkit module fixed it, but it now seems there is still a core issue when using a styled link.
Full issue description: https://www.drupal.org/project/linkit/issues/3540235#comment-16296884 🐛 Editing Displayed text generates multiple links Active

weseze → created an issue.

This is still an issue for is, but now only when using styles on links.
If we have a "button-style" on a link, we still get "the 3 links issue". It disappears after clicking somewhere in the ckeditor.
If the link does not use a style, there is no visual issue anymore.

Setting back to needs work. If this is no longer a linkit issue, but an issue with the styles dropdown, feel free to close again.

Can confirm this issue and confirm that the MR fixes it.
Attached is a static patch from the MR to use in composer patch workflow.

Our steps to reproduce this issue:
Created a new page with a layout builder block that contains some paragraph references and save it.
Translate this page, and save => fatal error.

Retested this in version 7.0.9 and the patch is longer needed. Marking as fixed.

Can confirm this issue on Drupal 11.2.4 and confirmed that the MR fixes it.
Also adding a static patch based in the MR, for use in composer patches workflow.

Can confirm this issue on Drupal 11.2.4 and confirmed that the MR fixes it.
Also adding a static patch based in the MR, for use in composer patches workflow.

Experienced a similar issue:
Edited a link, added an ID and saved.
The ID is rendered correctly, both on the frontend and in ckeditor (viewing source code)
Edited the link again and the ID does not show in the popup.

Tried on 2.3.1, I see no further commits so testing a dev release seems pointless?

Also see the CR: https://www.drupal.org/node/3515272 →

The "fieldgroup" type is being deprecated in form API and the suggested migration is to change to "fieldset" type + a "fieldgroup" class in the attributes array.
The CR does not mention that the fieldgroup css / library will be removed or deprecated, although that does seem likely to happen at one point.

Not sure what the best solution would be here...

That is very likely the case yes.

So dit something change in the data-types (in the database/schema-definitions) going from 1.x to 2.x?
Since I was able to store it in the 1.x version, I would assume updating to the 2.x would not give this kind of issue?
Or is it core-related, limits on entity/field storages?

I have tried to fix this locally, but I am not sure this is entirely correct...

If you change this:

      $show_empty_fields = isset($element[$child_name]['#show_empty_fields']) && $element[$child_name]['#show_empty_fields'];
      if ($show_empty_fields) {
        $empty_groups_indication[$child_name] = FALSE;
      }

to this:

      $show_empty_fields = isset($element[$child_name]['#show_empty_fields']) && $element[$child_name]['#show_empty_fields'];
      if ($show_empty_fields) {
        $empty_groups_indication[$child_name] = FALSE;

        // If one of the parents is a group, mark that one as not empty as well.
        if ($element[$child_name]['#group']) {
          $parents = explode('][', $element[$child_name]['#group']);
          if (is_array($parents)) {
            foreach ($parents as $parent_name) {
              if (in_array($parent_name, $groups)) {
                $empty_groups_indication[$parent_name] = FALSE;
              }
            }
          }
        }
      }

it seems to work correctly (for me)...

Can confirm this issue.
When updating our setup to 4.x a lot of our field groups disappeared.
The MR fixes this mostly, but not entirely. 1 edge case remains for us. (this was working in the previous version)

Consider this setup:

- field_group1
  - field_subgroup1 (render when empty is checked here)

This will not render anything, while I expected it to render fully since the subgroup is marked to render if it is empty (which it is).
It might look like a weird setup, but we use this in combination with the option to render a custom html-tag instead of an actual "group" of things. Also this is an extremely simplified example. Our actueal setup contains dozens of nested field groups and a lot of custom classes and javascript processing...

weseze → created an issue.

Confirm this issue exists in latest version, on Drupal 11.2.4.

I went a bit deeper here to try and find a working solution.

So, if there is a grant system active "NodeGrantDatabaseStorage::alterQuery()" adds an EXISTS ( ... ) part to the query (or joined query for relations) that checks if the current user has access to this node via the node_access table's grants.
It can also filter this based on the langcode if the query has the metadata "langcode" set to the corresponding language to filter on.
This part is not correct, since each individual row in the result of the query can have it's own langcode and should be matches to the node_access table, if it defines langcodes.

The correct solution is to bind the langcode in the node_acces table to the main query so each row is correctly checked.
Providing a langcode in grants seems to be optional, so we also need to bind it together if there is no langcode in node_access.

I have made a patch that does this, see attached. (made against Drupal 11.2.4)
Only thing I am not sure about is the "fallback", this can be defined in the grants table and I am not sure how to correctly implement it.

weseze → created an issue.

Patch #44 no longer applies to D11.2
Patch #49 does not work for us, it seems te create a direct parent-child requirement between the regions and the blocks (which is what we set out to avoid?)

Rerolled patch #44 to work against D11.2 and attached it here.

Static patch based on the MR above, for use in composer workflows.

Ran into this issue with a views block that is empty, but still rendering the HTML for it.
MR / patch resolves this issue.

reroll for 11.2

Been using this now for +1 year on several production websites.
Can we get a review?

Using the patch from #2 in production websites for +1year now.
Can we get a review?

weseze → created an issue.

Hi Tim

More info can be found on https://www.drupal.org/project/layout_block →
That module (maintained by me) allows to tie a block-type to a section-type. That in turn creates a block instance for every section instance.
The blocks contain fields that define the layout of the section (for example margins, paddings, background styles, etc..)
This is done so section configuration does not live in code, but in a block type. It allows to more easily maintain the "section-configuration" and have a familiar UI-experience through the use of fields, field_group, etc...

On the section-level this stores a block revision_id, so when copy/pasting (or cloning) blocks, I cannot reference to the same block revision_id as that would tie 2 different sections to the same block. I need to be able to duplicate the block that is referenced and update the new section with that duplicated block's revision_id.

I understand the community is moving away from patches, to MR's, but (currently) MR's are not usable in composer workflows so I need a patch...

Just ran into this issue.

It fired on a fresh install (via drush si) just after (or during) the "install_finish_translations" phase.
Site was installed without any issues and the error never returned when further configuring the site.

weseze → created an issue.

weseze → created an issue.

I think I ran into a similar issue over here: https://www.drupal.org/project/section_library/issues/3275063 →
Also had a blok reference field and expected the block reference to duplicate. Instead the section in the library was referencing the same block as the original section and the imported section was also referencing the same block.

Not sure if the suggested patch is the correct way of doing things.
Leaving entity references intact vs. duplicating the references feels like it should be a choice, not fixed behaviour.
That is why I suggested to have hooks available so you can decide to alter the behaviour in a custom setup.

The patch from #30 causes issues with relationships / contextual filters in combination with a language filter: so not a good solution.

This is the issue where the core mail system is being worked on: https://www.drupal.org/project/drupal/issues/3523592 🌱 Mailer module roadmap: the path to beta and stable Active

weseze → created an issue.

Thanks for understanding and changing the wording! These kinds of changes make my clients very happy

Can you please make a new release for this?

Nothing was fixed here, the wording is still very unclear and implies you have JS disabled in the browers.

As stated in my first post, 99,99% of theses errors (in our experience) have got nothing to do with users having JS disabled in the browser.
But rather, users submitting forms without interaction.
The current error message is confusing and very technical.

rajab natshah → credited weseze → .

You can define fonts in your twig/css files. I don't see the need for this? Can you explain the use case?

weseze → created an issue.

We are currently on 11.1.8. Updating to 11.2.x is not currently possible. I will report back when we update to 11.2.

It can be changed on a per instance basis... The config file for a field instance allows this. Also the translation interface for for example node-types > fields allows this.

Should it not respect the publication settings from the module?

Just tested this on the latest (2.2.8) release and this is still an issue.
Javascript error is still there and causes the widget to not work properly.

Thanks for the quick response and fix! Much appreciated.

Ran into #31: this is a critical bug since the missing JS file will break ckeditor... Even worse if you run JS aggregation (which you should on production). Might break the entire site.

Could this be the default value, when "Adding an existing field" to a content type?

weseze → created an issue.

Re-roll for 11.1.8.

@michaellander: sorry for only getting back to this now, I must have missed your update...

Not sure what you mean by "the part that this patch is missing"? The patch itself is not "missing" anything. What it adds is the option to allow png files to be compressed directly and lossless to webp. It does not affect jpg to webp conversion.

Also, attached is a patch that is compatible with Drupal 11. @see: https://www.drupal.org/project/imageapi_optimize_webp/issues/3504713 🐛 Call to undefined method Drupal\system\Plugin\ImageToolkit\GDToolkit::getResource() Active

I really need to review this, but it is low on my priority list... very sorry for that but it is the reality... :(

Could you provide feedback on the questions I asked in #22? That would at least help me determine if these changes would require a minor or major release, or if some more work is needed to work on backwards compatibility.

Some more changes are needed. See attached patch.

Attached is a patch to fix the issue.

weseze → created an issue.

Can we get a new release for this?

Also experienced this issue where dozens of errors are being logged from malicious requests. These causes unnecessary load on our infrastructure.

I wasn't able to get the core patch working, so we decided to leave things untranslated for our project.

Attached a screenshot of or config for the field that is breaking.

The relevant part from the config:

content:
  field_image:
    type: entity_reference_entity_view
    label: hidden
    settings:
      view_mode: scale_scale
      link: false
    third_party_settings:
      linked_field:
        linked: '1'
        type: field
        destination: field_image_link
        advanced: {  }
        token: ''
    weight: 0
    region: content

The image is rendered as media entity, the media entity renders the image through the drimage module with this twig file:

{% set dummy_image = "data:image/svg+xml;charset=utf8,%3Csvg xmlns='http://www.w3.org/2000/svg'%20width='" ~ width ~ "'%20height='" ~ height ~ "'%20viewBox='0%200%20" ~ width ~ "%20" ~ height ~"'%20%3E%3C/svg%3E" %}
{{ attach_library('drimage/drimage') }}
<div {{ item_attributes }} data-drimage="{{ data|json_encode }}">
  {# Prevent spaces in the link by glueing a and picture element together. #}
  {% if url %}
  <a href="{{ url }}"><picture>
  {% else %}
  <picture>
  {% endif %}

  {% if core_webp or imageapi_optimize_webp %}
    <source data-format="webp" srcset="{{ dummy_image }}" type="image/webp">
  {% endif %}
    <img src="{{ dummy_image }}" width="{{ width }}" height="{{ height }}" alt="{{ alt }}" {% if title %}title="{{ title }}"{% endif %} />

  {% if url %}
  </picture></a>
  {% else %}
  </picture>
  {% endif %}
</div>
<noscript>
  <img src="{{ data.original_source }}" alt="{{ alt }}"{% if title %} title="{{ title }}"{% endif %} width="{{ data.original_width }}" height="{{ data.original_height }}">
</noscript>

Specifally in our case the noscript tag is filtered out, which outputs all our images (with a link) twice.

Just ran into this "bug".
Both in Drupal 10.4.7 and 11.1.7.

I have a view that list the most recent node, filter by published flag and filtered by the content language.
The most recent node is translated, the original language is Dutch, the translation is French. The Dutch language has been unpublished.

I have create a page that shows the view, that page is translated.

When viewing the page with the view in French:
as administrator I get the correct French node as most recent.
as anonymous user I do not get the same node, but 1 older. (in French)

As both admin an ano user I can directly access the published French translation of that most recent node, so no problem there.

Applying the patch from #30 fixes the issue for us.

We are running several node access related modules, but the only one that actually generates entries in the node_access table is view_unpublished. After removing that module the behaviour did not change.
I also tried removing all modules that do something access related, the behaviour did not change.

So for us, this is still a bug and the patch does fix it.

Also can not reproduce this anymore.
I think it was related to one of the many contribs we are using to provide access controle to nodes. Or it has been fixed in core in another way.

For anyone interested, in views this is still a problem: https://www.drupal.org/project/drupal/issues/3061782 📌 Add langcode from views filter to query metadata Needs work

Thanks for the quick response and the new release!

The changes committed here have broken all of our sites... We were using patch #12 previously which worked perfectly fine...

When using it now, the new release without the patch, a lot of HTML from our twig files is filtered out.
This is because of the filtering: "$safe_html = Xss::filterAdmin($html);"
I don't understand why the HTML needs to be filtered, shouldn't it be trusted at this point?
It's already gone through all normal Drupal rendering, so I don't see why it would need any more checking or filtering...

Also, when trying to debug, we could not find the twig templates debug output, because it was stripped from the HTML. This breaks twig debugging output for all linked_fields... Very unfortunate.

So, at least for us, this "fix" and new release is unusable and actually breaks most of our websites...

Attached is a patch that does not filter the html. (as I really don't see the point of doing that...)

I tested the 1.6 + patch file based on "24ec304e - V1 backport".
This work as expected for us. Both in webform mails, and other mails.

What I don't understand is why anyone would go to a path like /index.phpsometext

To fill up the logs of a website with errors.
Or if you want to stay on top of errors and have those on a daily mail or sent through slack or some other platform, this becomes very annoying... Can't think of any legit reason to do so though.

weseze → created an issue.

I see this was marked as fixed.
We were using the patch from #3 against the 1.5.x branch, which worked for us.
Since 1.6 was released and, as far as I can tell, does not contain a fix for this, and the patch from #3 does not apply anymore, attached is an updated patch against 1.6.

Any chance of a patch against latest D11 stable release?
I could not get it working based on the MR diff/patch, tried to fix it manually but I was out of my depth there...

Patch attached for 1.x.

Module seems to work fine with just the infoyaml change.

See: https://www.drupal.org/project/layout_builder_block_clone/issues/3431573 📌 Automated Drupal 11 compatibility fixes for layout_builder_block_clone Needs review

Attached patch makes it work in Drupal 11. Please review.

EDIT: also needs this patch for adva module: https://www.drupal.org/project/adva/issues/3493311 🌱 Drupal 10 -> 11 status? Active

The module seems to work perfectly fine in Drupal11, just needs an info.yml update.
I probably haven't tested all (edge) cases, but the basiscs for us seem to work just fine.

It needed some extra work, attached patch is fully functional in Drupal 11.

Adding a static patch file for composer workflows. (new release would be much better :))

Anyone working on this? Will this ecosystem still exist in Drupal 11 or do we need to migrate to other modules? Content Access, Node Acces, ...?

Anyone working on this? Will this ecosystem still exist in Drupal 11 or do we need to migrate to other modules? Content Access, Node Acces, ...?

Anyone tried the module with this patch on Drupal11 yet? Is it functional? Is a Drupal 11 version being worked on?

Configuration Translation module is enable yes.
"Region and Language > Configuration translation" is available.
But there is no "Content view display" available on that page.

I cannot find any interface for translating the config for field formatters on a view mode...
Maybe this is not available in Drupal 10? Or I need to install a module to do this?

I only get a fatal error at "/admin/config/regional/config-translation/node_view_display".

[Thu Apr 24 17:04:01.371371 2025] [php:notice] [pid 56946] [client 127.0.0.1:59229] Uncaught PHP Exception Drupal\\Component\\Plugin\\Exception\\PluginNotFoundException: "The "node_view_display" plugin does not exist. Valid plugin IDs for Drupal\\config_translation\\ConfigMapperManager are: easy_breadcrumb.general_settings_form, system.site_maintenance_mode, system.site_information_settings, system.rss_feeds_settings, entity.user.admin_form, webform.config, extlink.settings, block_content_fields, media_fields, node_fields, taxonomy_term_fields, user_fields, paragraph_fields, block, block_content_type, config_split, crop_type, entity_browser, filter_format, image_style, imageapi_optimize_pipeline, configurable_language, linkit_profile, login_destination, media_type, metatag_defaults, node_type, search_api_server, search_api_index, solr_field_type, simple_sitemap_type, simple_sitemap, mailer_transport, mailer_policy, menu, taxonomy_vocabulary, user_role, webform_options, webform, workflow, pathauto_pattern, view, paragraphs_type, date_format, entity_view_mode, entity_form_mode" at /.../core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php line 53

Seems like this has nothing to do with the issue here?

weseze → created an issue.