🇧🇪Belgium @andreasderijcke

Added:

• PagedImportSyncClientBase, PagedImportSyncClientInterface
• Example client SyncClientSimplePagedImport and job type SyncClientSimplePagedImport to explain how to use it.

andreasderijcke → created an issue.

Since this is a formatter, we can't validate on input, which I forgot in the issue description.
Therefor, proposed in the MR is:

• Some regex to strip characters the wa.me URL can't handle and massage the value towards the expected format.
• Added composer.json to suggest installing telephone_validation → for actual input validation

These two combined still allow for a zero between the country code and actual number, but that does not seem to be a problem for Whatsapp.

After reviewing and comparing the pipeline jobs and results with other modules, it turns out that

• OPT_IN_TEST_PREVIOUS_MAJOR
• OPT_IN_TEST_NEXT_MAJOR

are only useful if the module has unit tests. Otherwise, these will just trigger a composer install with that major version, which will succeed anyway if there is no composer requirement restriction for core.

andreasderijcke → created an issue.

andreasderijcke → created an issue.

andreasderijcke → created an issue.

Added a first proposal for views filter for TimeRange field, as extend on the core numeric filter:

• Scrapped the regex operations, as they make no sense with time input.
• The 'is empty' operation does not work if there is no field record at all, see comment in code.
• Definitely needs more work and testing.

In my case it's a view of nodes with paragraph having the timerange field.

While writing this down, I realise I've been confusing the 'from' and 'to' input of the between filters with the 'from' and 'to' from the TimeRange field, and the filter would just as well work on the regular Time field.
If that's true, then rename of the filter class is recommended.

andreasderijcke → changed the visibility of the branch 3029652-add-functionality-to to active.

andreasderijcke → changed the visibility of the branch 3029652-add-functionality-to to hidden.

andreasderijcke → changed the visibility of the branch 3029652-add-functionality-to to hidden.

I've added the file with following variables overwritten:

• SKIP_ESLINT: as the module does not have any JS.
• OPT_IN_TEST_PREVIOUS_MAJOR: to test against D10 too (at this moment)
• OPT_IN_TEST_NEXT_MAJOR: to test against D12 as soon as the branch is started.

Also added the .cspell-project-words.txt file using the artifacts from the CSpell run.

andreasderijcke → created an issue.

I cannot reproduce the case, but the additional check makes sense and should not break anything, in contrary.

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

That patch makes indeed sense.

I'm just wondering if there are other situations where the current (content) language will not match entity (translation) being edited or created.

In my language (detection) setup, the $entity->getTranslation() is returning the default translation of the entity because of the fallback logic in \Drupal\Core\Entity\EntityRepository::getTranslationFromContext().
Any module affecting this fallback logic, could indeed lead to different result.

@swentel: What's the context of your case?
Inline entity form perhaps?

Ah, sure. I guess "if interface and content language differ" is indeed to vague.

Something like this:

(The "Selected language" is identical for both interface and content, as-in they share the value, set to default site language).

Point is to get to active language for interface and content to differ, one way or another.
That this can happen is often overlooked, both in core and contrib. Core does not always separate interface and content properly either, many issue about that.

Just imagine, you have editors with different native languages, and they each one wants to have the interface in their own preferred language (hence the "Account administration pages" enabled for interface) but they all managed content in all available languages.

So, in my specific case, I tried to edit an existing node with custom field with only NL translation (source) while having the interface forced to EN.
In that case, the code (pre) patch would use EN as default language to load the entity in for access checking, while it might not exist (yet) in that language. The content language does return NL in that case, since we're indeed editing the entity in that language.

PS: While trying to post the commit, the issue was already set to fixed. But submitting this anyway for future reference.

I've expanded the patch, as the previous version was did non suffice on D10.4 when the widget is hidden on entity translation forms due to the field being not translatable.

Core field constraints on the field are still fired, thus blocking creation of the entity translation. In the process, access check on the field returns 'allowed' causing the field to be taken into account for validation, even though it should not.

Have not found a solution to prevent this from happening, but discovered along the way that when the widget is hidden, the field submission values contain the options and current value, which cause the field constraint validation to fail.
By massaging the field submission values, or cleaning, this can be prevented and translation submission proceed.

This solution is added to the MR, including note that it is only a workaround until a better/real fix can be found.

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

andreasderijcke → created an issue.

Different patch as MR, because I think the base check can be simplified.

In addition, the is_numeric check should not be necessary according to the return type of getDomainId(), so either the check is obsolete, or the function doc is incomplete.
As I don't have the correct answer, have flagged it as a todo.

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

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

Fix by releasing 1.1.0 → .

Thanks for reporting and the proposed solution.

I will start a new minor version for D11, as many modules do. At the time, I didn't realise this change in ConfigFormBase was this impactful.

andreasderijcke → changed the visibility of the branch 3501197-using-error-level to active.

andreasderijcke → changed the visibility of the branch 3501197-using-error-level to hidden.

andreasderijcke → changed the visibility of the branch 3501197-using-error-level to hidden.

Fix for both D11 too.

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.