Facet process to merge node types

Ran into this issue https://www.drupal.org/project/facets/issues/3368327 🐛 Facets Pretty Paths module and Merge node types processor error Active
Updated the patch slightly.

renamed the patch

Re-rolled the patch in #14 to improve the language used in comments and the UI. The functionality works great in the original patch.

For context we're using version 2.0.6 of facets, solr / solr cloud, and json:api search index.

Here's what we're seeing for the url of our merged node facet (in the metadata section of our json:api response):

https://base_url.com/jsonapi/index/solr_node_index?filter[facet_group]=facet_item&filter[0]=facet_group:facet_item&filter[1]=facet_group:facet_item

Which is not a clickable link.

Our patch corrects the generated url to the below:

https://base_url.com/jsonapi/index/solr_node_index?filter[facet_merged_name][condition][path]=facet_group&filter[facet_merged_name][condition][value][0]=facet_item_1&filter[facet_merged_name][condition][value][1]=facet_item_2&filter[facet_merged_name][condition][value][2]=facet_item_3

Which is a clickable link

Hopefully this patch helps resolve this issue for some others, if not

FYI the interdiff is in the previous comment and file 3133309-18.patch attached to this comment is the actual patch

Resolution to patch 19 which was attempting to pass the translate object as a query parameter

We already have a combine facets processor in 3.0.x. doesn't it solve the requirements here?

@mkalkbrenner the use case here is a common requirement by clients to group content types (and other fields) together in the same value for filtering, for example to produce a checkbox widget like so:

[ ] Latest
[ ] Articles
[ ] Documents

Where Latest are from content types blog and news, Articles are from content type article and page, and Documents are from document and file content type (just a quick example).

This can be done either at index time with a computed field or something, or at search time, with the work on this patch, I don't think it's the same as combining facets.

This works on my end.
Use the query params which compatible to $filter_key & $filter_name.

Facets selected:
article -> Page
page -> Page
news -> News

It should look like this:
/search?f[0]=type:article&f[1]=type:page&f[3]=type:news

@_renify_: Mind summarizing your changes?
Here's the interdiff between patches #20 & #23.
We've been using the patch in #20 successfully for a year now.

In patch #23, you cannot uncheck the merged items once you select them. #20 works as expected

Similar to @dxvargas 's comment above: I need a similar solution, but for media bundles (not node types). Were this feature merged into the Facets module, it would be nice to incorporate other bundle types into this.

I couldn't get #23 to work. Once the combined node type filter was checked, I couldn't uncheck it. So I went back to #20. That didn't work but it was because the query parameter didn't work. Revised the query parameter. Here's what's working for me. We're using the checkbox filter and combining 4 different node types into a single type called "Page". Here's the patch and interdiff.

Same observation as #27 and patch #27 is working for us.

This is very cool, and works great actually!

However, a few observations:
- This should be a MR so it's much easier to review/work on.
- In the latest patch, there are quite a few unused variables (e.g $facet_string and $updated,...)
- I'm not convinced of the config UI. It's tedious if you want to remove the first item in a long merge list since you can only remove the last one.
- Sorting is an issue, I would have expected to have the filters in the same order as they are entered in the config form when no sorting is being applied to the facet, or when you select "order by display weight". This also brings me to previous point that you can't change the weight/order in the current UI.

Tackled the following:

-
Created a branch MR combo for 2.0.x and 3.0.x

-

Removed unused variables and injections.

- I'm not convinced of the config UI. It's tedious if you want to remove the first item in a long merge list since you can only remove the last one.
-

Since the config is loaded in the order it's entered, I'm that in a basic way. For 2.0.x I'm just misusing the termWeight property which is not used for none taxonomy facets. For 3.0.x it's properly using the set() function to do dynamic stuff. After which I can sort the facets array on set value.

-

Added an ID field which is used to set the setRawValue. Added a public method for this as it was a protected variable. I think it's ok to do that in this instance since we're creating a "new" facet based of an existing one. Made all fields required, I can't see a use case where you would not want to change any of the 3 form values. Not changing the ID can also result in conflicting grouped filters where the same first content type is selected as the ID which is solved by forcing an ID. You can of course still mess that up by entering the same ID multiple times. I did not invest time into looking for a machine_name field.

And probably could use a test :)

Just came to the conclusion that setting the raw value does not work like I expected it to.

This also doesn't play nicely with other facets or an exposed fulltext search. It's overriding the complete query with only that of this facet.

#35 and #36 are addressed. Maybe not in the ideal but this is working for my use case.

That just leaves :

I'm not convinced of the config UI. It's tedious if you want to remove the first item in a long merge list since you can only remove the last one.

And perhaps the changes from a textfield to machine name field or at least adding a warning a ID should not be the same as an existing facet value and not the same between groups.

fixed a few things.