🇵🇱Poland @gugalamaciek

This was wrong implementation on our side, where we have custom autocomplete filter. Nothing wrong with views_filters_summary. I'm closing this.

You're right. It's related to this one: https://www.drupal.org/project/dynamic_entity_reference/issues/2766213 📌 Add DynamicEntityAutocomplete form element Active

So it generates part in brackets like: :.

Looks like by fixing my scenario I destroyed the original one. On it, might be the fix is needed somewhere else, as:

• entity reference produces value = <entity_id>
• dynamic entity reference with https://www.drupal.org/project/dynamic_entity_reference/issues/2766213 📌 Add DynamicEntityAutocomplete form element Active produces value = Label (<entity_type_id:<entity_id>). The desired behaviour would be to get there and then no JS changes needed.

Checking more.

gugalamaciek → created an issue.

@mably it's done, I moved it to the separate module.

gugalamaciek → created an issue.

Replace comas with spaces, so now this is returned:
rgb(0 0 0)
rgb(0 0 0 / 0.5)

Yeah, I know. I’m short on time right now, but I’ll try to explain it better and add an MR when I get a free minute. For now, if someone needs it, can use the patch ;)

gugalamaciek → created an issue.

@mably it looks good, all works :)

@mably - I applied your MR, it looks good.

Meantime I I discovered one more problem with getFilterSubmit(exposedForm) inside views-filters-summary.js.

The case is when you configure entity browser with multiple tabs inside it. Then, entity browser can render additional buttons with type="submit", which are ofter hidden and disabled. But getFilterSubmit(exposedForm) just gets first one, no matter what it is. So improvement is to:
1. First, collect all inputs/buttons
2. Filter out disabled or hidden elements.
3. Try to use element with data-drupal-selector starting with 'edit-submit'
4. Fallback: try to use visuall primary button
5. Fallback: then just try to use first found element

Sorry for the patch instead of MR.

gugalamaciek → created an issue.

gugalamaciek → created an issue.

gugalamaciek → created an issue.

gugalamaciek → created an issue.

gugalamaciek → created an issue.

gugalamaciek → created an issue.

gugalamaciek → created an issue.

gugalamaciek → created an issue.

I see that remove operation assumes that we work only with entity reference fields. I extended it to work with any type of field, comparing main property values (e.g. target_id property in case of entity references, value property in case of text/string fields, etc)

gugalamaciek → created an issue.

I think, that when taxonomy unique is disabled, nothing should be added to the config files, so also taxonomy_unique.message should be unset. I made small change to achieve this. I replaced:

if ($form_state->getValue('unique_message')) {

with:

if ($form_state->getValue('unique_message') && $form_state->getValue('unique')) {

Patch for drupal 11.x (based on #27)

xjm → credited gugalamaciek → .

#26 extended with configurable parent and weight on detail page, not just form display.

I found small bug related to the scenario, when no fields are selected for update and I click “Update”. #5 fixes it.

There were problem with checking options on first loaded page, when filter were multivalue. Code will explain this (lines starting with + are new ones added in #19, compared to #18):

// On first loaded page, url can have filters passed in query. They are
// present in window.location.search. Let's add them to initial filters,
// when getting back to first loaded page.
$.each(parseQueryString(window.location.search), function(filter_name) {
+  // The options.data object stores entries keyed by filter name,
+  // which works well for single-value filters. For multi-value entries,
+  // the filter name includes '[]' at the end. We need to remove it
+  // before checking if options.data has the filter with given name.
+  filter_name = filter_name.replace(/\[]$/, '');
    if (!options.data.hasOwnProperty(filter_name)) {
      options.data[filter_name] = this;
    }
});

I’m not 100% sure if UUID is actually a required field (I assumed that) - so you can (potentially) have entity types without a UUID. Nevertheless, I believe this patch is a good starting point

The patch adds an additional sort by language code when the entity type supports translations.

gugalamaciek → created an issue.

gugalamaciek → created an issue.

One more small improvement to #74.

#68 for me won't work. I have scenario where:
1. I selected 2 entities
2. I can update one of them, as there will be no errors. For the other one I know there will be error.
3. #68 skips all updates, while on #52 one item is updated (as expected).

There is small bug in #52 (php error, when you try to submit, but nothing selected to be updated), I improved it in #74.

Patch to fix the problem.

gugalamaciek → created an issue.

The previous patch didn’t resolve the issue. I’ve written a new one that:

• Ensures that operator_id exists before checking whether it’s empty.
• Adds an additional check to verify that $input[$this->options['expose']['operator_id']] exists before using it. If it doesn’t, the default $this->operator is used instead.

Fix for Drupal 10.x and 11.x (the only difference is that in Drupal 11, file.js is located in the js/ folder).

gugalamaciek → created an issue.

Proposed patch to fix fix the problem.

gugalamaciek → created an issue.

gugalamaciek → created an issue.

gugalamaciek → created an issue.

If you still need it in version 2.0.0, here is the patch

Minor improvement: The preview remove button form #name was not always unique.