One task I am finding I do a lot is create the same facets on different sources.

For example, I might have a 'category' facet on one view, and I want to add the same 'category' facet on another view which has the same SearchAPI index as its source, or another display of the same view.

CommentFileSizeAuthor
#20 provide_a_facet_clone-2747593-20.patch8.27 KBborisson_
#20 interdiff.txt4.92 KBborisson_
#17 provide_a_facet_clone-2747593-17.patch8.02 KBborisson_
#9 provide_a_facet_clone-2747593-9.patch8.01 KBborisson_
#9 interdiff.txt7.09 KBborisson_
#2 2747593-2.facets.facet-clone.patch6.44 KBjoachim
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

joachim created an issue. See original summary.

joachim’s picture

joachim CreditAttribution: joachim at Torchbox commented
Status: Active » Needs review
FileSize
2747593-2.facets.facet-clone.patch6.44 KB

Here's a patch.

I've just noticed that Views calls the operation 'duplicate' rather than 'clone' now, but I don't have time to change the strings on this, sorry!

borisson_’s picture

borisson_
Primary language Dutch
Location Mechelen, 🇧🇪
CreditAttribution: borisson_ as a volunteer commented
Status: Needs review » Needs work
Issue tags: +Needs tests

Setting back to needs work because of the label change, this also needs tests. I'll take another in-depth look at the patch at dev days.

borisson_’s picture

borisson_
Primary language Dutch
Location Mechelen, 🇧🇪
CreditAttribution: borisson_ as a volunteer commented

We discussed this at drupal dev days and we suggest that we use a button to clone instead that uses an actual clone that only changes the id to append _1. That action should redirect to the edit form of the newly cloned entity.

joachim’s picture

joachim CreditAttribution: joachim at Torchbox commented

> we suggest that we use a button to clone instead that uses an actual clone that only changes the id to append _1.

I'm not keen on that. I really like to be able to control the machine name of my facets (and config objects in general). On the project I used Facets on, I had about 12 facets in total. If most of them had similar names with a _n appended it would have got pretty confusing.

(As it was, I called them VIEWNAME_VIEWDISPLAY_FIELD, so eg search_events_date, search_all_category, etc.)

borisson_’s picture

borisson_
Primary language Dutch
Location Mechelen, 🇧🇪
CreditAttribution: borisson_ as a volunteer and commented
Issue summary: View changes

We discussed this at the monthly hangout and we think that this functionality makes a lot of sense. We also see the value in being able to change the ID. However, changing the source doesn't seem very interesting, changing the source'd mean that the field might not be available either. So we figure that keeping only the ID in there makes more sense.

This will also still need tests as well.

joachim’s picture

joachim CreditAttribution: joachim at Torchbox commented

> However, changing the source doesn't seem very interesting

Changing the source was the entire reason of my use case!

joachim’s picture

joachim CreditAttribution: joachim at Torchbox commented

To expand on my use case:

I have a single search server and a single index.

I have two Search API views, each with several page displays, about 6-7 page displays overall.

One page display is 'Search everything'. The other page displays are more specialized: they have filters added for the datasource, or the node type within the node datasource. So there's 'search groups' (Group module entities), 'search events' (event nodes), 'search resources' (custom entity type).

There are several vocabularies which are applies to all node types and other entity types as well, and so the facets for these vocabularies were to be added to all the search displays. Eg, there are vocabs 'Category' and 'Topic'.

Using the clone form in this patch, I was able to create the 'Topic' facet on the 'Search everything' view display, and then clone it to all the other displays, thus saving me a lot of time!

borisson_’s picture

borisson_
Primary language Dutch
Location Mechelen, 🇧🇪
CreditAttribution: borisson_ as a volunteer and commented
Status: Needs work » Needs review
Issue tags: -Needs tests
FileSize
interdiff.txt7.09 KB
provide_a_facet_clone-2747593-9.patch8.01 KB

I discussed this with @barisw and @jhedstrom this week, they convinced me of it's usefullness. So I wrote a test and cleaned up the code and actually made it work again.

I think this is a very easy way to get in trouble though, the current way of loading views kind of scares me. I don't have a better solution at the moment though. So uploading my work but this is not ready yet.

borisson_’s picture

borisson_
Primary language Dutch
Location Mechelen, 🇧🇪
CreditAttribution: borisson_ as a volunteer and commented
Status: Needs review » Postponed

Postponing this on the work in #2772745: Search API integration doesn't check/define feature support of backends

BarisW’s picture

BarisW CreditAttribution: BarisW at LimoenGroen commented

Great work by the way, thanks!

joachim’s picture

joachim CreditAttribution: joachim at Torchbox commented

> I think this is a very easy way to get in trouble though, the current way of loading views kind of scares me.

Can you say more about this please?

borisson_’s picture

borisson_
Primary language Dutch
Location Mechelen, 🇧🇪
CreditAttribution: borisson_ as a volunteer and commented

> I think this is a very easy way to get in trouble though, the current way of loading views kind of scares me.

Can you say more about this please?

Sure, the reason why this worries me is because of the refactor in #2772745: Search API integration doesn't check/define feature support of backends, after that refactor, there won't be a difference between any kind of search api based sources (so search_api_page will use the same plugin). So loading a view won't always be possible.

I think, because of that, that we should refactor the code here once that gets in. The test that we added here is good, so we can use that to validate that the new code works.

borisson_’s picture

borisson_
Primary language Dutch
Location Mechelen, 🇧🇪
CreditAttribution: borisson_ as a volunteer and at Dazzle commented
Status: Postponed » Needs review

Back to NR, the issue that was blocking this is now in. Retesting #9.

Status: Needs review » Needs work

The last submitted patch, 9: provide_a_facet_clone-2747593-9.patch, failed testing.

borisson_’s picture

borisson_
Primary language Dutch
Location Mechelen, 🇧🇪
CreditAttribution: borisson_ as a volunteer and at Dazzle commented
Issue tags: +Needs reroll
borisson_’s picture

borisson_
Primary language Dutch
Location Mechelen, 🇧🇪
CreditAttribution: borisson_ as a volunteer and at Dazzle commented
Status: Needs work » Needs review
Issue tags: -Needs reroll
FileSize
provide_a_facet_clone-2747593-17.patch8.02 KB

Reroll.

Status: Needs review » Needs work

The last submitted patch, 17: provide_a_facet_clone-2747593-17.patch, failed testing.

borisson_’s picture

borisson_
Primary language Dutch
Location Mechelen, 🇧🇪
CreditAttribution: borisson_ as a volunteer and at Dazzle commented 
21:25:09   [Http\Client\Exception\NetworkException]  
21:25:09   Permission denied
21:25:09   
21:25:09   [Http\Client\Exception\NetworkException]  
21:25:09   Cannot read the response

I don't think we did that?

borisson_’s picture

borisson_
Primary language Dutch
Location Mechelen, 🇧🇪
CreditAttribution: borisson_ as a volunteer and at Dazzle commented
Status: Needs work » Needs review
FileSize
interdiff.txt4.92 KB
provide_a_facet_clone-2747593-20.patch8.27 KB

Fixes the test and make sure that this works for all of the search api based plugins, not just views.

borisson_’s picture

borisson_
Primary language Dutch
Location Mechelen, 🇧🇪
CreditAttribution: borisson_ as a volunteer and at Dazzle commented
Status: Needs review » Fixed

Committed, thanks for the patch here @joachim, sorry it took so long to get this in.

  • borisson_ committed b7cbb72 on 8.x-1.x authored by joachim 
    Issue #2747593 by borisson_, joachim: provide a facet clone form

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.