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?
Same problem on Drupal 10.3.14, patch fixes it.
It should be compatible with both.
Although the functionality for focal_point was added 8years ago and I personally don't use it, nor test for it...
So, if it is no longer working, please open a new issue for that.
I can confirm that the patch from #37 applies to the latest v4.0.3 version of the module and everything is working as expected.
Setting to "Needs review" so the maintainers can have a look and provide feedback, if needed.
We recently updated our entire drupal stack from address 1.x to 2.x and noticed that the field settings for address are not migrated correct. Sometimes the new "addresline3" is missing, sometimes our entire config of which fields to show/hide/require is lost...
This is a major problem and it seems we cannot fix it anymore. The config is lost...
Or only option is to go through GIT logs of the config files manually and correct this error.
Seems like some more warning is needed?
dieterholvoet → credited weseze → .
Patch #14 is not working for us on version 3.6. All field groups are always empty...
Tried without the patch and it seems to be working just fine. Not sure why the patch is still needed?
I have created a fix for this, patch attached. Both for the dropdowns and the baloon panels.
It's not pretty but can't find any better way at the moment.
For Drupal 10.3.x the latest version of this module (2.1.0) is working correctly.
The extra parameter ($required_derivative_scheme) was added in this release.
So not patch is needed for Drupal core 10.3x and 2.1.0 of this module.
As for Drupal11 compatibility: I do not know, have not tested this yet. But looking at the code it should work without the need for this patch.
Ah I see, must be an issue on my end... I seem to be stuck on the beta5 for some reason.
When will support for address 2.x be released?
A patch file does not work in a composer workflow and checking out branches at commit hashes instead of using versions kind of beats the entire idea of using a versioning tool like composer...
For anyone needing a quickfix, this is wat I ended up using:
/**
* Implements hook_preprocess_HOOK().
*/
function MODULE_preprocess_commerce_order_total_summary(&$variables) {
if (isset($variables['totals']['adjustments'])) {
foreach ($variables['totals']['adjustments'] as $key => $adjustment) {
if ($adjustment['type'] === 'tax') {
$variables['totals']['adjustments'][$key]['label'] = t('VAT');
}
}
}
Love to help in the coming weeks, but I personally find working with MR's a nightmare... Would much more prefer an alpha release to start testing on.
Everyone working with me (4 people) agree on my approach described in #3.
1/ Export the templates in the language of the host entity they were created from
2/ Give templates the language of the host entity on which they are imported (this one prevents serious technical issues also)
No, I don't have any direct contact info for any of the maintainers... (also don't know who actually has permission to publish releases)
OK, understood. Marking as "works as designed". Thanks for the feedback!
Ran into this issue today. So just confirming this is still an issue.
Thanks for the info! Really appreciate it.
I did not know that the fullscreen plugin was not an official ckeditor one.
Can you provide info on where the official one is being developed?
weseze → created an issue. See original summary → .
if ($account->hasPermission('edit search api exclude entity:')) {
needs to be:
if ($account->hasPermission('edit search api exclude entity')) {
?
Any solutions or workarrounds yet?
This is blocking us from migrating our sites to ckeditor5... :(
OK, it's fixed.
Seems it was a compatibility issue with the "ckeditor5_fullscreen". Can't have both installed...
abhi_khandelwal report that the patch from #2 works. There is no difference in the other patches/MR's.
When can we expect a Drupal11 compatible release?
I don't really understand what the issue(s) are here...
Seems like some tokens work and others do not, and I don't understand why.
Some examples:
[commerce_order:id] => works fine
[commerce_order:order_number] => does not output anything
[commerce_order:changed] => does not output anything
[commerce_order:changed:value] => outputs a timestamp
[commerce_order:placed] / [commerce_order:placed:value] => does not output anything
I had more issues, but can remember them all.
I will test some more next week on a staging environment. Some issues might be caused due to the order completion event not firing correctly on my local dev...
If we would include this patch on our Drupal setup, would sites that have "old" / "unmigrated" keys still work?
All of our websites that have recaptcha shoul be on a Google Cloud project and can use the enterprise variant of the script.
But I want to sure that if there are still websites with captcha keys that have not been migrated (yet), they will also work on the enterprise script.
Or is that simply not an issue?
Nevermind, I was using tokens that didn't exist (yet)...
Update: If I debug the commerce order variable in the code I also get just the ID, not a commerce_order entity... That would explain why none of the subtokens are working.
I will try some deeper debugging to see what is going on exactly: will report back if I find anything ;)
Since Google is transitioning to the Enterprise model before the end of the year, this looks super important to get in?
Is the patch something that I can use on a production website? Or is more testing needed?
Is this backwards compatible with captcha keys that have not been migrated yet?
Tried with a dev checkout from #3499977 but didn't work straight away.
First It wasn't obvious that I needed to enable on a per-field bases in the "Manage form display". In retrospect this does seem kind of logic :)
I also had to change the below code in (\Drupal\ai_translate_textfield\AiTranslateTexfieldCallbacks)
private static function getProvider() {
/** @var \Drupal\ai\AiProviderPluginManager $aiProviderManager */
$aiProviderManager = \Drupal::service('ai.provider');
$config = \Drupal::config('ai_translate_textfield.settings');
$provider_id = $config->get('provider');
$model_id = $config->get('provider') ?? '';
if (!empty($provider_id)) {
$provider = $aiProviderManager->loadProviderFromSimpleOption($provider_id . '__' . $model_id);
}
else {
// Get the default provider.
$default_provider = $aiProviderManager->getDefaultProviderForOperationType('translate_text');
if (empty($default_provider['provider_id'])) {
return NULL;
}
$provider = $aiProviderManager->createInstance($default_provider['provider_id']);
}
return $provider;
}
To:
private static function getProvider() {
/** @var \Drupal\ai\AiProviderPluginManager $aiProviderManager */
$aiProviderManager = \Drupal::service('ai.provider');
$config = \Drupal::config('ai_translate_textfield.settings');
$provider_id = $config->get('provider');
$model_id = $config->get('model') ?? '';
if (!empty($provider_id)) {
$provider = $aiProviderManager->loadProviderFromSimpleOption($provider_id . '__' . $model_id);
}
if (empty($provider)) {
// Get the default provider.
$default_provider = $aiProviderManager->getDefaultProviderForOperationType('translate_text');
if (empty($default_provider['provider_id'])) {
return NULL;
}
$provider = $aiProviderManager->createInstance($default_provider['provider_id']);
}
return $provider;
}
It is no fetching the correct ai provider at all for me... I went to all the configuration and it all seems to be OK. Also translation is working fine in other places.
Obviously, something is still going wrong in trying to fetch the configured provider, but loading the default one in case of issues at least makes it work.
Tried this today and, at least for us, translating text with html markup seems to lose all html markup in the translation.
I tried applying the changes from the MR, but that didn't change the behaviour. (not sure how I could directly test the MR...)
Didn't work for me :(
I can not get anything more specific from the commerce-order token itself. They al output blank...
For my use case I have written some custom code to "fix" the issue.
I'm tempted to agree with jsacksick on this:
Well the thing is, I'm not sure "Delete the account and make its content belong to the Anonymous user." applies to profiles... but maybe.
Perhaps it might be enough to add a warning message that profiles will also be deleted?
I'll try and get this released today.
Thanks for taking the time to document and fix it!
When can we expect a release for this?
Or could you upload a patch file based on your rebase?
I have tagged a new release, but unable to actually publish the release. I'm missing permissions for that...
You could use display suite module to have a drag-and-drop pseudo-field.
But your method works just as well, nothing wrong with it.
Seems like an issue for the "views_bulk_operations" module?
Feel free te re-open if changes are needed in "entity_pdf".
We had the same issues. Just use this module instead:
https://www.drupal.org/project/xls_views_data_export →
Works perfectly fine for us.
I tried this patch. Technically this works fine and the error is gone.
If I understand correctly, this assumes that the file is a "translatable field"?
We never do this, as we approach "translated" files as "new" and not translations. (I hope that makes sense)
So in that setup it is very confusing for content editors and might lead to unintended data loss. Knowing our content editors it will 100% sure lead to unintended data loss and we will 100% sure get the blame for it. (and rightfully so)
For me there is no reason to allow deleting the associated file on a translation. (in the case that the file itself is not translatable)
Doing so will result in the original language + other remaining translations still existing but without a physical file...
Is this something that can be fixed, configured? Or am I missing something in the module + patch here that would allow me to fix this myself?
I did some more digging and found the issue is the "webform_library_info_build()".
This function loads all webform, checks them for custom CSS/JS and adds those as a library if needed.
The website where we noticed the issue has 1000+ webforms. So trying to load them all leads to 200Mb of memory usage.
I tried changing the code to load them 1-by-1 and clear the static entity caching between each, but this didn't help. The memory usage stayed the same. I thought this would have been a quick and easy "fix"... :(
The better solution would be to split the code in 2 pieces:
1/ general CSS/JSS assets need to be added once in a "shared" library for all webforms
2/ only webforms that have specific CSS/JSS assets need to be loaded: this could still be an issue if there are many: not sure how to address that...
Seems fine to me, you can merge this.
patch 47 works fine for us. (it did need manually updating the block settings from previous patch...)
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?
@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.
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?
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?