eu_cookie_compliance.js states the following statuses:
Statuses:
null: not yet agreed (or withdrawn), show popup
0: Disagreed
1: Agreed, show thank you banner
2: Agreed
The merge request in this ticket only supports status 2 (agreed), but we need to support both 1 (agreed, show thank you banner) and 2 (agreed).
The default consent is handled by the google_tag module, see ✨ Additional consent mode options Active .
I tried to add a commit to the merge request, but got the "Members who can merge are allowed to add commits." error.
I've created a new patch which supports status 1 and 2, the changes of the merge request and the changes of patch #34.
Since ad_storage, analytics_storage, ad_user_data and ad_personalization are already hardcoded, I just added the suggested configuration mentioned in https://docs.osano.com/hc/en-us/articles/22469433444372-Google-Consent-M...
However I do agree this should be configurable in the advanced settings form. (not only through checkboxes, but also with a textarea where one can add custom consent items)
Patch #76 doesn't apply anymore due to conflicting tests in v2.0.8. Attaching a patch without changed tests.
Tests should be looked into, marked the issue as "Needs work".
matthiasm11 → created an issue.
Ok, no problem. Thank you both for the swift replies!
I see. Can we make the field disabled so it becomes less confusing?
Thank you for clarifying!
I misinterpreted the button "set default value" as a submit/save button for the value, since one can enter a value in the textfield above.
Maybe we should make the textfield in my screenshot disabled? - It makes no sense to allow someone to edit it.
It appears the "set default value" is only a link to another form, which contains the actual submit button from the screenshot in #2. And after clicking "update default value", it is also necessary to save the element itself with the blue save button at the bottom. So the submit button "update default value" isn't a save button, but a "go back to the form" button.
UX-wise, it would be a lot cleaner if we remove the "set default value" button, let the user enter the default value in the textfield (with the green border in the screenshot above) and let them save it using the blue "save" button at the bottom in the advanced tab. No need to open another form. This way it works the same as all other fields in the advanced (and other) tabs. Even the "clear default value" can be removed, so users can empty it themselves? After all, there isn't a "clear wrapper css classes", "clear help title" and so on... either.
What are your thoughts?
matthiasm11 → created an issue.
+1 for #179. Drupal 10.2.6 using PHP 8.2.
Changed the dialog options to match the same options set in layout_builder_browser_link_alter(). This will prevent the page from scrolling/jumping. The height option was the main issue.
After the dialog is opened, the size will be recalculated nevertheless, see 🐛 Modal height(s) are extremely large Active .
I suppose this is due to the modal not knowing how big the content in the iframe is. To be sure, the modal is made as large as possible.
See Drupal.AjaxCommands.prototype.openIframe.initialResize.
+1, thanks!
#7 working fine, thanks!
Combining the patches from #9 to generate the hash and #13 to fix the caching seems to fix the issue.
Disabling a module makes the corresponding menu item disappear, enabling the module again makes it appear again.
No console errors anymore. I've not investigated this any further.
The script attributes should be added before anything else is added. This ensures data-ot-ignore can be evaluated by autoblocking scripts, before the script is being blocked.
Thanks @nightlife2008 for debugging this!
Patch with the solution mentioned above.
matthiasm11 → created an issue.
Thank you Veronica, #4 works perfect.
+1 for patch #2.
If your using mimemail in combination with smtp, it may be worth to look into https://www.drupal.org/project/smtp/issues/3323386 🐛 Error sending e-mail: Invalid address RTBC .
Using patch #76 to have the select element instead of generating it through javascript. Works fantastic and is so much cleaner!
It is also compatible with the Chosen module (tested with 4.x), out of the box.
One remark though: it is not compatible with selecting multiple values, so in the facet config Ensure that only one result can be displayed should be set to TRUE to avoid unexpected results. Not sure how to fix this, since the page already reloads when selecting the first item, so you have no time to select the second item. (unless you do this after the page reload) Maybe we should only reload if the select element becomes unfocused AND changed AND isMultiple?
Hi
Thank you for your offer. This module already contains a stable release for Drupal 10 and there are no open issues (only 1 feature request).
When I look at your profile, you indeed have a lot of credited commits and modules mentioned there, but most of the commits are trivial code clean ups. I advise you to fix the issues and create stable releases (including security advisories) for all your co-maintained projects first.
Sending me a DM within the minute you've created this issue only adds to the intrusive feeling.
Have a nice day, kind regards,
This one works, thanks!
Patch #31 doesn't give the desired result.
The image style preview page has an image of 800x600. When applying "Focal Point Scale and Crop 1400×1000 - Upscaling: Don't upscale but still crop", the image is still upscaled to 1400x1000, while I would expect it to return the original image (800x600).
matthiasm11 → created an issue.
That was the aim indeed, thanks to @klaasvw it is covered now.
Apparently, security advisory is only possible if I contribute some big modules first. I therefore added a colleague who has more permissions then I do as maintainer. Security advisories is enabled.
Ok, thank you for your time. I'm closing this ticket.
It's a bummer tiny modules can't get security advisory unless I write a big module first.
Thank you for your reaction. Unfortunately, this is currently the only contributed module.
I do have credit on almost 50 issues:
https://www.drupal.org/u/matthiasm11 →
Would it help if another verified developer would vouch for me? (we are developer colleagues for over 9 years)
I've made an application for this: #3395917: [2.1.x] Block Visibility Conditions →
matthiasm11 → created an issue.
As stated on the project page:
It keeps security in mind by using Drupal's private file system to store those temp .zip files. Using the public file system may result in private files being leaked.
I had the same issue. The creator of issue https://www.drupal.org/project/media_oembed_control/issues/3388686 🐛 Exception thrown when trying to render a remote video field Active also had the same issue.
Attached patch.
FYI: the "other issue on the controller due to a change in Symfony's Request class" is being fixed in https://www.drupal.org/project/media_oembed_control/issues/3363412 🐛 Symfony\Component\HttpKernel\Exception\BadRequestHttpException: Input value "media_oembed_control" contains a non-scalar value. Needs work .
Fixed in https://www.drupal.org/project/select_translation/issues/3176488#comment... ✨ support other translatable entities Needs review
The following things have been improved in the patch (which applies agains 2.x-dev).
- Add support for all content entities. (patch #4 only added support for nodes and taxonomy terms)
- Fix issue where the base table is used instead of the data_table (f.e. node instead of node_field_data or taxonomy_term_data instead of taxonomy_term_field_data) and keep backwards compatibility.
- Fix issue when using this filter on an entity added through a views relation.
- Add support for multiple filters in the same view, on the base table or a views relation(s).
- Add support for current content language, while keeping backwards support for current interface language.
- Add support for entities having custom entity_keys for the "published", "langcode", "default_langcode" field.
This patch also contains the fixes for the following issues, to prevent merge conflicts or git apply conflicts.
- https://www.drupal.org/project/select_translation/issues/3383945 📌 PHP 8.2 compatibility RTBC
- https://www.drupal.org/project/select_translation/issues/2867316 📌 Support content language in the selection mode Needs review
As mentioned in the previous comment, there still is a todo in FileUploadForm.php.
Thank you for creating the issue. I've added dependencies on the main module in all submodules. This fix has been released in v2.1.0.
Thank you for your work. I created a merge request (I was able to select 2.x, I'm not sure what went wrong when you tried it) and merged the MR in 2.x. It will be available with the next release.