🇧🇪Belgium @andreasderijcke

andreasderijcke → created an issue.

Confirming MR19 as OK.
Haven't tested/applied MR18 on a real project.

Thanks for reporting!

Thanks for reporting!

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

andreasderijcke → created an issue. See original summary → .

Fixes all the warnings on my test case. Can't spot anything amiss in the MR.

andreasderijcke → created an issue.

I confirm this issue.

During debugging, the context had cache permanent (-1) which switches to '0' after adding the $url'.
The $url' does not have cache metadata, and $generatedUrl does, so from that perspective this changes makes sense.

Also, after more testing, we noticed issues when the nested paragraphs contained entity reference fields to Media, and in our case Bynder Media.
In the duplicates, the Media references disappeared saving the cloned paragraphs with the patch applied.

I didn't debug what happens in de creatDuplicate function, but it made sense that entity references to anything other than the (child) paragraphs, should not be duplicated (like nodes, users, terms,...).

For our project scope, an additional check on the entity being a paragraph, fixed the unwanted side behaviour:

          ...
          // Duplicate child paragraphs, remove when requiring 10.2+.
          // @see \Drupal\paragraphs\Hook\EntityHooks::duplicate()
-         if ($item->entity && !$item->entity->isNew()) {
+        if ($item->entity && $item->entity->entityTypeId === 'paragraph') {
              $fieldItemList[$delta] = $item->entity->createDuplicate();
          }
          ...

After checking the entity_duplicate hook, it seems that the if above could be the same as https://git.drupalcode.org/project/paragraphs/-/blob/8.x-1.x/src/Hook/En... (same check, just different way to do it and actually prefer the 'instance of' approach).

I've updated the issue title and description to emphasize the fact that the paragraph that is being cloned must be new aka not yet saved to the database.

This detail eluded myself and predecessor looking into this issue in some projects, making us doubt if the proposed patch here would fix our issue.

Without the patch, when cloning a new nested paragraph, the respective child paragraphs will be created as different revision of the same paragraph, each referring to different parent paragraph.
You can verify this when comparing the records in paragraphs_item_field_data table versus paragraphs_item_revision_field_data for given node and parent paragraphs.

With patch, you can see each child paragraph being created as separate entities.

content_lock-caching-invalidation-2919019-4.patch cannot work for 3.0.0-alpha4 due other codebase changes that are not taken into account.

Started MR97 on the 3.x to keep the current solution up to date, until something better comes up.

andreasderijcke → changed the visibility of the branch 2919019-contentlockentityoperation-doesnt-work to active.

andreasderijcke → changed the visibility of the branch 2919019-contentlockentityoperation-doesnt-work to hidden.

andreasderijcke → changed the visibility of the branch 2919019-contentlockentityoperation-doesnt-work to hidden.

andreasderijcke → created an issue.

apmsooner → credited andreasderijcke → .

Subsection added to the install instructions in the README.

Hope this is clear enough, without diving too much in the potential risks, which all depend on the setup, project etc etc anyway.

True, but this module clearly has a history concerning that part, so you might want check why this was done.
Beside, if you clearly know what needs to be done, why don't you provide the solution?

FYI: the composer file was removed intentionally by maintainer: https://git.drupalcode.org/project/varnish_purge/-/merge_requests/12/dif...

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

"This is not a bug, it's a feature".

From the module page, second paragraph:

Project name and module name
Because of some bad naming in the start - the project name is varnish_purge, but the module itself is called varnish_purger. Sorry for that, but it's hard to move namespace after you have registred one.

You have to use

composer require drupal/varnish_purger

The proposed info file rename does not fix this, and also ignores config, schema and others files that have 'varnish_purger' in their name or namespace.

Just leave it, until there is a proper solution to fix the project name(space).

A quick workaround for the case in previous comment, would be to alter

/**
 * Implements hook_js_alter().
 *
 * Handles script files added from libraries.
 */
function klaro_js_alter(&$javascript, AttachedAssetsInterface $assets) {

  ...

  foreach ($javascript as $path => &$script) {
    if ($script['type'] !== 'setting') {
      $app = $helper->matchKlaroApp($path);
      if ($app) {
        $script['preprocess'] = FALSE;
        $script['klaro'] = $app->id();
      }
    }
  }
}

to

/**
 * Implements hook_js_alter().
 *
 * Handles script files added from libraries.
 */
function klaro_js_alter(&$javascript, AttachedAssetsInterface $assets) {

  ...

  foreach ($javascript as $path => &$script) {
    if ($script['type'] !== 'setting') {
      $app = $helper->matchKlaroApp($path);
      if ($app instanceof KlaroAppInterface && !$app->isRequired()) {
        $script['preprocess'] = FALSE;
        $script['klaro'] = $app->id();
      }
    }
  }
}

which will cause all required stuff to be loaded as normal, and might/will have some unwanted side-effects in regards to the 'Only once' option and perhaps others?

I think 💬 Possible to ignore external resources Active kind of handles the same issue, therefor added as related.

We're using the OIDC My Citizen Profile Flanders → module to add a widget that for Belgian citizens so they can login to the site using their official ID.

The issue we now have, is that this module, even though all scripts are added to service that is to be required, is still preprocessing the widget scripts to text/plain, replace them post page load.
This causes the scripts to be loaded 'too late' and the oidc_mcpf module javascript to error, because it counts on those dependencies to be loaded async, and therefor already be present.

Being able to completely ignore resources (so no script inclusion rewriting in KlaroJsCollectionRenderer either) would solve the problem, without having the other module(s) change their ways.
This is what issue 💬 Possible to ignore external resources Active comes down to as well, as I understand it.

Stumbled on this issue as well. Happy to see this already submitted with a solution.
Tested the patch on my case, works perfect.

Code-wise, I've inverted the check so we can use 'continue' and keep the code change minimal (also avoiding an additional nesting level for about 100 lines of code);

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

andreasderijcke → created an issue.

Third try is hopefully sound.

So, the problem occurred for non-float numerical fields that only have a min or max set on the field, but still have the DB restrictions applied.
In that case, changing the minMessage/maxMessage to notInRangeMessage should fix it.

Found the culprit.

The code from marksmith ( https://www.drupal.org/project/custom_field/issues/3518147#comment-16060456 🐛 Cannot set both min and max values for numeric fields Active ) does not have the problem, but in the final refactored version, adding the constraint values is done if they have a value, not if the constraint is actually set. That causes the problem if you have only a min or max constraint set and not both.

MR coming up.

Ah, clear. Thanks!

Thanks for the fast response!

One follow-up question though: What would a 'revoked key' imply for this case. A person that lost its citizenship?

andreasderijcke → created an issue.

Perhaps the resource detection can be skipped (and thus no logging) for all paths that are configured in the 'Disable Klaro! element and dont block attributed resources on following url patterns' option?

The option description states

... On these paths no resources are blocked and Klaro! will be disabled.

Which might imply the unknown resource detection is also not active, but based on the logs it is active on those paths.

Module maintainers do not always have say in whether a third party library they need (as in 'no better alternative') that is loading additional stuff from a CDN.

For example, the Bynder module → includes a widget from Bynder itself, and that uses CDN for additional stuff.
There is no way the Bynder module maintainers can change this. They can ask Bynder not to use a CDN, but will they change it (and if so, how long will it take)

Also, the inclusion is for backend only, so it feels wrong to have Bynder included in the banner for the end user, who will only see images (or files for that matter) from Bynder without addition scripts.

I think this is just an overlooked part after forking from drimage, with either part of a solution or leftover from a test.

See the MR for my proposal.

andreasderijcke → created an issue.

MR adds small change to checks for regex match if there is no full match. This allows for matching entity password forms, which use the target node id or bundle.
In case of nodes, you can use entity_access_password_password_node_*.

andreasderijcke → changed the visibility of the branch 3489447-not-working-with to active.

andreasderijcke → changed the visibility of the branch 3489447-not-working-with to hidden.

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

+1 for this.

• Users that might need to look at the reports, do not necessarily be able to change this module config.
• The other suggestion do make sense to me too.

Have applied the change on the D10.4 with the desired affect.

andreasderijcke → changed the visibility of the branch 3533214-processor-rendereditem-add to hidden.

andreasderijcke → created an issue.

andreasderijcke → created an issue.

Assuming we're talking about the new Facets as exposed filters:

Using Better Exposed Filters → you can have the facet rendered as 'Checkboxes/Radio buttons' on the filter widget. Disableing the 'Allow multiple selections' option on the facet itself, will get radio buttons.

andreasderijcke → created an issue.

Using imagemagick module 4.0.2 and ImageMagick 6, the patch needed to be slightly different. See attached.

andreasderijcke → changed the visibility of the branch 3533143-optimize-error-responses to active.

andreasderijcke → changed the visibility of the branch 3533143-optimize-error-responses to hidden.

andreasderijcke → created an issue.

andreasderijcke → created an issue.

andreasderijcke → created an issue.

In our case, we also used a dedicated linkit profile, not only to exclude Media but also to limit to certain node types and vocabularies.

I understand the choice not to support this as a feature, but perhaps this can be mentioned in the README as a 'use at your own risk' as I think it is very usefull towards content editors?

andreasderijcke → created an issue.

apmsooner → credited andreasderijcke → .

Should have been fixed in 🐛 Cannot set both min and max values for numeric fields Active .
Perhaps it customisations that are interferring. Will double check later this week.

https://www.drupal.org/project/custom_field/issues/3524259# →

andreasderijcke → created an issue.

This patch works as expected.

In combination 🐛 TypeError: Drupal\content_lock\ContentLock\ContentLock::release(): Argument #1 ($entity) must be of type Drupal\Core\Entity\EntityInterface, null given Active you can fix a 'stuck' environment without additional manual cleanup.

Ran the change on a site with the issue, it cleaned it up nicely.

I'm also in favour of adding this in addition to 🐛 Deleted entity id's on content_lock table make cron to fail Active .

I confirm that with the MR

• The view block shows up as facet source on /admin/config/search/facets
• A facet as exposed filter can be configured (Facets 3.0)

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

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

After some fiddling, I settled on adding tests against all the available opt-in's except for the next major (doesn't exists at this time) + 'abuse' the 'previous minor' to test against the latest D10.3 version as there is no opt-in variable for the 'LTS' version.

This results in testing against all current D10, current stable D11.1 and D11.x-dev.

andreasderijcke → created an issue.

MR works nicely.

+1

andreasderijcke → created an issue.

andreasderijcke → changed the visibility of the branch 3520514-referencefieldextractor-not-checking to active.