Problem/Motivation
Currently, the disabling check is performed on the entire URI, including the query string. However, in some cases, this can lead to unintended behavior.
Steps to reproduce
In my case, the situation is as follows:
- I created a storage using the
storage →
module.
- Inside the storage, there's a reference field pointing to an image-type media, which uses the media library as its widget.
- Klaro is configured using the textarea suggestion
\/admin\/
, but only in the section "Disable Klaro! element and don't block attributed resources on following URL patterns."
- JavaScript aggregation is enabled.
When I edit a storage by clicking the button in the overview, the page opens including the destination parameter.
/it/storage/18759/edit?destination=/en/admin/content/storage%3Fname%3D%26type%3Dstorage_multimedia%26status%3DAll%26langcode%3Dit
In this case, when I try to open the media library, the AJAX commands to open the modal are correctly triggered, but the element with the ID #drupal-modal
is not present on the page, so the media library does not appear.
The missing element should be added to the HTML via drupal.dialog.ajax
, but for some reason, this script is not present when the page loads.
- If I disable JavaScript aggregation, the issue disappears.
- I don't experience this behavior when using a node instead of a storage, but storages don't use any custom libraries or JavaScript.
There is probably an issue with the ordering of the JavaScript files being aggregated somewhere else, but I haven't been able to identify the exact cause.
From what I've observed, the pattern used in Klaro is matched against the destination
in the query string, and as a result, the script is excluded. However, during aggregation, other JavaScript files are also removed — including the one responsible for creating the #drupal-modal
element.
I can fix this by modifying the pattern, but since the site is multilingual, I would need to use a pattern similar to this:
^\/admin\/
^\/it\/admin\/
^\/en\/admin\/
^\/fr\/admin\/
...
^\/es\/admin\/
Proposed resolution
Is the search in the URI instead of just the path intentional?
Otherwise, it might be possible to modify the methods KlaroHelper::onDisabledUri()
and KlaroHelper::onExcludedUri()
by replacing:
$uri = $this->request->getRequestUri();
with
$uri = $this->request->getPathInfo();
Remaining tasks
User interface changes
API changes
Data model changes