🇧🇪Belgium @weseze

Sorry for not getting back on this issue.

It is caused by core adding some lines to config files imported during install of core and modules.

It adds: (hash will vary offcourse)

_core:
  default_config_hash: xpDeWNLzjX4dDB9YyBlO9y9FR4vHwMv0GKsuqDYy0Bc

This in turn causes translatable labels from the config to go through interface translation rather then translated config files.
There is a valid use case for this scenario, but for me it is an extremely annoying and useless system...

Anyway, simple deleting those 2 lines in all config files fixes all of my issues.

For anyone looking for a quick-and-dirty fix to this issue.

Do a replacement in "/core/assets/vendor/ckeditor5/html-support/html-support.js":
find:

(t,l,i,"classes",(t=>{for(const o of(0,e.toArray)(r))t.add(o)}))

replace with:

(t,l,i,"classes",(t=>{\/*START-CHANGE*\/t.clear();\/*END-CHANGE*\/for(const o of(0,e.toArray)(r))t.add(o)}))

It's a bit of a mess to maintain on updates, but possible with a composer post instal/update script.

This changes the behaviour for the styles dropdown so any style you select will reset any previously applied style (classes) first.

weseze → created an issue.

I disagree.
The type "varchar_ascii" is explicitly set in some commerce schema field definitions. It could also be defined as "varchar", which would default to the collation used by the db/table and "fix" the issue.

Or do you mean that Drupal core should be responsible for correctly handling these ascii mismatch errors?
If so, is there a core issue that you can refer me to?

weseze → created an issue.

@upchuk: did you ever find a solution for this? Or a workaround?

Very strange that we would not be able to pass the ordernumber to Mollie...

There is something seriously wrong with the tax calculation in this module... I had to use patch #6 to make it work, but I also think this is not covering all cases. It just works for my specific case.

I have the store setup with prices including EU tax rate.
I have a custom tax resolver that checks user profile for tax rate. All orders are placed with logged in users and are B2B within the EU. So same country orders have to include tax, other countries don't.

Problem 1:
The shipping cost was set up without included TAX, but inherits from the store/tax settings (which say it should be included) There is no option to choose this per shipping method.... This is not incorrect, but confusing... I expected to able to chose this per shipping method.

Problem 2:
In the total calculation the shipping cost is shown before the tax cost. But the shipping cost shown already includes the tax... Very confusing for the end user. The same problem applies to the line-items, so this might by a commerce "design-choice".

Problem 3:
When my custom taxresolver returns a no-tax policy for the current user, the shipping cost is still calculated as the original entered amount, which includes tax. Taxes should be subtracted here, because customer does not pay taxes.

So, I managed to fix the issue with patch #6, but it feels like this is going to be something that is going to break or need updating and testing on every commerce update...
It is also technically wrong for me now, since shipping costs are entered as being prices with tax included, but now, with this patch, they are not... But it works because if you pay no taxes (0%) the tax amount subtracted is also 0...

Seems this is issue is also present in plain vanilla Drupal core forms: 🐛 Prevention of multiple submits blocks use of back navigation Active

I'm reopening this because it still exists. At least in my test in Drupal 10.2 but I'm assuming it also exists in 10.3 and 11.
You do have to use certain browsers.

In Chrome this is not an issue for me: version 127.0.6533.89 (Official Build) (arm64)
In Firefox this is an issue: version 130.0.1 (64-bit)
Client working in latest version of Edge also reported this problem.
A colleague working in Firefox Developer Edition (latest up-to-date version) also reported this problem.

This was tested using the test scenario as described by kalpaitch in the original post.

We first encountered this issue in a commerce setup, where this is issue was already reported several times, but no solution yet.
🐛 Using the browser's back button disables checkout button on cart form Active
🐛 Next buttons are blocked until page refresh after use browser's back button Active

There are 2 ways to get it working again (not a fix, but might give some insight into what the problem is):
1/
Inspect the page, navigate to the form element and remove the "data-drupal-form-submit-last" attribute.
2/
Make any change in any of the fields in the form.
Both of these make the form work again.

I have traced back the "data-drupal-form-submit-last" and it has something to do with preventing the form from being submit (double clicking the submit)

This was already reported, but no solution yet...: https://www.drupal.org/project/commerce/issues/3383845 🐛 Using the browser's back button disables checkout button on cart form Active

Also have this issue while using Firefox or Edge back buttons. Not an issue in Chrome.

The reverse issue also exist.
If I make an interface translation (locally) for one of the labels of the form modes and do a config export, the label for the form mode gets exported from the interface translation... very weird.

Just ran into this issue again.
Form mode name "Shipping", translations for it exported to config.
After deploying to staging, the interface translations for "Shipping", used by commerce_shipping module, were overwriten by the config imports from form_mode_manager.

This is really really annoying. How can I help get this fixed?

Works perfectly: https://www.drupal.org/project/redirect_after_registration →

I have the same issue...
Payments are marked as completed and paid, but the total amount remains open.
The order log shows that the payment info was received correctly.

Some quick debugging showed that the payment update from Mollie webhook is received in the "onNotify" function. The status is correct and this piece of code is executed:

    switch ($mollie_payment_remote_object->status) {
      case MolliePaymentStatus::STATUS_PAID:
        // Capture payment.
        $payment_transition = $payment->getState()->getWorkflow()->getTransition('authorize_capture');
        $payment->getState()->applyTransition($payment_transition);
        $payment->setRemoteState($mollie_payment_remote_object->status);
        $payment->save();
        break;

This correctly registers the payment as paid, but does not register the amount paid.
Looking through the commerce documentation: it states that it will only update the amount if the state changes to "completed", so this should work?

Do you need more info, I'm a bit lost in debugging this...

I have a very similar problem. Getting fatal errors on the webhook and payments are not registering.

The "id" is always empty... I checked the transaction in Mollie and they confusingly mention "order_id" as sent metadata to the webhook, but that is not what they actually send...

Still payments are never updated.
Yet the order history log mentions a payment received with the correct amount AND the correct remote_id.

@michiellucas: how did you fix this issue?

weseze → created an issue.

We are seeing the same type of issue with specifically crafted URL's causing errors when logging the "location" field for a page not found log.

These url's contain the "\x85" byte sequence. (displayed as character "…")
Using this byte sequence in the request url, for a non existing URL, causes a log entry to be written in dblog (the page not found message), and trying to write this to database than causes a fatal error to be thrown.

This does not cause any direct security risks, just annoying to have all these fatal errors in the log.

Should we also apply "mb_convert_encoding()" to al $context parameters?

I also need this functionality, didn't expect that it would not be standard...

Attached is a revised patch that works against latest stable release. (8.x-1.5)

I've added 2 changes:
1/ passing the langcode also to the the $params array
2/ reset the active language to what it was after the mail processing; this would prevent any other processes from using the wrong language

Also fixed som typos in variable names. (but that might be because of changes to dev?)

I als think this still needs work since the behaviour should be optional/configurable.
You do not always want to send mails in the customers language. For example when sending mails to administrators, they prefer fixed language.

weseze → created an issue.

I think the public/private detection is already done somewhere in the image() function in the controller. We should be able to pass it correctly.
Quick question, since I'm still running 10.2 atm, this change would make it break with 10.2?

Will have a look at this at the end of the week and try to get it release.

Thanks for the work! I'll make time at the end of the week and try and get it merged in and released.

Please don't make breaking changes that require manual work to fix... This is a hell when maintaining 100's of sites.
Can't we instead create an update/post_update/deploy hook to fix things?

MR22 works fine. (tried the patch from it against latest release)

Can we get feedback from the maintainers?

weseze → created an issue.

For those experiencing this issue with a cookiebot implementation, see my fix in 🐛 stopped working after adding cookie consent JS Fixed .

This is a cookiebot issue, not an antibot issue.

You can try and bypass the issue with this custom code in a custom module:

/**
 * Prevent cookiebot from blocking antibot. (testing code: to evaluate)
 *
 * Implements hook_library_info_alter().
 */
function MY_MODULE_library_info_alter(&$libraries, $extension) {
  if (isset($libraries['antibot.form'])) {
    $libraries['antibot.form']['js']['js/antibot.js']['attributes'] = ['data-cookieconsent' => 'ignore'];
  }
  if (isset($libraries['drupalSettings'])) {
    $libraries['drupalSettings']['js']['misc/drupalSettingsLoader.js']['attributes'] = ['data-cookieconsent' => 'ignore' ];
  }
  if (isset($libraries['drupal'])) {
    $libraries['drupal']['js']['misc/drupal.js']['attributes'] = ['data-cookieconsent' => 'ignore'];
  }
}

However, the better solution is to disable auto-blocking mode in cookiebot and handle JS files which set cookies properly from within Drupal.

You can do al these things with this module.

entity_pdf is a simple module, with a developer orientation.
entity_print can do much more and is more site-builder oriented.

Duplicate 📌 Automated Drupal 11 compatibility fixes for entity_pdf Needs review

Fixed and comitted, should be in next release. (2.0.7)

Should be boolean, not string.

Any possibility of updating the MR instead of forking?

I am willing to commit to get this working within drimage itself.
But comparing the forked module to the drimage, porting over changes and testing them, is not making this easy for me... :(

The field_widget / field_formatter implementation is in my opinion the only correct way forward for this.

I will close this issue since there is lack of development on this feature. (and I personally do not have a need for it)
If this changes, do not hesitate to ask my to reopen this issue, or start a new one.
This could also be done in another contrib module.

Seems straight forward enough to commit. Thanks!
Will be in the next release. (2.3.2)

Very cool idea, if it is optional.
I'm willing to review patch/MR if you have it.

I did some small tests and have some feedback.
I will try and make some more time this week to further test and maybe try and get this fully working but feel free to help me out here ;)

1/
The first request causes a redirect. Is this something we can avoid?

2/
The image_widget_crop handling contains an error. See revised code below that does work correctly.

      if ($this->moduleHandler->moduleExists('image_widget_crop') && isset($style_parts[3])) {
        $width = $style_parts[1];
        $height = $style_parts[2];
        // Need to implode all parts from index 3 and further to get the correct iwc_id.
        // The image widget crop id itself can contain underscores.
        $iwc_id = implode('_', array_slice($style_parts, 3));
      }

3/
Do we need the same kind if checks for the focal_point integration?

4/
I think there is some code + documentation and example to rewrite url's via apache vhosts: this will need to change also.

5/
Is there any other code we can delete once this new delivery mechanism is in place?

I'm also struggling to understand why we are searching for users and roles with the given search string?
What is the use case for this?

I'll reopen and try to make some time to review this. Sounds like a much better approach!

weseze → created an issue.

Updated the patch. It sill gave us issues.
After further debugging noticed that the $text variable isn't actually a string, but a text object. It can be used straight up without any parsing to preserve all special characters.

Patch from #3 can cause contextual links placeholder to be rendered wrong, causing it to replace portions of your content instead of just the contextual placeholder div-element.
You should not use this patch.

Instead, modules should fix their implementations and not use htmlentity encoding/decoding.
Just encountered this issue using linked_field module. See 🐛 Special characters are stripped Needs review .

Changes in MR are already committed (but not released), see 🐛 Linking breaks responsive image formats Fixed . (should really have this released)
Also, for us at least, this does not fix the issue. Special characters are still being stripped out.

We tried reverting the change from core: 🐛 [PP-upstream] Serialize function strips accents Postponed
That fixes the issue, but creates a whole new set of issues with contextual links being broken.
These seem to be converted into self-closing div tags, which is incorrect html and causes the contextual JS logic to incorrectly replace those.

The only full solution we fount, is to use patch #8 from 🐛 Linking breaks responsive image formats Fixed in combination with removing the "$text = htmlentities($text, ENT_QUOTES, 'UTF-8');" and "$value = Html::decodeEntities($value);". (see patch attached here)

weseze → created an issue.

weseze → created an issue.

Very good te know. Thanks for taking the time to answer!

Question on the change drimage.module.
Doesn't adding this line:

use Drupal\imageapi_optimize\ImageAPIOptimizePipelineInterface;

create a dependency on the the "imageapi_optimize" module?

What happens if you don't have the module? Error or warning?

Also this function:

function drimage_imageapi_optimize_pipeline_update(ImageAPIOptimizePipelineInterface $entity): void {
...
}

implies that the object "ImageAPIOptimizePipelineInterface" is availble and thus creates a dependency on an optional module.

Or am I wrong in this assumption?

I understand the technical explanation.
However, it is extremely confusing for non-technical persons. They sort their handlers and expect them to be executed in that order...

Perhaps a feature request to group them?

weseze → created an issue.

Patch nog longer applies to 2.0.1.

Thanks for the feedback.
Seems there are indeed upstream issues that are trying to address this:
https://github.com/ckeditor/ckeditor5/issues/14206 (thanks @bkosborne for finding it)
Also https://github.com/ckeditor/ckeditor5/issues/14946 mentions something very similar.
But all of those seem to be focussed on creating very complex logic for allowing multitple selections, remove classes and so on...

The only thing we need (and I guess a lot of users migrating from cke4 also need) is a simple toggle config option to disallow selecting multiple styles.
Is something like that available in cke5/drupal?

Would really hate to have to build our own plugin for this...

weseze → created an issue.

Can confirm this error.
Some of our content editors are getting stuck in this flow by mass translating in dozens of browser tabs and having some duplicates (already translated nodes) open.
Very easy to get in to this problem, very hard te understand without technical knowledge why this is a problem...

MR from DieterHolvoet fixes the issue nicely. Thanks!

The patch is working fine for me so I comitted it.

Do you have actual implementations for other engine that we could include?

Can you provide some documentation (for the readme and the project page) on how to create a new engine in a custom module?
If we have that I would feel comfortable making a new release.

Or I could add you as co-maintainer to work on that?

@Dieter: never received your message... How did you contact me?

weseze → created an issue.

Same experience as maxilein.

The patch fixes our problem for storing correct numbers.
But if we try and enter bigger numbers we get a nasty WSOD and some SQL out-of-bound errors. Not a warning in the interface.

I've made the change, but haven't properly tested yet.

weseze → created an issue.

weseze → created an issue.

Also experienced this issue today.
Frontend had added classes/wrappers to the links.html.twig and written CSS for it, nothing was visible...
We then tried removing the twig and noticed it was still in use...

Running "window.sessionStorage.clear()" fixed it.

Fixed and released to 1.3.

Closing this as a duplicate of #2992777: there seems to be some good work going on there, will try and check that.

I actually think the accessCheck should be FALSE here. I think it does not matter if the user deleting the translation has access to the paragraphs on the translation, they should be deleted anyway to prevent stale date in the database.

Setting back to needs work until I (or someone else) can confirm this.

@DieterHolvoet: Have you got any D9.3 installations to test on? (I don't)
Might be easier to just make a quick new release and up our minimum requirements to D9.5?

I'm marking this as won't fix. Setting an arbitrary delay is no guarantee it will always work. The correct way to fix this is to "hack" into whatever ajax callback is being executed and add a Drupal.drimage.init(yourElement); at the end of it.

However, that being said, we are also making heavy use of drimage within layoutbuilder and don't have any such issues...
So either I'm misunderstanding the issue and need more info or the issue you are experiencing is related to some custom code or contrib module.

Feel free to reopen and info if this issue is not resolved for you.

weseze → created an issue.

Seems good to me. Haven't tested since I don't use stage_file_proxy module. I'm assuming it works ;)
Will include this in the next release.

https://www.drupal.org/project/hubspot_embed/issues/3350218 📌 Replace README.txt with README.md RTBC

Closing because there is no more feedback. I'm assuming you resolved the issue. Feel free to reopen if there is more feedback.

A few remarks before we can get this in:

1/ Do we need the "declare(strict_types = 1);"? I'd prefer not to do this.

2/ Parts of the code require PHP8+. We still support Drupal9, which does not require PHP8. Can we rewrite the code in the patch to be compatible with PHP7? If not, we will need to also patch the info.yml and remove the D9.5 compatibility.

weseze → created an issue.

Patch applies correctly to latest releases of both D9 and D10. (haven't tested dev)
We are using it to fix serious performance issues in a heavy customised layout builder setup. Layout builder pages can contains up to 100 inline blocks. (but really there is no actual hard limit for us)

Before the patch (while editing and translating pages with LB) we had 5-10.000 SQL queries taking 3-5seconds of loading time. (depending on the complexity of the layout builder setup on the page)
After the patch this went down to few hundred SQL queries and e few hundred ms of loading time.

This is a lifesaver for us, so thanks to everyone here for all the work put in!

Having trouble applying the diff from the merge request via composer.json, so I have attched a patch file that does work for me.

Was already fixed... (forgot)

You would have to share your code for me te provide feedback on this...
My first guess is that you are passing an empty variable to Drupal.drimage.init(yourVariable).

weseze → created an issue.

Images are only loaded on page load and on scrolling. Any other system (like tabs) needs to implement a drimage delay class and JS init function to make it work.
The documenation for this can be found on the project homepage ( https://www.drupal.org/project/drimage/ → ) or in the READMe file in the drimage module.
Bascially you need to add a delay class, remove it when the tab opens and then call drimage init function on the content of the tab.

tabElement.classList.remove('js-delay-drimage');
Drupal.drimage.init(tabElement);

What system for "tabs" are you using?

weseze → created an issue.

weseze → created an issue.

Installation on a fresh D10 failed for us, because the rac.permissions.yml file was missing.
Patch from https://git.drupalcode.org/project/rac/-/merge_requests/1.diff fixed the issue.

weseze → created an issue.

Rerolled for D10.1.x

Update patch so it applies to seven as D10 contrib theme rather D9 core theme.

Patch for D10 based in my D9 patch from #151. Just here to more easily migrate from D9 to D10 without having to worry about changed behaviour during the update.

weseze → created an issue.