UUID and original_path parameters are not always available in the request

Created on 19 June 2024, 8 days ago
Updated 21 June 2024, 6 days ago

Problem/Motivation

When using entity browser for an entity reference field, the uuid and original_path arguments of the entity browser are passed via the URL. This allows you to fetch the entity browser settings in custom code related to the view and exposed form.

When using an entity browser in CKEditor5, only the uuid is passed. The original_path is not.

Besides that, when using a view with an exposed form, the uuid and original_path arguments of the entity browser are both not available in the request when the user starts to filter the results. The view executes the /views/ajax URL but doesn't pass along those arguments.

This is probably caused by the fact that we are only rendering parts of the entity browser (probably due to complexity added by CKEditor 5). As a workaround, we should probably add code that preserves those arguments in this module.

Steps to reproduce

  1. Create an entity browser using a view with exposed filters.
  2. Configure a CKEditor5 field with an entity browser.
  3. Add a link in the CKEditor using the entity browser.
  4. Use the pager or exposed filters.
  5. Observe the URL parametersuuid and original_path getting lost.

Proposed resolution

  1. Pass both the uuid and original_path arguments of the entity browser.
  2. Make sure the arguments are passed when using the exposed filters or the pager.

Remaining tasks

  1. Write patch
  2. Review
  3. Commit

User interface changes

None

API changes

The uuid and original_path arguments of the entity browser are always available in the AJAX requests.

Data model changes

None

πŸ› Bug report
Status

Needs review

Version

1.0

Component

Code

Created by

πŸ‡³πŸ‡±Netherlands seanB Netherlands

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @seanB
  • πŸ‡³πŸ‡±Netherlands seanB Netherlands

    Created an MR that passed the parameters. Also added a custom ckeditor5 parameter so we can check when to forward it for views.

  • Status changed to Needs review 8 days ago
  • πŸ‡³πŸ‡±Netherlands askibinski

    Yeah we use `Drupal.ckeditor5.openDialog` and not the `Modal` or `iFrame` provided by entity browser.

    There was a reason for using openDialog the way it is now, I think it was to simplify communication between ckeditor dialogs instead of the awkward way using iframes and also because entity browser threw in a lot of other (js?) stuff which screwed something else up, not sure.

    Looking at the code from entity browser, they indeed also add `original_path` so I agree we should add that to the request, I'm just not sure that `hook_views_pre_render` is also needed to add it to `ajaxViews`? I don't see entity_browser doing that either so if someone would need it, it could be implemented using that hook since it is not needed for normal functionality.

  • πŸ‡³πŸ‡±Netherlands seanB Netherlands

    Entity Browser has entity_browser.view.js that performs some magic. Since we do not properly use the Entity Browser modal it seems parts of it do not work as expected. I agree hook_views_pre_render is a workaround for this, but it seems a bit easier that properly integrating Entity Browser modals.

Production build 0.69.0 2024