🇧🇪Belgium @andreasderijcke

Tweak added. Didn't think of it, even having used it before.

andreasderijcke → changed the visibility of the branch 3508066-error-call-to to hidden.

andreasderijcke → created an issue.

I made the checks a bit more specific, as it didn't suffice for Layout Builder. The getValue() was still reached.

It would be even better if we could check the object class instead of presence of the getValue() method, but I don't know which one is expected.

andreasderijcke → made their first commit to this issue’s fork.

@stephencamilo The require-dev dependencies are only for development of the module and running tests that (might) test support and cooperation with those modules.
Those modules are not mandatory for this module to work, so it is correct that they are not listed in the info.yml file. As far as i can tell, both the info.yml and composer.json file are fine as they are.

Which features are you using that are causing a problem?

Still applies in combination with 🐛 MailjetConfigurationAccessCheck triggers on all routes Active .

I want to raise this to critical, because this problem can make a website completely inaccessible (access denied on all routes)

AccountInterface instance can have no ID in valid use cases, even though the AccountInterface does not say so (but should).

A good example is the Search API RenderedItem processor: a User(Session) is created on the fly to render and index entities for that user's role. This user is never saved, thus has no ID.
See https://git.drupalcode.org/project/search_api/-/blob/8.x-1.x/src/Plugin/...

Should the AccountInterface get updated to reflect the fact that the ID can be NULL, it still needs to be handled here.

Thanks!

No, was just a test to see if changing the issue credits assignment would stick, as a thank you for the work done.

Smart Date → is also conflicting.
One way to 'fix' this, is by increasing the weight of the module in core.extensions.yml, not without risk however.

• The empty value (86401) was missing. I've introduced a static function to check for this.
• Constraint check added too.
• Rebase with current 2.x

There more potential for reuse of code parts.
Also, the empty value 86401 appears both as int and string across the module. I recommend streamlining this.

andreasderijcke → made their first commit to this issue’s fork.

See MR for dependency declaration correction. Can't guarantee this will fix the issue.

I've tried on D10.2, D10.3, D10.4.

composer require "drupal/social_media_platforms:^1.0.1"

always works,

composer require "drupal/social_media_platforms:^1.0.2"
always results in the error.

I think this originates from the dependency declaration in the info.yml, which is incorrect:

dependencies:
  - 'block:block'

should be

dependencies:
  - 'drupal:block'

I've never seen mistake here bubble to composer, but since there is no composer.json in the module, this seems the most likely source of this problem.

andreasderijcke → created an issue.

Surprised to find out this works without issue.

Just need to find a why make this configurable :D

Still a problem for 2.0.0-alpha5 in combination with

1. core 10.3.x
2. views_bulk_operations → 4.2.7 (i know it's not the recommended version anymore)

📌 Refactor the JavaScript for the widget to use the once library Needs review fixes this problem as far as I could reproduce and test it.

@max.valetov Can you check if this is the case for you too?

I've updated the script to

1. Apply all the initialisation and event handler binding per slot/row instead of the entire table at once. This makes sure new rows added by Ajax get the required processing. The 'once' at field level was blocking this.
2. The striping fix was kept at field level, but it just occurs to me that I didn't check if that needs to be rerun after an exception is added, or when using the list widget.

Also
if ($nextTr.is(':hidden')) {
didn't work anymore for some reason, so I changed it to
if ($nextTr.hasClass('js-office-hours-hide')) {
which seems to have the same effect as far as I can tell.

I've updated the script to

1. Apply all the initialisation and event handler binding per slot/row instead of the entire table at once. This makes sure new rows added by Ajax get the required processing. The 'once' at field level was blocking this.
2. The striping fix was kept at field level, but it just occurs to me that I didn't check if that needs to be rerun after an exception is added, or when using the list widget.

Also
if ($nextTr.is(':hidden')) {
didn't work anymore for some reason, so I changed it to
if ($nextTr.hasClass('js-office-hours-hide')) {
which seems to have the same effect as far as I can tell.

andreasderijcke → changed the visibility of the branch 3314345-integrate-with-encrypt to hidden.

I forgot the exception case, that is still broken.

After merge of the changes made up until 1.19, there was not much left but swapping out the $(document).ready with the once().

That, also seems to fix 🐛 Additional slot row disappears after value change when used in nested paragraphs Needs work . I tested with a field in

1. Tabs
2. Details
3. A Paragraph
4. A Paragraph in Details

andreasderijcke → made their first commit to this issue’s fork.

Getting 📌 Refactor the JavaScript for the widget to use the once library Needs review fixed first might make fixing this easier, if only to avoid a merge hell.

This does occur in other nested situations too, when using field_group (for example) to put the field in:

- details element
- tabs
- ...

Tested on the last DEV commit at moment of writing.

Will try to update the patch (or have a colleague do it), as it doesn't apply on the last DEV commit.

Voila, released. Thank you for the nudge.

andreasderijcke → changed the visibility of the branch 3474344-argumentcounterror-too-few to hidden.

Had fix already in dev branch, just didn't come around to release it. Will use this to do it now.

This needs more work. Previous patch causes fatal error and does not cover all implications of the changed variable type.

@sarwan_verma Why do you create a patch while there is already a MR present?

Also your patch claims Drupal 11 compatibility for this module, which is not the subjet of this issue and obviously was not tested, as #3438029 is a result of incompatibility with the updated dependencies. There might be even more, so let us stick to making sure D10 compatibility is fully covered.

Because #3438029 will arise if you use the proposed MR and needs more testing on its own, I've marked it as a child issue of this one.

The new permission definition to allow access to provider config alone, somehow got lost.
The intention was to allow certain roles to manage these, without access to all module config. Therefor, I'm keeping the provider admin permission to both this permission and the general module admin permission.

Thanks for posting!

Ah, this is a result of new feature in paragraphs 1.18 → from 2 weeks ago.

andreasderijcke → made their first commit to this issue’s fork.

Works well for me, on Drupal 10.3.1 with Facets 2.0.7.

I did make a copy and removed the <strong> occurrences.
I suggest using a template instead of Markup, or an option to controle wrapping of the label in <strong> or not.

Current state just make sure the 'Empty facet behavior' selection is respected.

andreasderijcke → changed the visibility of the branch 3465494-daterangewidget-not-respecting to active.

andreasderijcke → changed the visibility of the branch 3465494-daterangewidget-not-respecting to hidden.

andreasderijcke → created an issue.

As far as I understand, this is default facet behaviour. Facets are to offer filter options based on the shown results.
If you want a date selection regardless of the shown results, an exposed filter is the way to go.

However, 🐛 Date range facet values don't appear in Facets Summary Needs review offers a patch to be able to allow the active date range facets to be shown in the facet summary, which offers a way out of situation for the end-user.

+1 to make this configurable.

The change make sense (security, and thus access denied, by default etc), but if you have many nodes of certain type and only a few with restrictions, this change has enormous impact.
The update hook vapn_update_9000 doesn't seem to take nodes without vapn restrictions into account.

This behavior is works as designed for version 3.x.
From the module page:

- In previous version, if you don't specify a role in your node, by default it will show it for all users. In version 3, it will now only show it to administrator.

I'm closing this in favour of ✨ Add a toggle to keep using 2.x default behavior of allowing access for roles Needs work , which provides a similar workaround and proposes to make this default behavior configurable.

Can we please get a proper compatibility release?
In Drupal 10.3, you can't even open the settings page.

I see issues fixed in the dev branch, but it also contains new stuff that cause other fatal errors, so can't rely on that either.
Please consider fixing fixing compatibility first before introducing new stuff.

I want to help, but there are so many code issues to address (lack of Drupal coding standard application for example, best-practices, ...), on top of the new errors, I don't know where to start without running high risk of just wasting my time.

Hide patches for clarity.

andreasderijcke → made their first commit to this issue’s fork.

Instead of fixing the route, I updated the controller, because code standards.

Still present on the newer 4.0.x.

I'm raising this to 'major', as from my experience:

If you reload the page and accept the resubmission of the delete action, because you think the deletion failed, all translations and thus the node will be deleted.
This means content loss, and might even warrant 'critical'.

Patch still works for D10.2.6 on php 8.1.
The notice has turned into a warning thought.

Patch from #8 still works on 2.0.7 and fixes the issue for us.

@Sourav_Paul Some feedback:

• I'm not sure how, but you have seemed to have overwritten the first commit on the merge request with the second. Following the git commands here on on the MR itself, it should be no problem to add commits to an existing MR. Something to double check in the future.
• About the update hook, 2 aspects:
  • The convention is to keep update hooks in the .install file, not .module and follow the existing update hook numbering unless to indicate major version jumps, which is not the case here.
    So the last one was 10001, so this one becomes 10002 and not 11001.
  • Update hook code itself was good, just didn't take possible language override into account.

In anyway, thanks for helping out.

@nightlife2008, thanks for reporting and patch.

The 3.0.x branch has been unflagged as 'supported', I guess.
The alpha releases are still there: https://www.drupal.org/project/mailjet/releases/3.0.0-alpha2 → .

If would be helpful if someone fixes this, so it is clear the module is not abandoned (since there is recente activity on the dev branch).

@Sourav_Paul Are you able to add update hook too, for potential installs that already have config on the wrong config key?

If anyone can add the update hook, this can be released faster. I might not get to it before wednesday.

The merge request is agains the wrong branch. I can't fix it, probably only the author and maintainers can. Can't find an option to start new MR from the same fork either.

Setting the 2.x branch as default might prevent mistakes like this.

@jonathan1055, @smustgrave Can anyone of you look into this?

Patch from the MR diff also works on 1.4.0.

andreasderijcke → created an issue.

andreasderijcke → created an issue.

andreasderijcke → created an issue.

I confirm the issue. The proposed solution works for us.

andreasderijcke → created an issue.

With "the attributes for CookiePro", I'm not entirely sure what you need, but I guess the info is on this page: https://my.onetrust.com/s/article/UUID-71e7d0a8-03d8-e272-e683-72cadded2ecf

If you need the exact consent categories (like 'C0004'), as those can be changed in CookiePro, they need to be configured in the module as well.
\Drupal\cookiepro_plus\CookiePro::getCategoryIds() will return them, keyed by the internal key constants as defined in https://git.drupalcode.org/project/cookiepro_plus/-/blob/1.0.x/src/Cooki... (CONF_CATEGORY_...).

Already fixed in the dev branch.

Set to review to get feedback on the current state.

andreasderijcke → created an issue.

andreasderijcke → created an issue.