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?
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.
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?
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...