🇫🇷France @GoZ

GoZ → created an issue.

GoZ → created an issue.

GoZ → created an issue.

Constructor has been removed in 3.0.2 and logger is loaded in create(). So 3.0.2 fixes the issue.

GoZ → created an issue.

GoZ → created an issue.

GoZ → created an issue.

@catch i figured out where i was wrong.

I misconfigured my Drupal settings for the nginx+php-fpm (no cache).

I update the blog post to fix this.

I make tests again as anonymous with all caches disabled (Drupal + twig) to enforce calculation.
And another as anonymous with all caches enabled.

Jmeter has been configured to launch only one thread at time, with no delay between two threads.

Summary is :

No cache :
NGINX+PHP-FPM : ~ 202ms
FrankenPHP : ~ 226ms

Cache enabled :
NGINX+PHP-FPM : ~ 5.43ms
FrankenPHP : ~ 6.36ms

Otherwise, something is still wrong since there is a big difference between the time with/without cache and the number of request with/without cache.

@catch i agree with you, the number of calls does not reflect the difference of response time.
As explained in blog post, both tests are done with minimum configuration :

- a fresh drupal installation with default umami profile.
- no differences between the two jmeter scenarios

I don't have dedicated servers to make real tests, but i can at least confirm i tested in the same way both stacks.
I'm not expert about jmeter, so if someone want to improve those tests, feel free to contribute !

Tests have been done with anonymous users, requesting home page.

If it can help pushing this issue, here is some quick perf tests of Drupal with frankenphp : https://www.iosan.fr/en/blog/what-does-frankenphp-and-drupal-have-say-ab...

Summary is :
NGINX+PHP-FPM : ~ 191ms
FrankenPHP : ~ 10ms

Extra-information : we should use drupal mechanisms path() or ur() instead of hard href so url can be altered by Drupal core, contrib and custom modules.

GoZ → changed the visibility of the branch 11.x to hidden.

GoZ → created an issue.

Looks like a duplicate of 🐛 AJAX pager doesn't work with exposed filter which has a default value Fixed

I confirm this patch help when we have to refresh more than the two hard coded parts.
This helps me on https://www.drupal.org/project/commerce_shipping_mondial_relay/issues/34... 🐛 Refresh Mondial relay pane on shipping method changes Active .

Another solution would be to dispatch an event on ajaxRefresh which could allow to alter ajaxResponse.

GoZ → created an issue.

Thanks guys

I'm working on it, you can find 2.0.x

Can you confirm you still have the issue with Drupal 9.1|10.x and 2.0.x version of the module ?

I cannot reproduce with 10.x and 2.0.x version of the module

1. +++ b/js/select-all.js
   @@ -0,0 +1,15 @@
   +        if ($('.check-' + value).prop('checked')) {
   

   Use context in jquery selection to not parse all the dom, but only provided context from behavior

2. +++ b/js/select-all.js
   @@ -0,0 +1,15 @@
   +        $('#checkall-' + value).click(function () {
   

   Use once() to avoid multiple calls if behavior is reloaded.

I move this issue to 2.0.x version since 8.1.x is not supported anymore

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

8.x-1.0 is not supported anymore since we have to move on drupal core 9.x/10.x.

I cannot reproduce issues with media on 2.0.x with drupal core 10.x. Can you confirm the status of this issue please ?

Thanks all of you

+++ b/src/Plugin/migrate/source/EntityStagingJson.php
@@ -20,23 +20,23 @@ class EntityStagingJson extends SourcePluginBase {
+ protected $inputPath;

Variable should not be renamed, there is no rules on that on phpcs

+++ b/src/Plugin/migrate/source/EntityStagingJson.php
@@ -20,23 +20,23 @@ class EntityStagingJson extends SourcePluginBase {
+ protected $stagingDirectory;

My bad, there is lowerCamel rule

Move to 2.0.x, since 8.x-1.x will not be supported anymore

I'm working on this to commit fixes

1. +++ b/src/EventSubscriber/EntityStagingProcessEntityReferenceFieldSubscriber.php
   @@ -55,27 +55,27 @@ class EntityStagingProcessEntityReferenceFieldSubscriber implements EventSubscri
   -          $dependencies[] = $migration;
   ...
   -      // Spacial case for entity types with bundle but without bundles in field settings
   

   This should not be changed, there is nothing to do with phpcs reports

2. +++ b/src/Plugin/migrate/source/EntityStagingJson.php
   @@ -20,23 +20,23 @@ class EntityStagingJson extends SourcePluginBase {
   +  protected $inputPath;
   

   Variable should not be renamed, there is no rules on that on phpcs

3. +++ b/src/Plugin/migrate/source/EntityStagingJson.php
   @@ -20,23 +20,23 @@ class EntityStagingJson extends SourcePluginBase {
   +  protected $stagingDirectory;
   

   Variable should not be renamed, there is no rules on that on phpcs

I had already fixed it in a MR, and we have to make it in a special 9.1+ core version, but thanks for the effort @Shreya.

GoZ → created an issue.

Thanks, both of you

Nice catch, thanks @stefan

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

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

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

In fact, making basic implementation for revision could work for simple cases, which is better than the current state where module does not deal with revisions and content moderation.

However, if we make such a thing, we'll potentially break other people plugins witch are querying entities, not revisions.

This is interesting, i don't close this issue yet, let me think about it

Thanks @Giuseppe87

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

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

Monitored Room 1 | 3.8 The Lounge

Monitored Room 2 | 3.7 The Studio

Scheduling and revision is a complex thing...

We should talk about uses cases because i already see issues about basing schedule jobs on revisions.

1/ Node is published (rev1)
2/ Revision 2 (rev2) is created unpublished with publication date from 2023-10-19 to 2024-10-19
3/ Revision 3 (rev3) is created unpublished with publication date from 2023-10-25 to 2024-10-19
4/ Revision 4 (rev4) is created unpublished with publication date from 2023-10-30 to 2024-10-19

Only rev1 is published, Revisions 2 to 4 are work in progress.

How can we know which revisions we can trust and deal with ?

Commited on duplicate #3184191. Can you confirm the commit solve your issue @stefan.korn ?

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

I'm done now, but open to discuss about changes if needed.

In Readme, in the "Main file" section, we can read :

Drupal.eu_cookie_compliance = Drupal.eu_cookie_compliance || function () {
   (Drupal.eu_cookie_compliance.queue = Drupal.eu_cookie_compliance.queue || [])
   .push(arguments)
};
<code>
This ensures that a script from another module (which either should not use
`defer`, or should be placed AFTER the main script in the HTML) will be able
to access the Events from the main script and perform actions.
</cite>

Except that adding the code of the "Second file" section :

<code>
var postPreferencesLoadHandler = function(response) {
   console.log(response);
   window.cookieResponse = response;
};
Drupal.eu_cookie_compliance('postPreferencesLoad', postPreferencesLoadHandler);

Will display the error :

Uncaught TypeError: Drupal.eu_cookie_compliance is not a function

After adding "defer" attribute to script, error no more display and code is called as expected.
But i don't think putting the script in defer is the better solution.

Looking at https://git.drupalcode.org/project/eu_cookie_compliance_gtm/-/blob/2.x/j..., i can see Drupal.eu_cookie_compliance is defined before using it in our custom script. Adding same piece of code make it works without having to definer script as defered.

  // Sep up the namespace as a function to store list of arguments in a queue.
  Drupal.eu_cookie_compliance = Drupal.eu_cookie_compliance || function() {
    (Drupal.eu_cookie_compliance.queue = Drupal.eu_cookie_compliance.queue || []).push(arguments)
  };

In "Second file" section, i think we should add the following informations :

To use Drupal.eu_cookie_compliance in you custom code, don't forget to instanciate it putting this code in top of your script :

  // Sep up the namespace as a function to store list of arguments in a queue.
  Drupal.eu_cookie_compliance = Drupal.eu_cookie_compliance || function() {
    (Drupal.eu_cookie_compliance.queue = Drupal.eu_cookie_compliance.queue || []).push(arguments)
  }; 
<code>

And we can take advantage to add the recommended <code>(function(Drupal) {})(Drupal)

syntax on the example.

Example: reading the cookie preferences after submission + save it
somewhere else for later use
```
(function(Drupal) {
// Sep up the namespace as a function to store list of arguments in a queue.
Drupal.eu_cookie_compliance = Drupal.eu_cookie_compliance || function() {
(Drupal.eu_cookie_compliance.queue = Drupal.eu_cookie_compliance.queue || []).push(arguments)
};

var postPreferencesLoadHandler = function(response) {
console.log(response);
window.cookieResponse = response;
};
Drupal.eu_cookie_compliance('postPreferencesLoad', postPreferencesLoadHandler);
})(Drupal);
```

Warning: As this type of code only needs to be called once, it shouldn't be necessary to add it as a Drupal.behavior.

I'd like to reopen for documentation improvements.

I'll work on it this week during the Drupal Con Lille.

I finally find out how to make it works.

I think it works "as designed", but documentation should be updated.

Event should be defined out of behaviors. Thinking about it, this should never be in behaviors, because it has to be called only once at page load, no need to reattach something with behaviors.

var _paq = _paq || [];
(function($, Drupal, drupalSettings, _paq) {
  Drupal.eu_cookie_compliance('postPreferencesLoad', function(){
    if (Drupal.eu_cookie_compliance.hasAgreed('audience')) {
      _paq.push(['setConsentGiven']);
      _paq.push(['setCookieConsentGiven']);
    }
  });
})(jQuery, Drupal, drupalSettings, _paq);

And we need to call this javascript with defer option so it will be called after eu_cookie_compliance.js script.

custom_module.matomo:
  js:
    js/matomo.js: { attributes: { defer: true } }
  dependencies:
    - matomo/matomo
    - eu_cookie_compliance/eu_cookie_compliance

GoZ → created an issue.

GoZ → created an issue.

Re-roll patch #13 on latest version after 2.0.0-beta4 release.

May be this patch could be merged to fix common cases, then work on #11 specific issues.

GoZ → created an issue.

I have the same issue. Here is my way to reproduce.

1/ Create a term in a vocabulary synced with menu.
2/ Set term as enabled.
3/ Menu item is created and enabled.
4/ Disable term
5/ Menu item is still enabled

There is two issues in code :
1/ In TaxonomyMenu::buildDefinition(), menu link should take care of term status.

// There is no enabled key here.
$link += [
      'id' => $this->buildMenuPluginId($term),
      'title' => $term->label(),
      'description' => $term->getDescription(),
      'menu_name' => $menu_id,
      'expanded' => $this->expanded,
      'metadata' => [
        'taxonomy_menu_id' => $taxonomy_menu_id,
        'taxonomy_term_id' => $term_id,
      ],
      'route_name' => $term_url->getRouteName(),
      'route_parameters' => $term_url->getRouteParameters(),
      'load arguments'  => $arguments,
      'parent' => $menu_parent_id,
      'provider' => 'taxonomy_menu',
      'class' => 'Drupal\taxonomy_menu\Plugin\Menu\TaxonomyMenuMenuLink',
    ];

2/ In update, TaxonomyMenuMenuLink::updateLink(), is called with $persist at false. When term is updated, some updates are passed to menu link like title or weight changes, but not status.

I'll make a MR to make menu link follow term status changes.

I have the same issue. I also use advagg, but i find the issue is not caused by advagg, but even Drupal js aggregation make the javascript error.

To reproduce :
- Install Drupal 9.5.x
- Install Token module and another module using tokens (Metatag, rabbit hole etc)
- Disable Drupal JS Aggregation
- Go to page where token link with tree widget is displayed (your node form with metatag field or node form with rabbit hole settings available)
- No errors, in console. If you have a wysiwyg for example, everything works fine.
- Enable Drupal JS Aggregation
- Go back to your node form
- JS error display in console and wysiwyg is no more available.

The patch #2 does not solve the solution.

May be the reason is: when we aggregate js, some other scripts add "use strict" instructions, but when strict mode is enabled, the keyword this is undefined in a function invocation in strict mode.

The MR replace 'this' by 'window' global variable to make this available in strict mode.

I make this issue critical since it breaks all javascripts execution when js aggregation is enabled.

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

@emmguyot can you create another issue for your case, so it can be resolved in it?
This issue is relative to twig update and loadTemplate method.

Thanks

Merge request use #14, but re-roll for 2.x

This is still the case for 8.x-2.x, but patch does not apply

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

GoZ → created an issue.

Thanks @acouch

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

Thanks @Sonal Gyanani

Thanks all, that was fast !

I reproduce in both contexts : after updating from 9.5.3 to 9.5.4, and after installation to 9.5.4 with existing config.

Steps to reproduce :
- Have an installed drupal at 9.5.3
- Be sure configuration is up to date : drush cex -y
- Update to 9.5.4 :

composer update -W drupal/core-recommended:9.5.4
drush updb -y
drush cex -y

Permissions in user.role.authenticated.yml is :

 permissions:
  - 'access administration pages'
  - 'access content overview'
  - 'access contextual links'
  - 'access files overview'
  - 'access toolbar'
  - 'access tour'
  - 'administer url aliases'
  - 'create article content'
  - 'create page content'
  - 'create terms in tags'
  - 'create url aliases'
  - 'delete article revisions'
  - 'delete own article content'
  - 'delete own page content'
  - 'delete page revisions'
  - 'edit own article content'
  - 'edit own comments'
  - 'edit own page content'
  - 'edit terms in tags'
  - 'revert all revisions'
  - 'view all revisions'
  - 'view own unpublished content'
  - 'view the administration theme'

- I commit this in git to see differences when i'll remove the permission and export again.
- Remove 'edit own comments' from /admin/people/permissions
- Export config : drush cex -y
- git diff on user.role.authenticated.yml is now :

 permissions:
-  - 'access administration pages'
-  - 'access content overview'
-  - 'access contextual links'
-  - 'access files overview'
-  - 'access toolbar'
-  - 'access tour'
-  - 'administer url aliases'
-  - 'create article content'
-  - 'create page content'
-  - 'create terms in tags'
-  - 'create url aliases'
-  - 'delete article revisions'
-  - 'delete own article content'
-  - 'delete own page content'
-  - 'delete page revisions'
-  - 'edit own article content'
-  - 'edit own comments'
-  - 'edit own page content'
-  - 'edit terms in tags'
-  - 'revert all revisions'
-  - 'view all revisions'
-  - 'view own unpublished content'
-  - 'view the administration theme'
+  0: 'access administration pages'
+  1: 'access content overview'
+  2: 'access contextual links'
+  3: 'access files overview'
+  4: 'access toolbar'
+  5: 'access tour'
+  6: 'administer url aliases'
+  7: 'create article content'
+  8: 'create page content'
+  9: 'create terms in tags'
+  10: 'create url aliases'
+  11: 'delete article revisions'
+  12: 'delete own article content'
+  13: 'delete own page content'
+  14: 'delete page revisions'
+  15: 'edit own article content'
+  17: 'edit own page content'
+  18: 'edit terms in tags'
+  19: 'revert all revisions'
+  20: 'view all revisions'
+  21: 'view own unpublished content'
+  22: 'view the administration theme'

May be there is a better solution, but set the code from Role::preSave back solve it right now.

Let see later why schema update from 🐛 Role permissions not sorted in config export Fixed does not solve this as expected.

I finally reproduce again.

This will occurs only if you remove a permission from a role (and then export configuration with drush).

Forget about this, i restart from previous dump, run the update again and cannot reproduce

After updating another project from 9.5.3 to 9.5.4, i don't reproduce the issue.
Really strange

Move it to critical since it will regenerate all permissions roles files of existing projects, and will need a rollback.

Found this similar issue for 10.x to
🐛 user_update_10000 causes exported permissions to be numerically keyed Closed: duplicate

Setting back the following code solve the issue :

\Drupal\user\Entity\Role::preSave:

    if (!$this->isSyncing()) {
      // Permissions are always ordered alphabetically to avoid conflicts in the
      // exported configuration.
      sort($this->permissions);
    }

Still needs to see why it has been removed. Seems something doesn't work as expected after 🐛 Role permissions not sorted in config export Fixed changes.

GoZ → created an issue.

I have a similar issue, except I still don't understand why.
I don't use webform, it's a boolean field in a node, displayed by boolean_checkbox form widget, with display_label option to 1.

In my case, i can see debugging gin_theme_suggestions_input_alter() function that #error_no_message exists and is TRUE.

Reading #2643012: Add property to identify if checkbox/radio is in group of checkboxes/radios → , checkboxes group is can be tested thanks to #error_no_message key AND #weight. After few tests and reading \Drupal\Core\Render\Element\Checkboxes, it seems checking #weight is float is more relevant than #error_no_message... but not the solution either.

Here is an example of a form. I should have toggle checkbox for fields, but none is displayed :

• Publié (published status)
• My checkbox (a boolean field)
• Sidebar > Create new revision
• Sidebar > Menu settings > Provide a menu link
• Sidebar > Simple XML Sitemap > Regenerate all sitemaps after hitting Save
• Sidebar > URL alias > Generate automatic URL alias

Then checking #weight is not float to use template suggestion :

function gin_theme_suggestions_input_alter(array &$suggestions, array $variables) {
  if ($variables['element']['#type'] === 'checkbox') {
    // Way to identify if checkbox is in a checkboxes group
    // as Drupal doesn't provide one yet (see #2643012)
    if (!is_float($variables['element']['#weight'])) {
      $suggestions[] = 'input__checkbox__toggle';
    }
  }
}

Finally, removing condition to always use template suggestion :

function gin_theme_suggestions_input_alter(array &$suggestions, array $variables) {
  if ($variables['element']['#type'] === 'checkbox') {
    // Way to identify if checkbox is in a checkboxes group
    // as Drupal doesn't provide one yet (see #2643012)
//    if (!is_float($variables['element']['#weight'])) {
      $suggestions[] = 'input__checkbox__toggle';
//    }
  }
}