Can not define "Slick ID" in slick views since version 2.10.0

Thank you.

May I know what exactly and how is Slick broken:

1. Is it CSS styling using IDs?
2. Or something else?

ID had been deprecated for years since blazy:2.2:
https://git.drupalcode.org/project/blazy/-/blob/8.x-2.2/src/Dejavu/Blazy...

> . Do not use this! Leave it empty, this option will be removed at future versions. It brings trouble than useful.
Old description: Manually define the container ID. This ID is used for the cache identifier, so be sure it is unique. Leave empty to have a guaranteed unique ID managed by the module, or if you see similar views while should be different.

Note the word: versions, not branches. Means immediate, but in fact already delayed for years.

There are reported issues about this problematic ID option, so removal is the best route.

Well, the removal breaks a key feature oft slick itself: when using the asNavFor in the optionset, that requires the ID for the view. If that's missing, the feature is broken.

Hm, I don't understand how it would break :)

As noted, IIRC from the early days of the module D7:
> Leave empty to have a guaranteed unique ID managed by the module...

ID is always managed by the module, setting it or not. And strongly recommended to be empty.

AFAIK, it was initially there inspired by Flexider. But later some reported issues with dup stale slides, etc.

Removing it makes no difference.

As seen in Slick Examples, 4-5 out of 6, IIRC, are asnavfor sliders. They work fine without even setting IDs.

However should you need to have different ID for a reason I am aware of, try the provided hook_alters, see blazy.api.php, and set blazies.css.id or even settings.id (deprecated) as needed, or perhaps hook_preprocess_slick() is more direct.

If views, hook_blazy_settings_views_alter().

In the linked issue is was taught by yourself that I have to use those IDs that cross reference to the IDs in the option set. If there is a different way, I'm happy to learn about it.

AFAIK, this is unrelated to blazy or any other third party. Its only about slick and slick-views

I just re-read the link issue :)

You are correct I suggested a workaround for Vanilla asnavfor which was never supported in Slick, but is in Splide.

However, still it is a workaround to the limitations of Slick module given Vanilla and asnavfor, mostly due to my limited time to work with this particular issue, and its ramifications. Unless somebody is willing to pay me for 2 or 3 hours, of course :)

Not an official supported methods.

And that was 4 years ago, before people likely reported issues with IDs, and deprecation, or in between, not sure, not checking the exact post dates.

But 4 years are way old an issue, I am afraid.

However positive not the end of the world, as noted, in my previous comment above, perhaps overriding ID via hook_alters, or preprocess is the most straight forward replacements to the gone ID UI?

Assumed you don't change your IDs in optionsets, just replace this module IDs with/ based on your asNavFor values.

Something quasi:
If optionset name is samplenav, set ID as samplenav.
If optionset name is maindisplay, set ID as maindisplay.

They should bring back your vanilla navs.

If you want to avoid this hustle in the future, try Splide. It supports navs for asnavfors.

Well, we do have tons of high-profile customer websites, all being dependent on Slick. I don't see that we can replace that any time soon. All our default website profiles are based on Slick components. Changing direction here is such a big task, I don't even want to think about that.

Don't get me wrong, I'm genuinely grateful for all your work with Slick. For us, this is the one-and-only solution for carousels, sliders, and the likes. I do recommend it in meetups a lot. So, please don't push me to something else ;-)

Using hooks is certainly possible. And I know how we can do that. However, for site builders we usually try to avoid writing code. We often have to create new sliders on live websites, and the beauty has been, that a site builder can do that themselves, without having to ask a programmer.

So, my question would be, how would we do something like https://www.seehallen.ch/de/areal#impressionen with configuration in the UI with Slilck and Views? Is that still possible somehow? Note that on the linked page there are a number of sliders, each of which do have different IDs so that the correlation between the slider and their thumbnails remains unique.

> UI for site builders
Makes sense.

Not tested, just guesses for now, not guaranteed to work, but worth a try:
perhaps bringing ID form item back via hook_alters related to forms in blazy.api.php may do.

Some sub-modules put their own form items in any blazy-related forms.

Check out elevatezoomplus module for real life samples. Or the easiest is Splidebox module which adds Ajax link to any blazy supported lightbox forms.

Just be sure to limit scopes to Slick, or any reasonable to have ID to not leak to other sub-module formatters you don't want to support.

3-4 requirements are mentioned in blazy.api.php doc comments: hook_alter, schema alter, scopes, the form item itself.

If you can make it work, this should be good.

Otherwise, the previous comments via preprocess or other alters apply.

Let me know how it goes?

In addition to the 4 requirements, the following may help.

Good news: setting.id is still consumed here:
https://git.drupalcode.org/project/slick/-/blob/8.x-2.10/templates/slick...

Bad news: id is obfuscated and overriden here:
https://git.drupalcode.org/project/slick/-/blob/8.x-2.10/src/SlickManage...

Then store it here in blazies.css.id:
https://git.drupalcode.org/project/slick/-/blob/8.x-2.10/src/SlickManage...

Breaking news: to override such overrides, two extra steps:
1. Store settings.id early in says blazies.css.original_id via hook_blazy_settings_views_alter(), etc.
2. Replace blazies.css.id and settings.id in hook_preprocess_slick() with your blazies.css.original_id. If needed, be sure to reflect/ account for main and thumbnail displays via settings.display condition.

This ID ends up here: https://git.drupalcode.org/project/slick/-/blob/8.x-2.10/templates/slick...

Jumping directly to override $content_attributes with blazies.css.original_id (if not empty!) may also work.

Hope that helps.

This is an unfortunate optimization byproduct and a problematic ID option identified later, I am afraid.

One thing for sure, the risk of workarounds is fragile, and can be gone and forgotten anytime.

I have said what I had to say above and also in the linked issue, including alternative solutions. If any betterment, they can go to 3.x.

3.x is out.

Any contribution should refer to the provided docs as outlined at project home:
https://git.drupalcode.org/project/slick/-/blob/3.0.x/docs/CONTRIBUTION....

Thank you.