🇫🇮Finland @vermario

Great!

One possible improvement would be to add this to the node interface instead of individual bundles.

would this be something like what happens in graphql_compose_metatags?

hi! I saw the same issue you are seeing, but with translations (another situation in which the tabledrag functionality should not be there).

I read your issue only after I found a possible fix, so I made a patch that actually does the same that you mentioned:

One solution is to update the paragraphs_preprocess_field_multiple_value_form() function to remove the correct columns from the table header and each of the rows. However, that seems fragile, as it would have to be updated again if there's another change to multiple value tables in core at some point in future.

Available in 🐛 Weight fields appear when editing a translation even if the order can't be changed Active

Your other solution would work with fields with cardinality 1, but for translations I think we still need the other fix. although, I wonder if this works only for drupal 10.2...

It seems that with drupal 10.2 the indexes of the table (both header and rows) are off by one. So this patch restores the previous functionality.

vermario → created an issue.

Hi!

I had the same issue, and this is a problem of the graphql module, not the grapql_compose one.

Development for the grapqhl module is happening on github, so I made a pull request there: https://github.com/drupal-graphql/graphql/pull/1388

You can add those changes as a patch in your composer.json like this:

            "drupal/graphql" : {
                "drupal-graphql#1323: Add check for translation (from Github)": "https://patch-diff.githubusercontent.com/raw/drupal-graphql/graphql/pull/1388.patch"
            },

For me, this fixes the problem.

hestenet → credited vermario → .

hestenet → credited vermario → .

hestenet → credited vermario → .

Here is a patch that seems to work correctly for us, done following the guide at https://www.drupal.org/node/3158256 →

At this line the .once method was called twice, but it does seem to work correctly with just one with the new method, so I went with that.

Please test! :)

vermario → created an issue.

@edmund.dunn

I noticed that in your patch you have included changes to fix these deprecation warning:

Call to deprecated method doesObjectExist() of class Aws\S3\S3ClientInterface: Use doesObjectExistV2() instead

and
Call to deprecated method doesBucketExist() of class Aws\S3\S3Client: Use doesBucketExistV2() instead

I think there are two problems with this:

1. the new method `doesObjectExistV2` has a new parameter that we should include, so just changing the name of the function won't work.
2. The parameter has to do with "delete markers" https://docs.aws.amazon.com/AmazonS3/latest/userguide/DeleteMarker.html . Supporting this could be a good improvement for the module, but we should make a separate issue for it, so we don't introduce more changes in this one, which is about having the module support drupal 10.

For these reasons, I am including a patch that leaves the deprecated methods in place, but adds your other changes.

hi! I am using Drupal core 9.5.5

The issue you are linking to is indeed fixed, and if I use a content type that has for example the body field, that is on the page when the page loads, the issue does not happen.

This ticket is however about the cases there a field with ckeditor5 is not initially there when the page loads, because it is in a paragraph form field which is initially collapsed. When the paragraph "subform" is opened, then ckeditor appears, and my suspicion is that the fix added as part of #3259380 is unable to fix the issue in this different context.

vermario → created an issue.

Fantastic! thank you for fixing this so quickly! 👍

For me it's a bit of a regression to not color the whole toolbar, since the main point of this module is to clearly differentiate between environments to prevent users changing things in the wrong environment (like deleting a section in production when they actually think they are in staging etc).

So I would also suggest to restore the styling of the full toolbar, unless there's some big technical impediment.

Hi! The patch in #2 works but it might create a fatal error in the cases where the file is not present.

This for us happens for example when working locally with a database exported from production, but without having the files.

This updated patch adds a try/catch to prevent the fatal error.

The idea is taken from another patch in the related issue https://www.drupal.org/project/imagick/issues/3018081#comment-14021982 🐛 Using a remote file scheme does not work Needs review

Here's a revised patch against the latest version of the module

Here's a version of the patch that keeps the update function in place.

Should we go with this?