I found that the changes from https://www.drupal.org/project/drupal/issues/2463753 🐛 [regression] Do not bypass route access with 'link to any page' permissions for menu links Fixed causes the performance issue.
I can see that when menuLinkCheckAccess is called it is not returning `$access_result->cachePerPermissions();` any more so the cacheContexts and cacheTags has changed from:
Drupal\Core\Access\AccessResultAllowed
#cacheContexts: array:1 [▼
0 => "user.permissions"
]
#cacheTags: []
#cacheMaxAge: -1
}to this:
Drupal\Core\Access\AccessResultAllowed {
#cacheContexts: array:3 [▼
0 => "url.query_args:auHash"
1 => "user.permissions"
2 => "languages:language_interface"
]
#cacheTags: array:25 [▼
0 => "group_content_list:plugin:group_node:blog"
1 => "group_content_list:plugin:group_node:<content_type_2>"
3 => "group_content_list:plugin:group_node:<content_type_3>"
...
]There are 23 cacheTag items coming from `group_content_list:plugin:group_node:.
Not sure if that is expected but seems to cause in issue in my case.
Thank you, I understand. There is a lot of custom code so I would say this is site specifi9c issue, and I have checked on a similar site but was not able to reproduce it there. I will roll back the group update and see if there is any change.
Profiling shows that the access checking is running on menu items (structured in a large menu) which is loading on the create node pages and group entity access is called in that call stack, so I am trying to understand if these group entity access checks were cached before and at which layer they were cached.
rick bergmann → created an issue.
I still have this issue. I see it is because for some reason Drupal is changing the ownership of the sites/default/files/js and sites/default/files/css directories back to www-data:www-data when it generates new aggregated css/js files. This is on my prod server so I need to keep aggregation enabled.
The patch in #90 🐛 Field Groups marked as required are missing red asterisk Needs work works for me on Drupal 10.3. I had to apply the config workaround to remove the duplicate asterix, however there is a scenario that doesn't work.
In 1 of my fieldgroups I have a fieldset which contains a required field. In that case there was no duplicate asterix and I had to keep the `Mark group as required...` setting enabled.
So the result is I have 2 field groups with `` and 1 field group with `` which is visually noticeable.
The patch works for me (using Claro), but the role="navigation" on the <ul> element is not a permitted aria role and fails an accessibility test.
I found it in this line of code:
return $('<ul class="tabs tabs--secondary" role="navigation" aria-label="Tabs"></ul>');
See here for permitted aria roles on a <ul> element.
Why does it have role="navigation"? Should it be removed or changed to instead of role="tablist" instead?
I had the same issue after updating from Drupal 9 to 10. I found that sites/default/files/css and sites/default/files/js had incorect ownership of www-data:www-data. I changed ownership to user:www-data to fix the issue.
@DieterHolvoet after some more testing, I see the `Publish state` dropdown appears once I have selected a schedule date, however the issue still remains when validation fails, the Publish state select field still re-renders outside of the Scheduling options section.
@DieterHolvoet I tried a different patch which does apply (the one from comment 25). Now the Publish / Unpublish state select fields are not displaying at all now. I guess they are meant to be hidden and their value should be the current workflow state, is that the case. If it is, then yes it looks like that patch fixes the issue.
@DieterHolvoet Thanks for the recommendation, I tried to install that MR as a patch but it fails to apply on version 2.0.0-beta2. I can add a comment in that issue with the errors if that's helpful?
Rick Bergmann → created an issue.
I ran into this issue and can confirm the patch works for me.