I have three date facets (one for Y, another for M Y, another for J M Y).

It would be great if i could make the visibility of the more granular facets dependent on the less specific dates. So that i don't see January 2016 unless i've already picked 2016.

While my use case involved dates, i can imagine this being useful for other datasets as well. Eg "pick a state and then a city".

At the moment, facet visibility requires a specific value being chosen in the dependent block, where i would like the equivalent of "Is Not Null".

My workaround is to set visibility based on the existence of a query parameter.

Comments

kevinwalsh created an issue. See original summary.

kevinwalsh’s picture

Issue summary: View changes
borisson_’s picture

Version: 8.x-1.0-alpha4 » 8.x-1.x-dev

That sounds like a good idea!

simon georges’s picture

Status: Active » Closed (duplicate)
ekes’s picture

I'm going to put my comment here, because this is where I'll stumble over it when I'm working on this again.

The dependent facet is certainly one solution. It might actually make sense related to performance to then index the strings 'YYYY' 'YYYY-MM' etc.

The hierarchical solution probably wants the SearchApiDate query_type plugin changing. Because it's based on ranges, and it works only at one level of granularity at a time. So you can't have YYYY and YYYY-MM working at the same time. Again most efficient would probably be working out the granularity dynamically by (a) when collecting the factets together seeing if the value is in an active facet and then upping the granularity by one; (b) when interpreting the active facets just working out the granularity from the active facet string length.

ekes’s picture

Title: Facet block visibility dependency without a specific value » Hierarchy date facet: Year, Year-Month etc.

Re-purposing this issue for solving just the OP with dates, as I'm leaving notes here. Seems the hierarchy plug-in solution would also work better for dates stored in ISO 8601 than the unix timestamps.

15:27 < ekes> borisson_: Looking further. Dynamically changing the granularity 
              for a timestamp facet is fine; but then it would need -timestamps- 
              for the hierarchy to be indexed for it? That's how taxononmy works 
              right, gets all the parents and indexes them too?
15:29 < ekes> borisson_: So it makes more sense for indexing as iso string 2001 
              2001-01 2001-01-01 2001-01-01T01 2001-01-01T01:01 
              2001-01-01T01:01:01 
15:31 < ekes> With the timestamp it makes more sense, though still not so much, 
              to also dynamically make the facets for the hierarchy for 978310861 
              depending on granularity of present search.
15:32 < ekes> But I can't work out how, or if that would be possible. At the 
              moment we get 978310861 and return 2001 or 2001-01 or whatever, and 
              I can return 2001-01 if 2000 is active, but not 2000 as well.
borisson_’s picture

Status: Closed (duplicate) » Active

Reopening

borisson_’s picture

So, @ekes is very clear why this is not sufficient the way it is right now. I have no idea how to fix it in the correct way though.
Keeping this as an open tab in my brains but actively hoping for others to help out, at least to provide direction.

I think we might have to change the storage first? Should we open an issue in search api?

borisson_’s picture

danielveza’s picture

StatusFileSize
new20.29 KB

I've got this working on a clients site with a custom processor and query type, and I would like to be involved when this moves forward if time allows.

My symfony/drupal 8 development is still growing, so I'm sure it could have been done a different way. It all worked well except for the count, which I had to fake by doing a query to get the count for each newly created facet item. At the moment the code assumes too much about the site it's installed on for me to publish, but when I get some time I'll publish it without these details. Even if you can just tell me to GFTO :p

Lanaya’s picture

Hi @DanielVeza, I'm currently working on a project and I would like to have the same bahevior as what you have developed.
Are you still planing to publish what you have done?
If it's a question about cleaning code and make it more generic, I'm able to help you :)

danielveza’s picture

Yeah sure. I haven't thought about this in a long time. I'll publish the code to Github this weekend after cleaning it up. I'll just addd TODOs where I made assumptions about the site it was built on and we can look at fixing those.

The better option for this may to be make it a plugin module rather than part of the facets module. I suppose that's up to @borisson_ and the maintainers.

Lanaya’s picture

Ok, it sounds great !
And I think you are right about making it as a plugin rather than part of the module but let's wait for what @borisson_ has in mind :)

borisson_’s picture

Yes, we can always start this as an additional plugin and merge it in in the future. Thanks so much @Lanaya @DanielVeza.

danielveza’s picture

@Lanaya I've scrubbed and opensourced the code. NOTE that it won't even work a little bit in it's current state. There is plenty to do, that I've tried to outline in the README.

https://github.com/DanielVeza/facet_granular_date/tree/master

Oof, I forgot how much the code got away from me in the end on review of it. I'm going to start cleaning it up bit by bit.

Happily accepting PRs (it needs it!).

Lanaya’s picture

Thanks a lot !
I will work on these next weeks when I will have some free time :)

danielveza’s picture

Hey @Lanaya and any others interested in this. I've found a significanly cleaner way of building this while open sourcing this module than the hacky way I originally built this, so hold off any extra work on github repo if you're been doing anything, because it's about to significantly change. I should have it up in the next week, as a drupal module as well. I'll post it here when I do.

To stop clogging up this issue queue any more, contact me on github above ^ if you have any questions :).

danielveza’s picture

@Lanaya and others - I've published https://www.drupal.org/project/facet_granular_date. It has some cleanup still to do but I would love some real world testing.

For development - I've made an issue about one part of the system I'm unhappy with, if you would liketo contribute I'd love some help there and/or general code reviews! I've reworked this a few times now.

Any new issues related to this raise in the new modules queue - Thanks all!

mkalkbrenner’s picture

Version: 8.x-1.x-dev » 2.0.x-dev
Status: Active » Needs review
StatusFileSize
new6.92 KB

Since facets 2.0.x allows hierarchy plugins we can provide hierarchical date facets with less code compared to https://www.drupal.org/project/facet_granular_date

Here's a patch (without tests to keep the review small for now).
@DanielVeza it would be great if you review it.

  • mkalkbrenner committed 3034bb5 on 2.0.x
    Issue #2802571 by mkalkbrenner, DanielVeza, ekes: Hierarchy date facet:...
mkalkbrenner’s picture

Status: Needs review » Fixed

Status: Fixed » Closed (fixed)

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

vladimiraus’s picture

@mkalkbrenner I tried Hierarchy Date Facet plugin and it dumped everything - years, months and dates.
Is there way to do it same way as facet_granular_date module: only show top level until one is selected or selected level + 1?

facets hierarchy date

mkalkbrenner’s picture

Sure. You need to select the granularity, enable the date hierarchy and ensure that the hierarchy gets built before the date formatting happens.

Now the result looks like this:

vladimiraus’s picture

Thanks that worked. :)
I'll convert #3272851: Document setup of Hierarchy Date Facet into documentation issue.