🇬🇧United Kingdom @andrew robinson

Thank you. I've tested this change and it resolves the issue for me.

andrew robinson → created an issue.

Thanks Justin. I've tested the patch and it works.

However, I'm not sure I understand which permissions are controlling this?
When I look at the layout_paragraphs module I don't see any permissions defined.

I've seen that there is a sub-module called layout_paragraphs_permissions, but I don't have this enabled.

andrew robinson → created an issue.

andrew robinson → created an issue.

andrew robinson → created an issue.

andrew robinson → created an issue.

andrew robinson → created an issue.

andrew robinson → created an issue.

andrew robinson → created an issue.

Thank you!
I approve of these new more granular permissions. I've tested and on the whole they're working as expected.
However there is one bug still that occurs unless I misunderstand your intentions with the permissions!

Scenario:
Role A is someone who creates ME templates.
Role B may not create ME templates but they are allowed to browse existing ones and they are allowed to insert them into new pages that they create.

Question: What permissions would you expect to grant to Role B?
My expectation (that may be wrong!) is that they should have:

• - Access the Mercury Editor template overview page (to browse existing templates)
• - Use Mercury Editor templates
• - View Mercury Editor template

When I give a user with role B these permissions they are able to see the list of ME templates. When they create a page they can see ME templates in the list of components to add to the page. However when they select one to add a console error is generated and the template fails to be inserted.
The console error is
POST https://my.lndo.site/mercury-editor-templates/ad19f4d251a69b4c0466f385d5d35d29/insert/1?_wrapper_format=drupal_dialog&_wrapper_format=drupal_ajax 403 (Forbidden)

I can circumvent this error by granting Role B the "Create Mercury Editor template" permission, but I don't think this is what you intended.

Further to the above:

I want to be able to give a particular role the ability to Create and Delete Mercury Editor Templates but not the ability to administer them.
At the moment this isn't possible.

If I grant the "administer mercury editor template" permission then the user can see the "Mercury Editor Templates" link on the admin/content page, but they are also able to access the settings page within the Structure menu.
If I do not grant the "administer mercury editor templates" permission then the user can not see the "Mercury Editor Templates" link on the admin/content page - even though they do have the "create mercury editor template" permission.

IF the above assertion is correct then the attached patch should resolve the issue.

Andrew Robinson → created an issue.

I found a way to consistently reproduce this error.
- Run `drush cr`
- Open the status report page (/admin/reports/status)

The error message is displayed at the top of the page, but only for the first page request after a cache clear.

I tried applying the patch from comment #2 but this resulted in:
ValueError: Array sizes are inconsistent in array_multisort() (line 64 of modules/contrib/token/src/Token.php).

The solution in my case was to look in custom modules for poorly defined tokens in hook_token_info and fix them by ensuring they all have a 'name' key.
I was able to see a list of custom tokens and any that are missing names by browsing to /admin/help/token

I am running a Drupal 10.1.6 site using Token 1.13

I understand and appreciate the reasons for closing this ticket.

In case it helps anyone stumbling across this problem in future:
I experienced this problem due to a typo in the namespace of my custom action class file.
My advice would be to check the namespace, and also to check that your class name matches the filename of your action class.

A note for anyone upgrading from D9 to D10:

The patch in this thread will enable any existing countup embeds that are in the website to continue working.

However, you should be aware that the countup button that can be added to the CKEditor toolbar will not work with CKEditor5 (at the time of writing).
When upgrading from CKEditor 4 to 5 the following message is displayed:
The CKEditor 4 button countup does not have a known upgrade path. If it allowed editing markup, then you can do so now through the Source Editing functionality.

There is an open ticket for making countup compatible with CKEditor 5 here: https://www.drupal.org/project/countup/issues/3331244 💬 Compatibily with ckeditor 5 Active

Updated patch to include fix for jQuery.once call in countup.js

Updating patch to include Drupal 10 in the core_version_requirement line of the .info.yml file.

To upgrade from Drupal 9 you can:

• Install composer-drupal-lenient ( composer require mglaman/composer-drupal-lenient )
• Add this patch to composer.json
• Create a drupal-lenient stanza in composer.json (as a sibling of the patches stanza) add this module to the drupal-lenient section.

eg.

        "drupal-lenient": {
            "allowed-list": [
                "drupal/countup"
            ]
        }

Thanks @a.dmitriiev.
I've switched over to patch #38 on my Drupal 10.1.0 site using Paragraphs 1.15.0.
When I try to edit a page that contains paragraphs I get the following error:

TypeError: Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher::dispatch(): Argument #1 ($event) must be of type object, string given, called in /app/docroot/modules/contrib/paragraphs/src/Entity/Paragraph.php on line 468 in Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch() (line 89 of core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php).

It appears that in Drupal 10.1 the event_dispatcher service uses the dispatch function from ContainerAwareEventDispatcher.php, which expects $event as the first parameter.
Ref. https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Component%21Even...

I've attached an updated version of patch #38 that switches around the parameters in the two calls to the dispatch function.

I agree with the intention to make these options consistent.
However, a user with only Edit permission for a content item is able to deselect the "Create new revision" checkbox when editing the item
so the statement
Users with the "Administer content" permission will be able to override this option.
is misleading.

The same applies for media.

I propose changing the descriptions for the "Create new revision" options to:
Automatically create new revisions. This option can be overridden when content is edited.
and
Automatically create new revisions. This option can be overridden when media is edited.

I agree. I've updated the proposed resolution with Chris' suggestion.

@laurab Would you mind outlining the solution you settled upon with for achieving this?

The Profile module provides a configurable entity that is attached to user records. By creating multiple profile types you can associate different fields with different user types.

I'm not 100% sure about the second sentence. My aim was to convey what I assume to be a common use-case for the module, but it might sound a bit restrictive.

Summarizing this module in <200 characters is difficult!

A alternative suggestion for a more generic description could be:

The Profile module expands user profiles by allowing administrators to collect additional information with custom fields, enhancing user data management and personalization options.

vladigor@gmail.com → created an issue.

I think this is unlikely to be a Drupal Core problem and more likely to be caused by a contrib module that has either not been updated to its newest version, is not yet compatible, or has failed to have its database updates applied successfully.

I experienced this problem myself on a Drupal 10 upgrade today. The error message appeared when I visited a node edit page.

My first suggestion is that you run drush updatedb.

If there are no db updates / that doesn't solve the problem then check your contrib modules are up to date.
composer update will update modules within their current major version, but if a new major version exists you may need to composer require the new one.

In my particular case, neither of the above helped. I did notice however that the pathauto module had a ticket a while ago about this issue. ( https://www.drupal.org/project/pathauto/issues/3222776 → ).
To test if this was the cause I disabled the module on my local copy of the site and the error went away. I re-enabled the module and the error was still gone. This suggests to me that at some point my site failed to apply an update hook from pathauto. After reverting to a backup database I boiled the fix down to just needing to run pathauto_update_8108()

The function can be run from drush directly : drush eval 'include_once(DRUPAL_ROOT . "/modules/contrib/pathauto/pathauto.install"); pathauto_update_8108()'

I believe these patches fail in Drupal 10 sites with the error:

Uncaught Error: Class "Symfony\Component\EventDispatcher\Event" not found in modules/contrib/paragraphs/src/Event/ParagraphSummaryAlterEvent.php:4

According to vendor/symfony/event-dispatcher/CHANGELOG.md, in Symfony 5.x

Based on this I think the use statement at the top of src/Event/ParagraphSummaryAlterEvent.php should be updated
from
use Symfony\Component\EventDispatcher\Event;
to
use Symfony\Contracts\EventDispatcher\Event;

for sites that are based on Symfony 5 or above.

Thank you.

My use case isn't entirely typical.  It relates to compliance and the storage of data in a secure vault in case it is required in a legal case some years in the future.   

To achieve this I set up an S3 bucket and turned on Object Lock and set Compliance mode with a retention period of 7 years.  This prevents any file added to the bucket from being deleted or overwritten for 7 years. 
My Drupal application takes a form submission, renders it as a PDF and then saves the PDF into the bucket using s3fs.

Based on your advice I've tried out the hook_s3fs_upload_params_alter hook.   Unfortunately they are executed after the validate routine so never get invoked due to validate failing.  However, after temporarily bypassing the validate function I can see the hook does run and setting   $upload_params['AddContentMD5'] = true; does resolve my problem.

So here's the solution in my local copy:

1.  I've added a new setting into settings.php:    $config['s3fs.settings']['object_lock'] = true;

2.  I've added a hook into my module:

function mymodule_s3fs_upload_params_alter(array &$upload_params) {
  $config = \Drupal::config('s3fs.settings')->get();
  if (isset($config['object_lock'])) {
    $upload_params['AddContentMD5'] = TRUE;
  }
}

3. I've patched the validate function in S3fsService.php as follows:

diff --git a/src/S3fsService.php b/src/S3fsService.php
index 97c22f8..464368a 100644
--- a/src/S3fsService.php
+++ b/src/S3fsService.php
@@ -160,6 +160,11 @@ public function validate(array $config) {
         $putOptions['CacheControl'] = $config['cache_control_header'];
       }

+      // An MD5 header is required for files stored in an object lock enabled bucket.
+      if (!empty($config['object_lock'])) {
+        $putOptions['AddContentMD5'] = true;
+      }
+
       $s3->putObject($putOptions);
       $object = $s3->getObject(['Bucket' => $config['bucket'], 'Key' => $key]);
       if ($object) {

vladigor@gmail.com → created an issue.