🇧🇪Belgium @bramvandenbulcke

Thanks!

We are using the version of #6 in production and everything is going well.

Each webform has options for the submissions. 

Go to: Admin > Structure > Webforms > (Choose the form you want to edit) Settings > Submissions > Submission general settings > Included submission values

Check both Exclude empty elements and Exclude unselected checkboxes. 

I have a similar problem. Which setting are you referring to? 

We are in the same boat! Similar request here.

Maybe noting: we used mollie_payment in our setup but switched to commerce_mollie because there were problems with some payments (visitors abandoning the payment) in combination with the Entity Registration module.

Switching from mollie_payment to commerce_mollie solved our problem but we also switched from api v2 to api v1!

I'm also seeing this. Install: Drupal 10.3 with PHP 8.3.

I have nested paragraphs but it's also happening on normal paragraphs (without nesting). I'm also using exclude a lot on my paragraph fields.

I can confirm this issue.

I'm also seeing this on several websites.

It's also showing on Webforms. See for example the screenshot of a remote post handler.

Same here!

This regressions started with Gin release 8.x-3.0-rc11.

It's working well: the path https://example.org/sitemap.xml is now accessible for anonymous users.

Thanks!

To find the code, go to your Matomo environment (in my case company.matomo.cloud) and log in. Then click at Tag Manager in the top menu. Next, select the correct instance (in my case company.com) and the correct container (in my case this is also company.com).

In the menu on the left side, you will see an 'Install Code' link. This code snippet will contain the URL to a JavaScript file.

For example:

https://cdn.matomo.cloud/company.matomo.cloud/container_abcd1234.js

You need to copy and paste this URL in the Container URL field of the Matomo Drupal submodule.

We have a minor issue in our install.

We did the following:

• EU Cookie Compliance was already installed. We use Opt-in with categories. Disable JavaScripts is empty and "Enable cookie(s) automatic-removal when consent isn't given" is disabled.
• Implement Google Tag module ( https://www.drupal.org/project/google_tag → ) including this patch: https://www.drupal.org/project/google_tag/issues/3424623 🐛 "Enforce Privacy Consent Policy" checkbox default value is checked even when it is disabled RTBC . I guess this patch will me merged in on the next Google Tag release.
• Implement EU Cookie Compliance GTM ( https://www.drupal.org/project/eu_cookie_compliance_gtm → ) plus patch #9.

And for the cookies:

Functional cookies:

{
"functionality_storage": "@status",
}

Analytical cookies:

{
"analytics_storage": "@status"
}

Marketing cookies:

{
"ad_personalization": "@status",
"ad_storage": "@status",
"ad_user_data": "@status",
}

There is one weird thing. We receive an additional event cookie_consent_post_pref_load. This shouldn't be here I guess. Any ideas? See the screenshot.

@Statamis Giannakis. I've seen this as well in the past.

Can you uncheck the checkbox "Enable cookie(s) automatic-removal when consent isn't given" (Under Cookie handling) in the settings of EU Cookie Compliance and test again?

Patch #11 is working well. I'm using Drupal 10.2.5 at the moment.

Steps taken:

• Make sure download link is set for Document under /admin/structure/media/manage/document/display. And for my use case: add Name to the form display
• Add patch #11 to composer.patches.json and run composer install
• Copy the media-entity-download-link.html.twig template from /modules/contrib/media_entity_download/templates to the theme folder
• Apply the changes in the markup. I'm using the Name field as the link text. This makes the most sense (the description field is not available anyway). This code inside the Twig block: {{ link|merge({'#title': media_entity.name.value }) }}

I have been using the conversion to webp functionality since launch (in core). I have seen this behaviour from the beginning. But I thought this was intentional. Apparently not!

We've been using patch #17 for some time now and it's working fine!

I updated one site with this issue and after the db updates of 4.1.0-rc7 the errors are no more showing.

I know this issue is really old but this issue is still present in the 3.x branch.

The Group cells field should allow more than only numbers. Flickity groupCells uses an integer, a boolean or a percentage value, see https://flickity.metafizzy.co/options#groupcells.

In a project I'm working on I'm using 4 for a carousel with logos. This is fine on desktop but on mobile 4 is too much. So, the option 'true' would be a solution: this takes into account the viewport.

I agree with the remarks.

The plus icons at the top and bottom of the element are certainly an improvement. Also the icons are nicer than the 1.5x icons. But the 'jiggle' (elements moving) when hovering over the elements is annoying.

Great!

Yes, sorting with excluded paragraphs on the frontend is working now. Thanks a lot!

Thanks for the patch and the quick response!

When using the patch, I'm seeing the correct paragraphs in the frontend. So the excluded option is working now. Only small thing I'm seeing is the weight of the paragraphs is not respected. The sorting of the excluded paragraphs is in my case alphabetically using the machine name of the paragraph type. The sorting is respected in the backend, so you can test this by comparing the sorting in the backend (by using the form display of paragraphs itself, for example show paragraphs with dropdown button).

I'm not sure the sorting remark should be in this issue. I can open a new issue if you prefer that.

Thanks for the update. I will wait for the fixes.

Will this be fixed in the 4.1.x version eventually? I'm working on a new, to launch project with this error. I could uninstall this version and install the 4.0.x version but that will take some work. If there is a fix in the future for this error, I could leave the error and wait for the fix. Everything is functionally working.

bramvandenbulcke → created an issue.

For reference see https://www.drupal.org/project/heading/issues/2934662 → .

I have the same errors. Also using heading field on paragraphs.

The update is working well on our side. Thanks!

We are using Antibot on more than 20 installations. Antibot was doing really well in protecting against spambots for several years, in a 'set it and forget it' way. Beginning of last week, we started receiving messages from several clients saying spam was getting through the webforms, mostly simple contact webforms.

At first, I thought these spam messages were human spam. But the amount of spam was increasing and the IP addresses are rather random, which points to spambots bypassing the Antibot protection. Most spam I've seen was maximum five/six messages per day: no huge numbers but still annoying.

I've added Honeypot (with a non-default hidden field name) to some Antibot instances but that didn't help. Honeypot used to be an elegant anti-spam method but it doesn't work anymore for us. This week, I've been busy implementing reCAPTCHA 3 (with the Simple Google reCAPTCHA module) on several instances. This blocks the spam but creates another dependency on Google.

I will try patch #14 on the remaining instances.

A follow up from my side: I used patch 3379445-25.patch and thought everything was working fine but the count of the pager wasn't working with the patch installed. For example: select a facet selection with a result of 3 pages and when selecting the next page the pager goes to 9 pages.

As a temporary fix I disabled AJAX on these facet views.

Thanks for linking the other issues!

The module smart_date_recur is not installed in my case.

Also adding the schema from phpMyAdmin.

I'm in the same situation.

The error started showing on two installs after upgrading from 4.0.x to 4.1.x. This had one db update (increase_column_storage): this update applied cleanly. On one install, in development phase, I could remove the field and add it again. Another install has already more than 1000 nodes, so this one will be more tricky. I guess the client won't notice, as everything is still functioning as before. The installation in development phase has one language, the other is multilingual. Both installs use the same field (field_date) on two content types.

Errors:

• Status report: Mismatched entity and/or field definitions. The following changes were detected in the entity type and field definitions. Content: The node.field_date field needs to be updated.
• When trying to resave the field: An error occurred while saving the field: The SQL storage cannot change the schema for an existing field (field_date in node entity) with data.

I also add the schema info.

@kevinfunk. Thanks, the patch is working well!

Patch 3379445-25.patch is working fine for me.

@wfraga: is Facets 3.x enabled (installed) on your website?

I guess I was too fast (with my update of the module). This error is not showing anymore.

bramvandenbulcke → created an issue.

The script didn't show an option to confirm. It ends with the error.

In the end all my scripts are in place and when I run composer update again, the error isn't shown anymore.

But it's possible others will encounter the issue and maybe there is some explanation for it.

bramvandenbulcke → created an issue.

@saschaeggi see the attached screenshot for the icons in my install.

I only added the patch 3394085-09, I didn't add your commits 30d5cc78 and ac492711. So I have no updated CSS in my project.

@saschaeggi the MR shows the same error but patch 3394085-09 is working fine. The icons in the experimental sidebar look a bit weird but the functionality is working fine with this patch.

bramvandenbulcke → created an issue.

This regression really breaks the proper functioning of the module!

If you have anonymous users checked under user role and this condition is reversed after the 2.x update, then you are basically tracking no users at all.

I'm using config management and I didn't see it.

I have a website with a block where content type + negate this condition was used. The checkbox 'negate this condition' is no longer shown but the negate is still applied. So, I'm basically locked out of the setting. The website uses Chaos Tools.

I'm also in favour of this setting. In my case I have a hero region which applies for all content types except some secondary layouts. So in that case I use negate: if another content type is added, it would also have the hero region. Using negate is often a way to make an install easier to manage in the future.

This would be a welcome addition to the Metatags module! The forms are too long now and contain obsolete information:

• The Basic tags contain two fields that are no longer supported. This information clutters the interface.
• The Open Graph tags form is really long.

I mostly try to avoid printing the form for website editors (mostly by using a summary field) but sometimes they want a custom metatag description.

I'm currently hiding the unused metatags in Seven with some CSS (I use a small custom module to override the admin styling):

#edit-field-metatags-0-basic .form-item,
#edit-field-metatags-0-open-graph .form-item {
	display: none;
}

#edit-field-metatags-0-basic .form-item.form-item-field-metatags-0-basic-title,
#edit-field-metatags-0-basic .form-item.form-item-field-metatags-0-basic-description,
#edit-field-metatags-0-open-graph .form-item.form-item-field-metatags-0-open-graph-og-title,
#edit-field-metatags-0-open-graph .form-item.form-item-field-metatags-0-open-graph-og-description {
	display: block;
}

This will expose only the meta title and description on the basic and Open Graph fields. It's a dirty solutions but it helps to clean up the interface.

Thanks for the patch! It's working as intended.

I also encountered this issue when updating to Drupal 10.1. Drupal drupal/core-recommended was updating to 10.1 beta. I just could't figure out the reason. I normally run composer update globally.

This was the information I needed to solve the problem (and ending up in this thread):

drupal/core-recommended 10.1.0 requires egulias/email-validator ~4.0.1

Uninstalling Swiftmailer and Mailsystem and replacing both with Symfony Mailer was indeed the solution. As said by Anybody: my custom email templates used with Swiftmailer are also working with Symfony Mailer.

This issue was preventing me from updating certain sites to Drupal 10. Thanks, Rajab!

I'm receiving the same error on a simple webform with a conditional checkbox 'Subscribe to our newsletter'.

Steps taken after installing the Pipedrive module:

• Added a API token under admin/config/system/settings
• Added a handler on a custom webform: the fields to map show up nicely
• Added a condition 'subscribe to our newsletter'. If this checkbox is checked, data needs to be sent to Pipedrive

In the logs I see:

Error saving user on Pipedrive: HTTP Response Not OK

Thanks for the quick fix Rajab!

We are getting the same error on a multidomain website:

Exception: Only local files should be passed to _locale_parse_js_file(). in _locale_parse_js_file() (line 1112 of core/modules/locale/locale.module).

I'm seeing the same error on AdvAgg 5.x and 6.x.