🇺🇸United States @aaronelborg

@mibstar Did you try visiting a node/view page before a node/edit? That seems to fix it for me. Hope it helps.

What worked for me was to add the Wrapper Icon to the 'full html' text format.

Got it from here:
https://www.drupal.org/project/drupal/issues/3332416#comment-15777990 🐛 CKEditor 5 toolbar items of multi-value field (typically Paragraphs) overflowing on narrow viewports and overlapping with node form's sidebar on wide viewports Needs work

I ran into this issue after upgrading to Drupal 10. Fix seemed to be:
1) Upgrading to Components 3.1
2) installing symfony/css-selector and symfony/dom-crawler (you might not need to do this but I did)
3) adding this to my theme's info.yaml

components:
  namespaces:
    atoms: ../wingsuit/dist/app-drupal/atomic/patterns/01-atoms
    molecules: ../wingsuit/dist/app-drupal/atomic/patterns/02-molecules
    organisms: ../wingsuit/dist/app-drupal/atomic/patterns/03-organisms
    templates: ../wingsuit/dist/app-drupal/atomic/patterns/04-templates

Perhaps this will help someone else. Hope so!

Doc block was wacky.

Interesting...

I had to add that reused field to yet another paragraph (so now 3 paragraphs have that field). Truth be told, I need to add it to at least 4 more.

After adding it to the 3rd one, the 500 error is back on node/edit regardless of the http.response.debug_cacheability_headers setting (true or false).

Has anyone confirmed for certain that the problem is only from http.response.debug_cacheability_headers:true and that the other developer settings aren't also interfering?

I can confirm that the http.response.debug_cacheability_headers setting is indeed what's causing the issue for me. Never ran into this before today.

To trigger the issue, I added a boolean field to one paragraph and all was well. However if I added that same field (e.g. reused the field) to another paragraph that appears within a 'field_flexible_content' field (which is a entity_reference_revision field), I got the whitescreen/500 error. Both paragraphs are nested within the same node and both have content, fwiw.

This is my development.services.yml:

# Local development services.
#
# To activate this feature, follow the instructions at the top of the
# ‘example.settings.local.php’ file, which sits next to this file.
parameters:
  http.response.debug_cacheability_headers: false  #<-when this is true i get a whitescreen/500 error on node/edit
  twig.config:
    # Twig debugging:
    #
    # When debugging is enabled:
    # - The markup of each Twig template is surrounded by HTML comments that
    #   contain theming information, such as template file name suggestions.
    # - Note that this debugging markup will cause automated tests that directly
    #   check rendered HTML to fail. When running automated tests, ‘debug’
    #   should be set to FALSE.
    # - The dump() function can be used in Twig templates to output information
    #   about template variables.
    # - Twig templates are automatically recompiled whenever the source code
    #   changes (see auto_reload below).
    #
    # For more information about debugging Twig templates, see
    # https://www.drupal.org/node/1906392.
    #
    # Not recommended in production environments
    # @default false
    debug: true
    # Twig auto-reload:
    #
    # Automatically recompile Twig templates whenever the source code changes.
    # If you don’t provide a value for auto_reload, it will be determined
    # based on the value of debug.
    #
    # Not recommended in production environments
    # @default null
    auto_reload: null
    # Twig cache:
    #
    # By default, Twig templates will be compiled and stored in the filesystem
    # to increase performance. Disabling the Twig cache will recompile the
    # templates from source each time they are used. In most cases the
    # auto_reload setting above should be enabled rather than disabling the
    # Twig cache.
    #
    # Not recommended in production environments
    # @default true
    cache: false
services:
  cache.backend.null:
    class: Drupal\Core\Cache\NullBackendFactory

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

I was able to apply #31 to Entity Embed 1.4.0 and this does seem to eventually solve the "No way to add a link around Image Entities" issue.

However, it might be worth noting that when uploading one's own image, after clicking the 'Add Images' link at the top of the modal, there's an 'Image Link' field within this modal that seems to only exist to allow the user to add a url to the content one thought they were adding in order to have the image link to that specific link entered in that field? (The field is called 'Image Link' but is that really needed if it just prints a url to the image?)

In other words, I'm not 100% clear as to why it's needed? Maybe it was intended to be the link to what the user wanted the uploaded-image to link to? Currently, it just prints that link at the bottom of the image.

But all in all, this patch seems to successfully allow creating an image link as after clicking 'Save Images' at the bottom of that modal, one is correctly taken to the next modal called 'Embed Media Item' where one can properly add an image link (using the 'Link To' field) and that DOES seem to work as intended so thanks for that!

Perhaps this 'Image Link' isn't needed though? Or needs a better description of what it does?

Thanks again for the patch!

@Graber, Yeah as soon as I hit the 'submit' button on my post, I thought "yeah... this could be done by accessing the node ($entity) directly instead". I appreciate your input though. Thanks!

I'm not sure if this is the best place to ask this so forgive me if I'm out of place here...

I'm wondering if OP's issue stems from the fact that they're accessing properties within the execute() function from a loaded single entity but performing operations on many items that were referenced by said single entity. My assumption is that the bulk operation is only aware of that single entity. I'm actually running into this issue now and a search found this issue so here I am.

In short, I'd like to get my custom VBO action to access bulk operations messaging/saving operations... but not on the $entity passed to execute. Instead, I need this data to reference the entities referenced from the single $entity passed to execute().

For example, if I'm loading nodes tagged with a certain term and then removing that term from these nodes, how can I access the bulk operations data to do its operations (messaging, count of items, etc) on these nodes? Obviously, they aren't the $entity passed to the execute method so (I'm assuming) that the bulk operations has no knowledge of their existence. What I'm using works but it will time-out occasionally on terms that reference tons of nodes. As it stands, I just re-run it until I actually see the progress bar finish.

I've found very little documentation on this which leads me to believe I might be doing something weird and/or wrong. Thanks for any advice.

      $nodes = \Drupal::entityTypeManager()->getStorage('node')->loadByProperties([
        $old_vocab_field => $tid,
      ]);      
      foreach ($nodes as $node) {
        // Add tid to node.
        $node->set($new_vocab_field, $tid);
        foreach ($node->get($old_vocab_field) as $k => $v) {
          $target_id = $v->get('entity')->getTargetIdentifier();
          if ($target_id == $tid) {
            // Remove old tid from node.
            $node->$old_vocab_field->removeItem($k);
            $node->save();
            break;
          }
        }
      }

I think I fixed this by updating to the latest and greatest Paragraphs module. Does that sound familiar to anyone else?