🇮🇩Indonesia @gausarts

It is very good. I am already a bit uncomfortable to place competing markdowns in the recommendation, though.

This should be very useful at any rate.

Thank you anyway.

@jordik , thank you for your work!

I need to make taxonomy and other entities sortable as well.

I made it work for entities by replacing this line:

+    $column = $field_name . '_value';
+    $table_alias = $table . '__' . $field_name;

With this:

+    $field_definition = $this->getBundleFieldDefinition();
+    $column = $field_name . '_value';
+
+    if ($field_definition->getType() == 'entity_reference') {
+      $column = $field_name . '_target_id';
+    }
+
+    $table_alias = $table . '__' . $field_name;

If you could update it to support entities like above or any other way, that would be great.

Considering it is assigned to you, I would leave it to maintainers' and your consideration.

Good idea, thank you!

Features may be in when I or my clients need ones. Patches or 3-5 hours sponsors are also welcome :)

ATM, the existing Splide filter at text formats is available as basic CKEditor alternatives.

Try switching to Olive for a mo. It has a fixed header like yours.

See an example how to deal with fixed header:
https://git.drupalcode.org/project/ultimenu/-/blob/3.0.x/css/components/...

You may want to copy some rules if you have issues with CSS.

If you have issues with upgrade, I recommend you re-reading the CR linked previously. I updated with upgrade steps yesterday. Or stick to working version 2.x till you have time to update it, or use 3.x for new sites only.

See project home First things first, or here: https://www.drupal.org/node/3447576 →

In short, you must re-save both Ultimenu and it's block form, and tick the new options as required.

Slick 2.x and 3.x are exactly the same, 99.9999%. I made it so to avoid upgrade issues.

Only Blazy has removed depreciations, with minor services changes and JS improvements specific to BigPipe.

The issue here is Drupal 11, not Slick per se. And the solutions are here and there. Try using search box.

Understood, thanks :)

Another obvious change in 3.x is it is no longer relying on media queries for the most parts, instead on touch and non-touch devices, since that is the best way to spot hoverable states.

This helps reduces CSS complexity thanks to more precise detections. On the other hand, this has a minor consequence -- it no longer supports resizing which is normally done by devs, anyway, hardly end users. You can always use media queries should you need to support resizing, though.

See the CR above for more.

Pressing CTRL/CMD + M to bring browsers' responsive view is more reliable than resizing for devs.

We'll keep it open for feedbacks if anything useful to help better upgrades.

Good suggestion, thank you!

Thank you.

You might be right for particular usages, and I understand such a problem with this change.

However as I said in the docs, I don't worry much about CSS thingies :)

Hence in your case the solution is you should use more specific CSS rules with direct descendants to not leak to submenu links.

See examples here https://git.drupalcode.org/project/ultimenu/-/blob/3.0.x/css/components/...

/* Without direct decendants > to be inherited as needed. */
.ultimenu li .ultimenu__link {
  color: var(--ultilink-normal);
}

/* With direct decendants > to avoid submenus from inheritance. */
.ultimenu > li > .ultimenu__link {
  background-color: var(--ultilink-bg-normal);
}

The ultimenu__link was normally available for the first level menu, indeed, since we have no new features till 3.x.

Reasons for the new ultimenu__link in submenus as newly introduced in 3.x:

• To support <nolink> with consistent styling since it has no A tag.
• To support collapsible menus relevant to JS.
• To minimize confusing anonymous A tag without a class causing non-efficient and too many decendant usages since flyout may also have A tags.

Be informed, new branches allow breaking changes in designs and features so this change does not classify a bug.

The way you use CSS rules matter here.

There was a similar issue. Try searching your title keywords in the search box for details.

Slick as a module and Slick as library are two separate entities with different authorities, authorship, responsibilities, lingos, maintainerships, etc. I have said this many times.

I as the module author cannot acclaim to be responsible for the library's issues. That would add me unnecessary and irrelevant burderns.

Given a few possibilities, local patch, github forks, hardcodes, not to mention different version preferences and time constraints, I refrain myself from touching the library. However your and other people's contributions with relevant solutions are very much appreciated. Anything that works well with your workflow is acceptable and just great, go ahead.

Postponed to avoid more dups, not to do anything about this.

Thank you.

Thank you.

Local patch might be good till you have time to follow the CR:
https://www.drupal.org/node/3447576 →

Should you have 1 hour time, technically only two major changes:

• CSS, roughly costs you less than 15-45 minutes using thoughtful reversed search and replace via any code editors. Reversed means starting from more specific to global as opposed to written docs, thus replacements must start from is-ultimenu-canvas-off, etc. to is-ultimenu-canvas, not vice versa.
• Saving both Block and UI forms, costs 15 seconds.

I am interested to know why it would take you days so we can improve docs to help smooth upgrade?

Weird, I always enable syslog, dev, stage or prod, and have never seen OP.

However good find, thank you!

Let's keep it open to avoid more dups.

Unfortunately, no. It would be possible to fix this if I could reproduce it.

The problem is likely another module which triggers the issue, but I don't know nor have it.

OP issue is similar to the other one, only different in the service.

I would leave it open if anyone has the triggering module so I can figure out a reproduction.

Feel free to share a solution. Thanks.

I am not sure, AFAIK, circular reference happens when class A extends class B, and vice versa, which is not the case here.

Also the problem is both asset.js.optimizer and plugin.manager.block are core classes. We couldn't change them :)

Previous solution was to move plugin.manager.block service out of DI into static service call, and solved another circular reference issue at D9-10.

Now we have another different circular reference issue.

Just a long shot, what about moving the plugin.manager.block in UltimenuBase::blockManager():
https://git.drupalcode.org/project/ultimenu/-/blob/3.0.5/src/UltimenuBas...

into just UltimenuManager:
https://git.drupalcode.org/project/ultimenu/-/blob/3.0.5/src/UltimenuMan...

UltimenuSkin previously referenced it, but later disabled it due to D12 compat, still marked as @todo.

If that fixes the issue, it is likely the root cause.
If not, at least one suspect down :)

I was also thinking to decouple UltimenuSkin from UltimenuBase later, considering only three methods/services are being affected: ::config(), ::cache() and ::getPath(), and it should be fine to duplicate them in UltimenuSkin, only if necessary.

The current solution with view--blazy CSS class scoped to Slick/Splide and Blazy ecosystem as Views output addressed various use cases which might break them at one go.

The linked issue was quick and dirty solution which should have been removed once a more scoped solution was available, which is now in the latest Blazy.

There is a similar issue at Splide which has different CSS implementation from Slick's, meaning the CSS rule breaks any carousels/sliders, either with float or flex rules.

Your proposed solution doesn't address other themes, or Olivero sub-themes, and potentially adds more complex logic for a tiny mistake like this outside (sub-) Olivero.

The solution was already in Blazy, nothing else to do now.

Updating to the latest Blazy should fix the issue.

Should be marked as Dup, but Postponed to avoid more dups, not to do something else better :)

Thank you, anyway.

Thank you.

I just have time to see to it.

There is no significant difference between 2.x and 3.x in term of PHP, except for deprecation removals.
Unless I missed the obvious, of course.

However I saw no evil/ regression with Paragraphs in my installs.

For others who prefer Slick, few known issues/ caveats:

• 📌 Incompatibility with Drupal 11/jQuery 4 Fixed , fine at D10, though.
• Must use Paragraphs Revisions, else empty.
• Be sure to match the correct and supported Slick library versions, in case upgraded by mistakes. See Slick project home requirements → .
• Also see this very project home Usages, Gotchas, and adjust things accordingly. Using Media directly with Slick Views is less complex than Paragraphs, IMHO.

Good luck, anyway!

You are correct.

Try typing your would-be title keywords in the search box for details.

Updating should also fix it.

Thank you.

Try re-saving both forms.

Check out updating.

Also be sure to read the entire docs:
/admin/help/ultimenu

Let me know?

Thank you for contribution.

2.x is no longer supported. Thank you.

There is an option elementParse, we can move items into it.
A bit round trip, but the only way to support non plain img or any HTML like Picture/Responsive image, SVG, Video, Remote video, Pinterest, Twitter, Instagram, etc.

Almost similar approach to PhotoSwipe seen at Blazy PhotoSwipe with the same authors.

Not bug, just a workaround to the library limitation with items construct.
Thank you for contribution.

I extend my debug.

The basic is indeed fine:

jQuery(box).magnificPopup({
     delegate: S_TRIGGER,
      type: 'image',
      gallery: {
        enabled: true
      }
    });

After I changed delegate to items, the issue appears:

jQuery(box).magnificPopup({
      // delegate: S_TRIGGER,
      items: [
        {
          src: '/sites/default/files/2023-07/7umxppkjd1k-paul-itkin.jpg'
        },
        {
          src: 'https://www.youtube.com/watch?v=SlPhMPnQ58k',
          type: 'iframe' // this overrides default type
        },
        {
          src: '/sites/default/files/2021-04/as-build-Screenshot%20from%202021-02-18%2012-48-08.png',
          type: 'inline'
        },
        {
          src: '<div>HTML string</div>',
          type: 'inline'
        },
        {
          src: '/sites/default/files/2021-04/generateImage_bLt9oz.jpg', // CSS selector of an element on page that should be used as a popup
          type: 'inline'
        }
      ],
      type: 'image',
      gallery: {
        enabled: true
      }
    });

Both are the very basic construct like in the demo:
https://dimsemenov.com/plugins/magnific-popup/documentation.html

As suspected at #4, it might get confused for losing a correct selector when given items.
Unfortunately items and delegate can not coexist without errors.

Conclusion: the library issue with items in sliders.

Try searching at github with keys: slider or carousel.
I haven't been able to get what I was looking for.

Moving it to Blazy.

I just have time to see to it.

Looks like the issue is persistent for both Slick and Splide, not just Splide.
I have tried to check anything to do with Blazy MFP initializer, but no joy, so far.

It might be Blazy or the library, not sure.

We need to isolate the BLAZY MFP to the very basic construct with just LINK element via delegate option.
Currently it uses items object collection which appears to confuse MFP.

Feel free to debug the latest DEV file here:
https://git.drupalcode.org/project/blazy/-/blob/3.0.x/js/src/components/...
https://git.drupalcode.org/project/blazy/-/blob/3.0.x/js/components/jque...

Copy the non-minified content to the minified one, and start with the very basic construct as mentioned above.

Thank you for contribution.

Just to be sure for repros:
You didn't have Blazy before? Or you did have one?

The drush en blazy assumed you didn't.

> drush en blazy -y
I think I understand your situation. You didn't have Blazy before upgrade?

However to cover two scenarios, please follow both steps here.

If you DON'T have Blazy before:
Try downgrading to Ultimenu:2x first, install Blazy 2.x or 3.x, no problem here.

composer require drupal/ultimenu:^2.0 drupal/blazy:^2.0 -W -n
drush en blazy
drush cr
drush updb
drushcr

Downgrading modules doesn't pose issues, normally, as long you clear caches properly.
Then follow the next step since you have blazy enabled above.

If you DO have Blazy 2.x before:

composer require drupal/ultimenu:^3.0 drupal/blazy:^3.0 -W -n
drush cr
drush updb
drushcr

Note I didn't run drush en blazy on the last step since Blazy was already install at first step.

Just be sure this time it is blazy:3.x, not 2.x.
More details are in Blazy upgrade steps.

Check out Slick project issues.

It is a configurable option, not worth changing.

Thank you anyway.

The last found issue is here:
🐛 Slick Media Display on Commerce Product Variations not working correctly Active

With the fix:
https://git.drupalcode.org/project/blazy/-/commit/d1bb571a4f8b553a550c7c...

    // Adds bio.ajax to fix product variation AJAX within BigPipe.
    // Views AJAX will automatically work, however to support other non-views
    // AJAX, add more conditions to your custom hook_blazy_settings_alter.
    if ($type = $blazies->get('field.entity_type')) {
      if ($type == 'commerce_product_variation') {
        $blazies->set('use.ajax', TRUE);
      }
    }

Basically non-views and variation AJAX needs to load blazy/bio.ajax library only if BigPipe is present.
Implementing a custom hook_blazy_settings_alter as above should fix the issues within BigPipe environment.

Closing this for now.

What the fix did was only touching js-related issues, not CSS.
Leaving the obvious CSS re-order issue in the OP to BigPipe since Blazy nor any other modules can solve this last bit.

Should be fixed here.

I couldn't reproduce it with my current environment, including after upgrades from 2.x to 3.x.
See the other issue, which was triggered by another module existence.

However I removed/changed potential issues accordingly, along with minor unrelated issues.

We'll keep it open should anyone have a consistent reproduction. Then we'll close this if no more reproduction info.

Check out the linked issue for details.

Most of the CS issues were outdated.

Solutions:

• Update you PHPCS. Do not use global PHPCS, use per project instances. The call it in the Drupal root:
  

  ./vendor/bin/phpcs \
    --standard="Drupal,DrupalPractice" -n \
    --extensions="php,module,inc,install,test,profile,theme" \
    web/modules/d10/ultimenu
    
  ./vendor/bin/phpcbf \
    --standard="Drupal,DrupalPractice" -n \
    --extensions="php,module,inc,install,test,profile,theme" \
    web/modules/d10/ultimenu

• For CSS, use Stylelint. CSSLint was deprecated for stylelint. Call it:
  Checking for errors:

  npx stylelint "web/modules/d10/ultimenu/css/*.css"
  npx stylelint "web/modules/d10/ultimenu/css/**/*.css"

  Fixing the errors:

  npx stylelint --fix "web/modules/d10/ultimenu/css/*.css"
  npx stylelint --fix "web/modules/d10/ultimenu/css/**/*.css"

• For JS, use ESLint.
  

    // Located at /modules/contrib/ultimenu, run:
    // eslint . -o ../../eslint/ultimenu.html -f html

  See here:
  https://git.drupalcode.org/project/ultimenu/-/blob/3.0.x/.eslintrc.json?...

A good conflicting sample between old and new CS is this line:

FILE: .../web/modules/custom/ultimenu/src/UltimenuTool.php
----------------------------------------------------------------------------------------------------------------------
FOUND 1 ERROR AFFECTING 1 LINE
----------------------------------------------------------------------------------------------------------------------
14 | ERROR | [x] Use statements should be sorted alphabetically. The first wrong one is Drupal\block\BlockInterface.

The latest CS was actually the opposite of yours, and already committed here:
https://git.drupalcode.org/project/ultimenu/-/commit/f23a1323ff51badcf81...

It may confuse you since they are NOT sorted alphabetically. But it should make sense to put classes in core/lib directory at first rows, then core/modules, etc. It was the latest CS change.

Please refer to Drupal CR and docs for more updated info and details.

Thank you anyway.

Thank you for contribution.

Thank you.

Could anyone RTBC?

Thank you.

I haven't been able to see to it, nor have seen it before. But I understand your issue may be valid under certain circumstances about which I never had.

In fact, we had this type of circular reference issue before in this project, and already fixed, although I didn't understand why that happened since it was triggered by another module, and never had it myself.

Why? Because to my limited knowledge that issue happens when class A injects class B, and vice versa in circular reference. But we didn't see that in this module from the very beginning.

We had even removed DI classes for the most parts previously just to solve something bogus aka I didn't understand, yet simply works.

I suspected this is related to core issues somewhere but just haven't found the exact related issue for the proof :)

About failing service instantiation, it must be related to your failing caches. Be sure to follow the Update SOP procedure at Blazy.

This exact silly combo:

drush cr
drush updb
drush cr

After composer require ... never failed. If failed, be sure to update your drush, or see Update SOP for more.

If you have more info, please share.

Very helpful debug, thank you.

Two underlying issues I can think of without seeing it directly in a laptop:

1. Missing to include bio.ajax as proven by the addition of views AJAX block then it works. The bio.ajax is there, not sure how and if escaped in JSON format, but it must be there since that should trigger the library inclusion.
2. The only change between 2.x and 3.x is 3.x tries to be aware of BigPipe, but there is one tiny glitch I haven't figured it out, yet, that is the anomaly of Drupal.attachBehaviors and Drupal.detachBehaviors specufic to AJAX in BigPipe environment. While the current 3.x works for normal Views AJAX and Infinite scroll like IO pager and VIS, it might still miss with this particular non-views AJAX:
   https://git.drupalcode.org/project/blazy/-/blob/3.0.11/js/src/plugin/bla...
   This might explain the regression, and that is why I still keep the issue open:
   📌 Compatibility with BigPipe Postponed

However given Views AJAX it works, it should be the easier solution than pursuing such anomaly.

Till further fixes, you can use such a workaround if that works for you with BigPipe.

Patches are welcome in Blazy for better bio.ajax inclusion, then we can close this. FYI, I avoided harsh all-or-nothing inclusion like Responsive image AJAX which is similar workaround to bio.ajax, and prefer softer approach per usage basics, but it apparently creates issues and challenges. Maybe we should exclude admin pages to be less harsh, or just fix per usage as before, and add awareness to variation AJAX.

OK, would love to hear about BigPipe. It is the safest to (un-)install without any issues.

If uninstalling BigPipe fixes it, try the following before we work any further.

One more debug, on the troubled page:

• Press CTRL/CMD + U, or right click on the page > View page source.
• Press CTRL/CMD + F, and type bio.ajax or bio.ajax.min.js.

With or without BigPipe, check out its exact location, whether in standalone script tag, or included in the script JSON section.

If not exist, or inside JSON section (meaning mixed up), it might be the cause.
If exist as standalone, it might be 3.x JS regression.

If not exist, to put the blazy AJAX library there, whichever easier:

• Create a single block of empty view, enable Use AJAX on Views UI RHS under Advanced.
• Implement hook_blazy_settings_alter:
  https://git.drupalcode.org/project/blazy/-/blob/3.0.11/blazy.api.php?ref...
  $blazies->set('use.ajax', TRUE);
  More condition is in the blazies.field section of the $blazies object.
• Include it in your theme with proper scope: blazy/bio.ajax

Thank you.

> On initial load... the main image appears correctly. ...loaded by AJAX and the main image does not load...
Sounds like an unfortunate JavaScript regression, hardly PHP, then.

Please help narrow down and reply by exact numbers till I have time to debug it properly:

1. Is it D11, or less? See D11 compat issues and its workaround.
2. Uninstall BigPipe a mo. Clear caches, including pressing F5 or CTRL/CMD + Shipt + R to clear browser caches. Some browsers are stubborn by caches, especially AJAX contents. Any difference?
3. Verify the supported Slick library 1.6-1.8.0, see project home for fake/ misleading 1.8.0.
4. If using Accessible Slick, revert to original Slick.

Additional PHP checklists, might be unrelated, just to be sure:

1. Is it EleveateZoom Plus? Or plain Slick?
2. At Slick 2.x, did you enable "Use theme Blazy" option at Blazy UI /admin/config/media/blazy_ui? If disabled, try enabling it at 2.x, and see if that causes it.
3. I don't know how you setup your Slick -- Vanilla, Responsive Image, etc. Try minimal setups without Vanilla, without Responsive Image. Any difference?

Patches are welcome if any.

> double-drush-cr many times to avoid the WSD
Be sure to update your drush.

I did notice your drush issues during likely drush 9-10, not sure. I even wrote a notice at project homes to use the good old Drupal UI if CLI failed. Some people at later drush versions thought I made up things with CLI failures. Now I see you had similar issues like mine years ago. And also see few others.

Updating drush should avoid multiple drush cr, but twice is still needed in between drush updb.

The reason for double drush cr was explained in the docs.

Failing to clear caches might also involve permissions of the folder where PHP is dynamically generated. Check out your sites/default|blah.com/files/php, see Drupal folder permissions documentation in general for more accurate info.

> It appears to be something to do with the way Slick is calling the Blazy code?

As noted in the above link, your #3 issue had been properly identified and documented. It is all about cache.

Failing to clear caches properly, you'll get a brick.

The combo drush with the mentioned silly sequence is the only cure, never failed.

However, if you don't drush, the Update SOP covers it with plan B and C, just as well.

Checkout Update SOP:
https://git.drupalcode.org/project/blazy/-/blob/3.0.x/docs/UPDATING.md?r...

This combo an sich:

drush cr
drush updb
drush cr

after composer require hardly failed.

Be sure to follow upgrade steps as noted at project home, which points to Blazy:
Upgrading from 1.x to 2.x or 3+

The above suffices, however only if you got a brick, see WSOD section on that link.

Thank you.

The messages says it all, try:
composer require drupal/slick_extras:^2.0 drupal/slick_views:^3.0 drupal/slick:^3.0 drupal/blazy:^3.0 -W -n

Add more as required.

Basically you must explicitly composer require the modules that were spit out in the message.

Try consulting composer documentations for details. This project has nothing to do with composer for real.

Thank you.

I haven't been able to see to it, just FYI, Blazy does not require Magnific popup module to be installed, only its library is needed.

See /admin/help/blazy_ui > LIGHTBOXES section.

Not sure if related or conflicts, try uninstalling the Magnific module, and see if persistent.

Thank you.

Patches are welcome :)

Alternatively, if you or anyone could sponsor the feature for USD120, I'd be happy to work on this.

Hope that sounds fair.

Let me know?

Thank you.

We don't.

You can run:
grep -r "polyfill.io" ./modules
grep -r "polyfill.io" ./themes

or any other suspected folder:
grep -r "polyfill.io" ./profiles
etc.

Or use your code editor to search your entire codebase accordingly.

Blazy and Cash modules do have polyfill.min.js, but no external file URLs like polyfill.io.

Removed the quick-dirty rules.

FYI, the fix is still needed, otherwise Slick has gargantuan width and height.

Only now left to Blazy to be more scoped, and should no longer bleed.
If for some reason the gargantuan width issue crops up somewhere else, Blazy scoped rules fail due to being too scoped.

To solve the issue, simply copy the removed rules, or adjust the ancestor selector to not have problematic grid rules, into your theme as needed.

Thank you for contribution!

Thank you for contribution!

Thank you for contribution!

For documentation purposes, I forgot to emphasize the reason for those useful classes as it was mentioned there:

> Remove useful classes for DOM diets when you can get rid of Field, Block, Views, etc. wrappers so you have context for styling.

As I said I am a big fan of @mortendk.
In a strict DOM diet, I normally clean out block and views wrappers whenever possible leaving these field classes are the only contextual and useful classes to work with. Possible means not always applicable like in Views AJAX, nor when running out of dev time.

Meaning, it might cause a bloat as you perceived initially, but has a nobel usage for a bigger strict diet plan in essence.

Anyway, that is what the option is for, to satisfy both scenarios :)

Makes sense. We can always consider this later. However till I have more free time for open source works, I prefer not to fix non-broken codes, or non-major broken codes that already have UI fixes :)

It is always a breeze seeing kindness around my projects. Yes, that is why I am still here after 10 years of insults, I also saw many good people around like you :)

Thank you.

Good idea, but that might break existing installs which already utilized those classes, although it looks like very minor and can be solved by toggling this option.

We should minimize disruptions because not all people can communicate an issue in a civil manner like you did. I have enough rambling tyrants around my projects, and any disruption, even minor, will invite them to make it as a valid target for unnecessary strikes. These tyrants are not only abusive in adverbials and adjectives, but also not paying me a dime for using my works which is perfectly fine since they are open source, anyway.

I am fairly happy now, I saw more and more contributors can speak with data, and focused more on the underlying issues than useless gossips or side kicks.

Thank you.

You are correct about DOM diet. I am glad you are aware of it.

However it has always been Blazy's concerns since the initial devs, and your particular OP issue been made an option later.
You can remove these classes at /admin/config/media/blazy

Remove field/ view wrapper classes
> Remove useful classes for DOM diets when you can get rid of Field, Block, Views, etc. wrappers so you have context for styling. Other required classes: lightbox, grid, etc. are intact if so-configured.

Another obvious useful DOM diet you might not notice is the removal of field containers:
.field > field__items > .field__item
to just:
.field

I know some people disagreed, that is why a hook_alter at Blazy is provided, and also an UI option is provided at sub-modules:
Slick, Splide, Blazy layout builder under Use theme field or Use field template options.

About the same classes logi
The same multi-value field will output the same classes whenever being split as an individual field block foe example when using blazy option By delta. That is the correct logic, no bugs. However each is unique as output. To prove its uniqueness, make each field output of the same field using Media switcher > Colorbox. You'll get individual unique field rendered correctly with its unique colorbox ID. Press F12, Inspect element the field container, and see its different ID.

Feel to contribute any more improvements, just be sure to read the entire docs at /admin/help/blazy_ui and /admin/config/media/blazy to avoid unnecessary dup efforts, and save yourself your precious time.

You are correct. Do not hesitate to post any more improvements you have in mind in another thread.

That would be very much appreciated!

I just have time to look back, so for documentation purposes:

https://git.drupalcode.org/project/drupal/-/blob/11.x/core/core.services.yml?ref_type=heads#L1691
library.discovery.collector:
    arguments: ['@cache.discovery', '@lock', '@library.discovery.parser', '@theme.manager']
    class: Drupal\Core\Asset\LibraryDiscoveryCollector
    deprecated: The "%service_id%" service is deprecated in drupal:11.1.0 and is removed from drupal:12.0.0. Use LibraryDiscovery instead. See https://www.drupal.org/node/3462970

Meaning library.discovery.collector is deprecated for library.discovery. Not the opposite.

You appeared to misunderstand the CR, and your patch did the opposite, and so it will break D12.

As I said manual deprecation works are prone to fatal errors, some due to misunderstanding, the rest are carelessness. Hopefully you don't post this type of issues anywhere else, or you'll break them. If you did, be sure to close them out.

But don't take it so hard, just so we are looking at things right. We all made mistakes. What matters, we correct them whenever we can.

Thank you.

> How urgent is updating ...
2.x was a transition from contrib Media to core one. It should have gone since contrib Media was being deprecated a long long time ago, years. No urgency, nor immediate forces, 2.x had been around for far long too much. In fact, delayed too much due to time constraints in making it matured enough.

Take your time, though.

> ... and what is really important to look for concerning compatibility?

1. D8 is dead. D12 is already rising. Anyone should update to higher versions anytime. No negos.
2. We had fatal error issues against PHP8 vs PHP7 compatibility. I cannot afford supporting PHP7, anymore. People speak nasty with fatal errors, and I have to reduce such issues for my own mental health. I am a very kind and sensitive artist, and I love around non-toxic, good and supporting people.
3. Upgrade documentation has been provided and socialized for quite a while.
4. 7k successful upgrades convinced me enough to move forward. It says 3.x upgrade is working properly.
5. I no longer have enough free time to maintain things I no longer use when their replacements work just as finely and more stable, see successful upgrades.

Should you have troubles in upgrades, do not hesitate to post them to benefit others.

Just be sure to read project home Upgrade section.

I hope you can move on and forward, too :)

I haven't got time to investigate this issue. However, your proposed solution fixed the issue, while mine still failed.

Committed with minor failsafe cleanup.

Thank you for contribution.

Thank you.

Looks like you are upgrading from 1.x to 2.x without proper steps?

Always run:

drush cr
drush updb
drush cr

The second will update your database with the missing config you mentioned.

See Blazy help for updating across the Blazy system which also applies to to all modules in general:
https://git.drupalcode.org/project/blazy/-/blob/3.0.10/docs/UPDATING.md?...

Thank you.

I haven't checked this feature, yet, but looks like you missed a quote.

> següent', first'
Missing quote? Should be:
següent', 'first'

Thank you.

I don't see Slick module codes in the warning message.

The calling site is local.module.

Looks like it doesn't properly checks for the Slick library folder existence before calling its containing file.

As an example to explain "properly" above, we did check it properly here:
https://git.drupalcode.org/project/slick/-/blob/3.0.3/slick.install?ref_...

Unless the caller is this module,
please report it to core issues instead. This module cannot fix other module's code.

To entertain a bit, warning should be fixed, but it is not qualified as an error, meaning hardly major.

Quick solutions:

• Disable warning reports at production as it should me. Enable logging instead.
• Put the required file until the actual fix, although unnecessary for sure.

Failing to match the expected versions will cause issues.
More detailed in the main Slick → project home requirements.

Thus reading any module project requirements should help get you up and running quickly without problems.

The issue turned out to be the exact version requirements.

Failing to match the expected versions will cause issues.
More detailed in the main Slick → project home requirements.

Thus reading any module project requirements should help get you up and running quickly without problems.

The previous answers to focus on and separate Media field formatter which handles the link from Slick Views should fix OP.

However should you want to use the hook_alter, that will do, too, but not as robust as Link inside a Media formatter.

For reasons:
Link in Node will only have one link applied to all Media items, while Link in Media will be unique to each Media item.

However up to your design requirements, if that serves your purpose.

Thank you for contribution.

Thank you for contribution.

Already so:
Module categories: Content Display, Developer Tools, Integrations

Thank you.

Thank you for contribution.

Thank you for contribution.

Removed Content Display for Integrations, since it apparently integrates with native browser features as well.

Thank you.

The current:
Module categories: Content Display, Media, Performance

We can no longer use Integrations, since Blazy library had been no longer a requirement since D9.

Let me know?

Thank you for contribution.

Thank you.

Changing the supported Drupal versions is not necessary in this particular context.

For cross-version compatibility, removing the constructor and using static::create() method instead would be less disruptive and more efficient like Blazy here:
https://git.drupalcode.org/project/blazy/-/blob/3.0.x/src/Form/BlazyConf...

FYI, major version compatibility is always a Task, not bug, otherwise the entire lower version Drupal 10-9-8 ecosystems are bugs which is not the case.

Feel free to update your patch.

On second thought, makes sense, out-of-scope rule is not right. It was more a quick and dirty fix to D10 Olivero integration.

IIRC, the latest Blazy in 3.x already sniffs for Slick and Splide in Views, and provides the more scoped CSS rule overrides.

So this Slick kill-em-all rules could be removed later after another check.

Thank you for good communication and keeping civil!

That spots the issue better, thanks.

Let's make it clear:

• The fix is fixing core Olivero integration problem, and it works for core OOTB stuffs. We cannot nego core stuffs for now.
• I understand it breaks your previous custom works, but you must understand it is your own custom works. We are concerning more about the most common use cases here, things like OOTB. Core integration wins over custom works. That is the ugly truth you might never hear nor want to. And the fix corrects it very well.

This might be a regression to old D9 context, but not a bug in D10 context.

It fixed the new bug introduced by Olivero at D10. Without the fix, similar issue like Splide's would be reported here.

Solutions:
Just update and override that rule in your own custom CSS, be sure to have more specificity or exact CSS class to avoid issues at other areas to win over this module.

I hope you understand such a situation.

Thank you.

Mind screenshoting before and after for better spots?

I don't always have laptop nearby.

About the reason, the convention is any modules should work with core defaults OOTB, hence Olivero is D10 theme default. Unlike the previous Bartik, Olivero is very advanced in CSS, thus posing more advanced challenges to contribs. The explanation is right above the fix:

/* Fix for unnecessary Olivero Grid surprises causing Slick excessive height. */

The problem also happens at Splide slider. Normally as a Views block and in a grid. No problems are outside these two conditions.

The actual problem:
Both Slick and Splide have massive widths, only hidden partially to make sense in sliding displays. It was fine so far, until D10 Olivero adds problematic CSS rules, and to my investigation, pretty much useless, that is by allowing the child elements' widths to expand beyond its parent and reveal excessive widths and heights, while they should be hidden in the case of these carousels.

However I am interested in seeing your actual by-products.

Thank you for contribution and patience.

I don't bother much about admin previews.
Assumed no problems.

Thank you for contribution and patience.

Thank you.

Deprecation jobs are normally taken care of by Drupal Rector.

Manual works had been proven to fail and cause fatal errors somewhere as seen at Slick project, etc.. Not always, but a few times. Even when they were harmless at first glance. We should avoid wasting energy for manual works whenever bots can do better and safer jobs, specific for depreciation issues.

With due respects, I didn't want to repeat terrible experiences. Worst when the patchers didn't care enough to reply to my questions on the affected subject matters. I am a very patient man, I asked them six times very patiently and respectfully, and each question had never been replied properly, and when later I applied their patches, boom, I got errors somewhere they didn't even bother to answer in the first place. He repeated the same arrogant patches without explanation at this module, and I could no longer be patient. People who never read the entire story might think I was impatient, but rest assured I am a very patient man until the seventh annoying repetition. Be warned, I might reduce it to the third like other normal people once in a while, though.

You are good at communicating the problems and potential regressions, thank you! The previous patchers are horrible at communications. They should learn from you how to communicate an issue.

Please focus your efforts on helping other areas instead. Yours is useful for those in urgent need whenever bots come too late to party.

Appreciated, nevertheless.

Thank you.

This has been properly documented in /admin/help/slick_ui, README, and a few dup issues.

Accessibility issues (tabindex, etc.), and many more internals are initiated and managed by the library, and thus solutions should go there, not here. This module has fixed a few minor library issues so far, we cannot add more. It is better handled by the library, anyway, so to have clear responsibilities, and avoid potential conflict of interests.

Let's have things clarified, as this issue is frequent:

• Slick library manages its own internals at github.
• Slick module at drupal only provides an integration with Slick library, and cannot touch the library internals.

They are two separate and independent entities in term of internal management, although this module depends on the library.

Solutions:

• Report it to Slick github project for permanent solutions.
• Try the WIP Accessible Slick. Beware the fitfalls mentioned at project home.
• Try Splide, some reported better accessibility supports.

Yes, failsafe (the linked setTimeout function block) already failed, and should be ignored for now, as said.

What about adding the check, wrapping the body function, as in #3?

Thank you.

.one() will be executed once, best for anything executed once like AJAX content replacements, not suitable for this intention which may still be needed to be accessible at the next round.

Looks like the failsafe failed here:
https://git.drupalcode.org/project/blazy/-/blob/3.0.10/js/src/components...

The underlying problem may be event bubbles from child elements screwing it up. Perhaps another check is needed to wrap the entire body of the function, https://git.drupalcode.org/project/blazy/-/blob/3.0.10/js/src/components...

var transitioning = function (event) {
   if (event && this === event.target) {
     // the current body function 
   

}

If that works, the failsafe can be removed, but not necessary for now.

@sourojeetpaul, I am with you :)

I'll arrange some time this week, and close this.

Ok, 512px is good, then :)

One last question, @sourojeetpaul:
Which one do you want to place at this project home?

I thought the last would be more recognizable, but apparently not due to confusing small letter "s". Intriguing positively and interesting nonetheless :)

The second one is more recognizable and beautiful:
https://www.drupal.org/files/issues/2024-08-14/Slick-Paragraphs-2.png →

We'll keep it open for a mo to hear others' feedbacks before I can place it at the project home.

Thank you for your works!

To be clear and minimize efforts, perhaps a combination of letters:

• Slick P
• S P

Whichever looks prominent, I would leave it to your best design choice.

It is good, but I am afraid a bit more complex for a logo, IMHO.

Just my two cents, maybe a minimalist logo is more prominent, no descriptive accessories are needed as previously mentioned.

I was thinking about just combining the two logos of Slick and Paragraphs with a single color so to be more coherent or integrated to depict more about integration idea.

Anything that is still recognizable as a favicon is normally a so-called minimalist.

We'd love to hear what others' feedback on this, as well.

Thank you.

Not clear, but solutions exist.

Depending on your setup: entity, vanilla, media, w/wo views, etc. formatters, the existing solutions might confuse you.

At any rate, the quickest solution would be just using Blazy PhotoSwipe sub-module.

Applicable to both Vanilla and Non-Vanilla formatters as long as you are not confused by nested view modes.

Then you can have a regular Image to PhotoSwipe option under Media switcher option.

Good catch. Never thought about external URLs.

Patches are welcome.

Thank you.

@sourojeetpaul, #5 is cool, thanks.

However as @kristen-pol said, it might need a little more association to Slick or Paragraphs modules.

Their logos exist.

If you could incorporate or just combine Slick and Paragraphs logos in a coherent design/ association, that would be more recognizable, not necessarily descriptive.

Thank you.

Thank you.

It is a limitation of the current /io/block AJAX page.

By limiting to a particular node type hence a "type" of the node you restrict it to /node/123 only which will never meet nor include io/block path.

The same problem arises if you also put your block at views pages (/my-view-page, etc) where they have no node context to associate with.

The only solution for now is to just use Pages using path visibility.

I assumed this was fixed with the latest guerilla fixes.

If still an issue, please try 3.x, and feel free to update the report.

Thank you.

Thank you.

It is a WAD to reduce DOM nested divities like:
.field > .field__items > .field__item > .gridstack

Into just:
.gridstack

However to use theme_field, you can implement hook_blazy_settings_alter, and add:
$settings['use_theme_field'] = TRUE;

Be sure to add proper conditions accordingly using the provided $blazies object, otherwise it will likely break other displays in the entire Blazy ecosystem.

This would do for now.

About the future, tests are the best bet, but no resources for that :)

On third thoughts, this should be addressed by CSS like #2 and responsive image to add enough room by padding or image styles to not fill up the entire screen at any devices.

The library has mobile supports, anyway, thus hover and scroll is not an issue.