🇵🇹Portugal @joao.ramos.costa

Hi @ klaasvw, using your #7 patch fixed the issue on my end. Using:

• PHP 8.3
• D10.4.5
• Views_bulk_operations 4.3.4

But on dev end using Xdebug 3.4.2. the issue still appears, not sure if related with my config.

Nevertheless, seems working with Xdebug 'disabled'.

Thank you

Dear @rahul_
didn't investigate that, sorry.

Did you tried https://www.drupal.org/project/views_filters_summary → as suggested per documentation ?

As only facets_filter (+BEF?) support AJAX, ATM.

@all With some work indeed managed to setup views faceted filter work with AJAX, in my case, the issue 2894747 🐛 Views hardcodes exposed filter block form ID's which breaks AJAX when the same form is shown multiple times on one page Needs review was preventing auto submit the ajax form.
Also, some custom processors I used, add are not needed anymore.

So, I second nmillin #297 suggestion and try to upgrade facets.

Hi @karlshea, I'm moving to 3.x too. And actually using a patch from this issue. But AFAIK it indeed works. Not 100% sure about views facets summary as it was detached but views block seemed straighforward...

Added tests for both the fix and the issue.

The very same issue happened to me when language configuration override contains data that differs from the expected type.
In this case https://www.drupal.org/project/tmgmt/issues/3509121 📌 Mismatching language configuration override values Active .

Can be related with this line, for instance: https://git.drupalcode.org/project/drupal/-/blob/11.x/core/modules/confi...

If a given config entry value isn't passed it will be set as null, despite it's base config expected value/schema ?

Cheers.

Let's create tests (passing and failing), and/or discuss better approach.

joao.ramos.costa → created an issue.

joao.ramos.costa → changed the visibility of the branch 4.3.x to hidden.

Currently, the filter setting option checks if the term has already been replaced in that filter instance (plus string transformations). What I added in the open MR was to check, in addition to this, whether it has already been replaced in the current request. I think we'd be fine with the latter, as I believe that's the rationale for choosing that setting. At the moment, I’m also checking it more as a POC, so let others test. let’s discuss!

In that sense a new issue title and summary would be more appropriate, as any text instance rendered on the ‘page’ can use glossify filters, nodes, paragraphs, blocks, taxonomy terms… etc.

Hi,

Here's a suggestion MR 43.

joao.ramos.costa → made their first commit to this issue’s fork.

Hi @anybody,

(other) kind reminder that documentation was added in MR39, WDYT ?

thank you :))

Hi @anybody,

kind reminder that

MR37 was updated containing new tests and MR38 includes similar failing tests adressing #15.

Can we move forward ?

Thank you :)

I think the concerning issue should be fixed ASAP or the tooltips are unusable, since with "common" filters any editor may create html entities by pressing 'shift+enters' on (eg) taxonomy term description and the parse errors will be triggered.

+1 on this. Worked on my end!

Hi @bkosborne, I've tried your MR, worked on my side, thanks a lot for your work.

Yes, I agree that convert the <br> may be done in other issue,
but tried to keep as much as previous patch was doing, since it was added from #4 🐛 HTML entities lost during tooltip rendering Active and I wanted to keep a commitment. But yes, you are right. Let's do it in another issue, if necessary.

joao.ramos.costa → changed the visibility of the branch 3360633-html-entities-lost-3.x to hidden.

Hi @cmd87, I tend to agree in what @berdir concerns, also I'd like to add what could happen with upgrade when a given hash exists ?

Hi @rayand,

from your console errors 1st seems the issue reported on https://www.drupal.org/project/facets/issues/3211155 🐛 facet-views-ajax.js and ajax controller do not take views prerender and views drupal js settings into account Needs review .
See #239 🐛 Facets with AJAX not working in most of situations Needs work

Try to apply the provided patch there 🐛 facet-views-ajax.js and ajax controller do not take views prerender and views drupal js settings into account Needs review and see what happens.

Yes,

possible in the README in a misc section ? Your you mean add a hook_update, that could be tricky...

Absolutelly ,

on it.

I'm already getting confused with the issues :)).

Thanks for the quick response!

Hi @anybody,

done at https://git.drupalcode.org/project/glossify/-/merge_requests/37 ; I couldn't push to 3504552-make-glossify-exclude-class branch, so Include both commits.

So, concluding (sorry for the spam), regarding:

1 - Cirurgical terms excluding:
add .glossary-exclude class to a span wrapping the concerning term. (Or Include https://www.drupal.org/project/glossify/issues/3504552 ✨ Make "glossify-exclude" class detection more robust Active to a more robust approach)

2 - Exclude concerning term all the time, implement hook_query_tag_alter that is available from 6622277d, and add the needed condition (in the above example add a boolean field called field_exclude_from_glossary, or a $query->condition('tfd.name', "Not me", '!='); and the implementation example).

Thanks for merging,

but what other issues you mean ? If means @andrés chandía concern to exclude some words to be "glossified", can simply wrap the term in text editor within a span with glossify-exclude class.
eg
<span class="glossify-exclude">prosodia</span>

Can be easily configured with ckeditor styles plugin:
eg

as per https://www.drupal.org/project/glossify/issues/3504552 ✨ Make "glossify-exclude" class detection more robust Active suggestion.

So I don't see anything more to do here.

I tend to agree with you,
in fact one maybe don't want to use tooltips and don't need HtmlPurifier at all, but on the other hand currently including a   triggers a warning. We can even simply add a hook there and anyone may sanitize the text with any other method. I'm not sure re other module, but the setting seems a decent approach. Only would be available if someone have this dependency enabled.

But let's see others opinion, then.

tkx

Also,

.glossify-exclude could be documented.

Hi @anybody,

I wasn't aware of https://www.drupal.org/project/glossify/issues/3504552 ✨ Make "glossify-exclude" class detection more robust Active at the moment I start working on ckeditor 5 plugin, but the solution provided by @prudloff seems even more flexible than ckeditor5 plugin, as any site editor may only need to leverage CkEditor styles dropdown plugin and add the class to the given words/elements, as they please.

So, IMO this fix partially this issue, then I'll drop glossify_exclude module I was working on, which it could lead to other issues, in fact. Drupal version support, GlossifyBase class overwrite, etc.

But, problem/solution 2 persists - exclude list. In that case no extra module is needed, or even desired, as the hook should be triggered on nodeTooltip and taxonomyTooltip.

tkx

Indeed, clever than what I proposed in https://www.drupal.org/project/glossify/issues/3455743 💬 Avoid linking a specific istance of a word in content Active .

I was overcomplicating working on a ckeditor5 plugin that included a new html element to break processing and avoid glossify a given word instance, then bumped on that xPath query, and your issue.

This solves partially https://www.drupal.org/project/glossify/issues/3455743 💬 Avoid linking a specific istance of a word in content Active , as any site builder can simply leverage ckeditor styles plugin (styles dropdown) and add .glossify-exclude class on desired elements.

So, +1 for me.

Tested it and seemed working smoothly on my dev end.

Hi @anybody,

thanks for quick responding. I do agree that 1 is more flexible, indeed, but think of a big project where content editors want to remove all glossary links for specific word, but want to keep the taxonomy term intact, that's happening in my case :D, using the custom tag would evolve a big update with a lot of "take cares" to test.

So I'd say both can be useful,
the 1st for cirurgical alterations, and the 2nd for a more flexible approach, could be to exclude terms by condition, could be to add others, there's no limit for the imagination.

I can provide a MR with both if you agree.

cheers

Hi folks,

here are my 5 cents,
I think there's at least two ways to deal with the issue both compromising solutions, and I'd say can be cumulative:

1 - Add a ckeditor5 plugin that add a tag wrapping the word we want to skip in text editors, as @Andrés Chandía suggests and simply

2 - Use a custom field per entity which would exclude the word directly from the query, this could be achieved by simply add a new hook in the fashion of (eg) hook_taxonomy_vocabs but letting developers alter the query, adding for instance a query join with a condition ie

$query->join('taxonomy_term__field_exclude_glossary', 't__feg', 't__feg.entity_id=tfd.tid');
$query->condition('taxonomy_term__field_exclude_glossary.value', 0);

I can work on both and open a MR,

just LMK your thoughts

Hi @anybody and @jurgenhaas,

just commited a suggestion including HTMLPurifier (https://github.com/ezyang/htmlpurifier) which is a decent library to provide proper sanitization, included also a composer.json to require it. The tests must be updated. Not sure how.

Yes, not easy indeed. I only think of HTMLPurifier as a safe alternative with performance cost, ofc.

Hi @anybody,

I've ported MR13 to 3.x and included tests.

joao.ramos.costa → made their first commit to this issue’s fork.

joao.ramos.costa → made their first commit to this issue’s fork.

I think this could actually could be fixed by https://www.drupal.org/project/glossify/issues/3269949 ✨ Add in a synonyms feature Needs work , a synonyms feature would let to add in the needed acronyms.

+1

Hi everyone,

still investigating but I think there's some issues when commit b124c65a introduced entityqueue_views_query_alter.
1 - This line if (\in_array('entityqueue_relationship', $join_ids, TRUE)) { :
It should look for relationship plugin 'id' and not for its key as we might have more than one relationship where _n is appended.
2 - The expression $subquery->addExpression("MAX($revision_table.{$keys['revision']})", $keys['revision']);
Doesn't seem to take into account when 'limit_queue' option from entity_queue ViewsRelationship is set, or more than an entity_queue, I guess.
3- entity_subqueue_revision table doesn't include the parent queue, in case of a subqueue set as 'limit_queue', so it makes dificult to add a condition clause here too.

Same here.
If help is needed, LMK :)

Cheers!

HI @heykarthikwithu , thank you for the mr.
I'm not sure why scope is being reduced to link or src tags, when this also affects meta tags, for instance.
Regards.

Hi graber, I'd say using workspaces module and switch to other than "live" workspace, access /admin/content and try to publish content using VBO.

joao.ramos.costa → created an issue.

Hi @loopy1492, I will soon test your steps, although I think we should add them as kernel/unit tests. As for the table auto-incremental unique id, here's my two cents: Seems indeed like the most wise choice; otherwise, we might get lost in the infinite creativity of character combinations.

HI @ tommyk,

indeed. Got here by the same reason. The aria-* attributes may be 'whitelisted' as for the same reason 'data-' attributes are and perhaps a little more than 'ng-'.

Hi @dualfr,

mr is updated according to your concerns, thanks! On the other hand, I think an addition fixes the buildOptionsForm, as I couldn't see the other fields using Drupal 10.3.6. I hope no one minds being added here; otherwise, it would have been difficult to test the functionality properly.

Hi @dualfr,

Thanks a lot for reviewing it. I'll have a look at your thoughts on the review soon, but they seem absolutely crucial at first glance. I can't promise exactly when, but it will be soon.

Regarding the second topic, I think it should definitely be done. It was possible to extract it, but it didn’t apply directly since it fit with the conditionals added in this MR. However, I promise to take a look and open an MR as well.

Thank you !

Hi @duaelfr,

Sure. I've opened MR10 to split the patches to make it easier to review.

Here's a path from the diff to one who might want to use it.

Regards,

J.

Hi @anybody,

there's a already a MR, just added the patch (from latest mr changes) so one can use it from d.org.

Hi @anybody and @Eugene Bocharov,

indeed.

Removed such property.
Here's an updated patch from Mr7.

(Sorry for the delay :/ )

Here's a suggestion patch from mr 29.

joao.ramos.costa → made their first commit to this issue’s fork.

Hi @chi,

of course 🤦🏽‍♂️, it works and updates without any problems.
Closing as it oesn't make sense.

Thanks

Hi @ananya.k,

The patch fixes the issue, but we can't move without it is applied upstream.
For instance a tool like cweagans/composer-patches will only apply patch after module installation.

For those who might be stucked a workaround can be an alias:
ie
"twig/twig": "3.14 as 3.10.3",
https://getcomposer.org/doc/articles/aliases.md#require-inline-alias

Faced the same issue with mysql 8.

ERROR 1062 (23000) at line 11049: Duplicate entry '/mypage page/example/1.pdf-en' for key 'redirect_404.PRIMARY'

joao.ramos.costa → created an issue.

Thank you @elc,

your patch and #254 suggestions worked for my case (D10.3.1 , Facets 2.0.8, Search API 1.35.0).

Works smoothly,
Tkx @elc.

+1

Hi @berdir,

Commited, here's an updated patch from current mr.
Thanks for reviewing.

+1
Manage to tackle the same issue for https://www.drupal.org/project/onomasticon/issues/3251919 ✨ Allow the selection of multiple vocabularies Needs review as multiple vocabularies save need a schema.

Dear @broon, any thoughts on #13 patch ?
I'd move forward with this, the changes seem pretty straightforward and adding the schema allows use in Drupal 10.3+. By chance when updating I didn't notice because I already had the patch, but the schema is necessary.

thx :)

Hi @svenseeberg,

Thanks for following up on my incomplete information.
To whom it may concern, I'm actually using the patch from #138, with a local patch on top of it adding the request session. As after @idebr very useful patch there was already a trajectory on the issue and I haven't had time to specifically analyze its impact, although it works on my project, I haven't yet added a patch here. I'll do that soon.

Cheers!

Yes, @msnassar. Worked like a charm.

Hi @Alex Bukach,

thank you for the patch.

I've applied it, but unfortunatelly on my end (PHP 8.3, D10.3.1, Facets 2.0.7) it ended up duplicating the existing libraries and broking some facet widget behaviors.

It seemed solved in my case by adding request parameters to the new request parameters , allowing Drupal\Core\Ajax\AjaxResponseAttachmentsProcessor::buildAttachmentsCommands() filtering out existing libraries from ajax_page_state key:
https://git.drupalcode.org/project/drupal/-/blob/11.x/core/lib/Drupal/Co....

ie:

if ($request->hasSession()) {
      $request->getSession()->save();
      $new_request->setSession($request->getSession());
      $parameters = $request->request->all();
      $new_request->request->replace($parameters);
    }

But it seems to fix this momentarily, I'm not sure of the impact of it.

But looking back now, seems to related with:
https://www.drupal.org/project/facets/issues/3211155 🐛 facet-views-ajax.js and ajax controller do not take views prerender and views drupal js settings into account Needs review .

Thanks

Unless otherwise noted and tests fail, here is an attempted reroll from #81 to D10.3.

#10 MR7016 reroll for D10.3.

Hi @quietone,
Looking back this doesn't make sense :).

closing,

Thanks for reviewing

Hi @justin.green
Faced the same issue,

We have a custom block extending the search_api_sorts block as we needed a custom solution, but for the case the problem is the same.

So as a workaround we're rendering the block in the view (there are several ways ie views_block_area ,etc.) then it is rebuilt on the ajax request.

Thank you @ioana apetri,
worked smoothly!

Hi @matthiasm11,

worked smoothly for 2.x-dev,
thank you!

Here is a 'reroll' from #9 for 2.0.0-alpha4.

joao.ramos.costa → made their first commit to this issue’s fork.

Got the same issue concerning

  'longerthan' => function ($l, $r) {
        return strlen($l) > $r;
      },

since in our case $l can be null/undefined as we cannot control the remote json structure.
I believe that is a common issue.

Thank you

Worked for me. +1

Dear,

here's a updated suggestion (patch from MR14 https://git.drupalcode.org/project/onomasticon/-/merge_requests/14 ) with some fixes from #10 and tackle @broon concerning from #8. Namely:

- filter schema.
- Update hook to existing instances to new schema settings.
- Single hook_onomasticon_terms with all loaded terms.
- Form checkboxes instead of select for vocabularies.
- Settings form validation to prevent empty vocabularies or vocabulary set when filter is disabled.

Cheers!

joao.ramos.costa → made their first commit to this issue’s fork.

Thanks a lot for the review and merge :)

Hi @ioana petri,

I was having the same issue in a project and hadn't updated from 4.3.0, waiting for time to look into the matter, but I can confirm your patch resolved the problem and solr_date_range with a custom filter using undefined range works smootly.
Solr version: 8.7.0
Search_api_solr: 4.3.2

Let's let more people test this and change the ticket status.

Thanks a lot!

Here is a patch from MR17 [https://git.drupalcode.org/project/views_json_source/-/merge_requests/17]

joao.ramos.costa → created an issue.

Hi @berdir well noted,
here's a patch from current MR with updated settings.

Super!
Thanks a lot

For those looking for an intermediate solution, instead of a rollback of the aforementioned commit, with a custom implementation as mentioned above:

/**
* Implements hook_config_schema_info_alter().
*/
function MODULE_config_schema_info_alter(&$definitions) {
if (isset($definitions['ckeditor5.plugin.ckeditor5_sourceEditing'])) {
unset($definitions['ckeditor5.plugin.ckeditor5_sourceEditing']['mapping']['allowed_tags']['sequence']['constraints']['SourceEditingRedundantTags']);
}
}

2.0.x Patch from MR14

joao.ramos.costa → made their first commit to this issue’s fork.

A patch from 2.0.x branch

Updated patch from MR.

Hi @AstonVictor,

Thanks a lot!

Hi @AstonVictor,
thanks again for maintaining the module.

I now see that the possibility of passing arguments within the body of the POST request in the commit has dropped at commit https://git.drupalcode.org/project/views_json_source/-/merge_requests/6/..., I was already using this in a project so unfortunately I still cannot update to release 2. To make things more difficult, the getRequestResponse method is private and prevents an class override to change the method and thus the request parameters.
Should I open a new issue?

Kind regards,

João.

Thanks a lot for the quick review and merging

Tested MR7 on 1.6 release,

fixes dynamic property declaration notice.

Cheers @AstonVictor,

Thank you !
👍👍👍

Dear @ttesteve,

Can you please review the requested feature with the provided patch, and update the issue status ?

Cc
@broon

Super! Thanks a lot!

João.

Hi @justcaldwell,

Thank you ! :)