🇮🇩Indonesia @gausarts

I couldn't reproduce it last time, but the fix was already in the latest Blazy.

• What is Blazy version?
• Still an issue after updating to the latest Blazy and cache clears?

Other people experienced this as noted in core issues, so it is a known BigPipe issue.

As noted in the parent issue, changing it directly to core once, caused more issues in more complex AJAX setups. The current workaround which should finally be removed has helped reduce those extra issues. The workaround is still needed until core fixes the issue which is now closed as outdated, but unfortunately I could not find further info for D11, yet.

I haven't rechecked the latest D11 fixes against D10.

We'll reopen Blazy parent issue later after your reply to my questions here.

Thank you.

More info please:

• Cache cleared -- drush cr drush updb drush cr?
• What Blazy version?

Anyone has this with D10? It was fine at my end before the latest releases.

No significant changes with the latest except to support complex AJAX setups with BigPipe enabled that is to automatically load Blazy AJAX when AJAX is enabled or around. Just like Core responsive image enabling its AJAX helper, only conditionally at Blazy.

The outdated core issue referred to D11, leaving D10 in the dead end :)

> And to be clear, I don't want to demonize Blazy ...
Sounds misunderstanding :)

The context is users' needs -- yours vs the rest of users who may have no time or resources to mess up with Vanilla option which might also require some hard-codes or more complex works with nested formatters, etc. Not all people have code kungfu, complex site building needs, or even resilience like you.

Replace "devil" with "other people's needs" to make sense. The links are to confirm their needs are real unless you prove it otherwise.

But no biggie. Feel free to re-open if you found anything.

Thank you.

> do not use the sizes attribute
What happens if you use it?

Patches are welcome.

> Since we have switched to native (image) lazy loading, we mostly need Blazy as a dependency of Slick, so we aim to reduce the overhead as much as possible by default.
By seeing scripts, it looked like you still require Blazy features somewhere else unawarely like your previous Blur :)

A few more to do:

• Disable script-based lazy load at Blazy UI > No JavaScript > Lazy load.
• Only if the above insufficient, disable Views AJAX, if not actually used and if Blazy is called.
• Disable Lightbox option.

Technically, only 4 of Blazy scripts when all features are turned off:
https://git.drupalcode.org/project/blazy/-/blob/3.0.x/blazy.libraries.ym...

Thank you.

You can disable many polyfills at Blazy UI, more by disabling features you don't need:
Blur, Lightbox, or even lazy load scripts.

It is called plugable aka modularized scripts. They won't be loaded until you add features which require them.

In fact you can have no scripts loaded at all at its very basic setup, just like core, says with Slick.

Start from a simple Blazy image setup to mimick core, and disable JS at Blazy UI, and other features.

Only add one feature at a time, and see more scripts are loaded as required.

All in all, those amount of scripts are tiny scripts except dblazy.min.js which is around 11kb, and even less when gzip, normally half, or less.

Don't worry about the amount, you can always make them all as a single file when you enable aggregation at production mode. Worry or careful about what features you ask for instead :)

More description in each form items.

Let me know your findings?

Let's focus on 2.x+.

Thank you.

One last two standing issue down. \o/

Thank you all for kind and quality contributions!

Thank you for contributions.

Good idea. Thank you, j.!

Blazy did polyfills, never thought about it for this issue. The best solution to fix Slick libre, however I don't mind 0.N kb, less works for most users, at least.

Feel free to make a patch in Slick.

To benefit others and avoid potential weight issues with BigPipe, please make it fixed at -19, below jQuery:
https://git.drupalcode.org/project/drupal/-/blob/11.x/core/core.librarie...

And use the minified version, while keeping the non-minified in js/src folder for convention since core minification is less robust:
https://git.drupalcode.org/project/slick/-/tree/3.0.x/js?ref_type=heads

Feel free to use online JS compressor, normally better than IDE.

Thank you.

For future compatibility we should remove the constructor entirely, and rely on static ::create() to allow Core change anything later. new static() is a best practice in Drupal. Many samples are in Blazy environment. The closest is Ajaxin:

https://git.drupalcode.org/project/ajaxin/-/commit/a09e840fd0d3ed5ea395a...

Or here is the final result for better read:
https://git.drupalcode.org/project/ajaxin/-/blob/2.0.x/src/Form/AjaxinSe...

Feel free to update it.

Thank you.

> I think this should be highlighted more in the documentation.
Basically reusable stuffs like Image styles and skins are kept in Slick Extras. Removable stuffs are in Slick Examples.

That is the main difference.

Patches are welcome in another thread.
Thank you.

> But I couldn't still configure the slider to work with breakpoints...
Mind screenshot the UI form and the actual problem vs the expected to pinpoint the issue better?

Please attach the optionset to see possible misconfiguration.

Also does the issue happen with the provided Splide Example?

Thank you all for contribution.

Float for

slidesToShow

is not working with any Slick versions, including master and Accessible Slick. It will break some other Slick on the page as well. Simply revert to old integer if any issues.

However I am open to forks since those Slicks are hardly updated, also the linked issue is pointed to react-slick.

Committed with minor change as per #10.

Thank you all for contributions.

Looks like thread UI is still changing. The Merge button was there, then gone, then replaced by a link leading to a page, yet with no Merge button.

There must be docs for this new UI workflows, but can't find it yet.

Still looking for the correct keywords to search for this type of UI changes. No joy.

If you find the relevant instructions to merge, please share.

If UI is still mysterious, I might need to use CI later whenever I get a chance.

Just an FYI.

Still no Merge button.

BTW, does the patch still works for D10?

Let's see if RTBC make the bottom appear. If not, I'll need to search for DO issues with this UI change.

No worries :)

However I couldn't find the Merge button which was normally there.

I seem to lose the Push access, even after clicking the Get access button and a reload.

Might be the latest Drupal thread glitch.

I'll come back sometime later, hopefully the Merge button appears again.

> The missing piece was to uninstall BigPipe

FYI, 2 issues:

• JavaScript, was fixed locally by Blazy.
• CSS, not fixed, yet. Left to core for real solutions.

In short no need to uninstall BigPipe now, see:
https://www.drupal.org/project/blazy/issues/3361143 📌 Compatibility with BigPipe Active

The latest Blazy should be fine with BigPipe, except for complicated AJAX setup which should also be fine at least with the latest DEV. Please try DEV if any issues specific with AJAX setups, and confirm OK so we can release a new version.

The CSS reordering issue is core problem, and should be fixed there.

Warning was provided more as an FYI.

However not really fatal, IMO, only causes minor stylings like arrows styles being reset due CSS reordering, etc.

If you know CSS, a minor fix would do.

This CSS issue only happens if you enable slick for custom loaders at UI which is not recommended. If you left it disabled, no real issues, IIRC.

@mullzk, does the patch work?

Thanks.

Thank you for quality post.

Patches are welcome.

Thank you all.

Apart from the library, the optional word in the description might also be the hint to avoid confusion, so no correction is required.

Thank you.

The only reason it was removed for a single slider is to have a DOM diet.

However I understand a consistency might be needed somehow :)

Currently, if this must be in, we must also change the references in splidebox which assumed splide-wrapper ONLY exists as an identifier for navigation. If it is always present, it will break:
https://git.drupalcode.org/project/splidebox/-/blob/2.0.x/js/src/splideb...

Perhaps we should replace it with splide-wrapper--nav to be more precise.

Until then, you can copy the file into your theme if you don't use Splidebox, and adjust the HTML.

Actually I couldn't reproduce your issue with D11 and BigPipe.

But I understand the underlying problem as previously mentioned.

I added a new commit to avoid enabling Views AJAX without unneeded AJAX inclusion or risking a regression by modifying the existing scripts:
https://git.drupalcode.org/project/blazy/-/commit/62ec0b769337ef6aeefe78...

If you could test out the latest Blazy DEV and confirm OK, we'd probably have a new release soon.

Thank you.

Take your time :)

On second thought, enabling Use AJAX option at Views UI RHS, should fix it.

It is less expensive and problematic than any proposed solutions above. More efficient than loading AJAX scripts for all Views blocks.

UI fixes are equally valid as codes.

Pretty much similar to the linked issue, only less clear :)

Feel free to re-open if persists, though. Be sure to reply to my previous questions properly for better scopes.

Thank you.

> Slick sliders are not initialized for admin users
Is it only bad at admin pages, or any pages for admin?

We need more info to narrow down triggering contexts:

1. What Drupal version? Fine at D10?
2. Slick version according to the supported one? See project home for sure, also apply D11 fixes if D11.
3. Is it fine without BigPipe?

The only reason Blazy extended core once was to deal with known BigPipe glitches given various contexts: AJAX in infinite pagers vs regular AJAX, multiple calls/renders of BigPipe causing particular initializes (library/script loaders) messed up, multiple Slick sliders in infinite pagers, etc.

So the fix should go to Blazy, if later proven BigPipe, or in this module if anything else like D11 compat, etc.

Thank you.

> When visiting any page with a null route
What pages exactly without routes on where Blazy sits?

Thank you all for contributions and extra finding.

Good catch, thank you.

How about Url::mergeOptions():
https://git.drupalcode.org/project/drupal/-/blob/9.4.x/core/lib/Drupal/C...

Looks like less hustle and more compact in there?

Feel free to update it.

Two possible causes:

• Fill in Skin main with at least Default.
• Change Banner Image to a Blazy formatter, and tick or until Use field template option as described in the Gotchas above.

Clear caches as usual unless on a strict dev environment.

Read more on Splide Views section or at the previous previous Slick Views USAGES section for the supported and working configurations.

Be sure to follow the USAGES section strictly. Only break any rule once you master the ins and outs of it.

Let me know.

Looks like something change with perPage? You can play around with the expected number, whichever works here.

Please screenshot two forms:

• Views Splide Slider form
• Image/Media field form under Fields section

And we can proceed from there.

Thank you.

Be sure to follow and reply to each of the following so we both understand the underlying issue if none does not resolve your OP.

> I have a view using Splide Slider that is not rendering translated content properly on the front-end.
Is it a View style at the topmost format section? Or a regular field formatter at Fields section?
Read more about Views Gotchas in the docs, or at Slick Views similar Gotchas, and confirm if it fixes your issue?

> The view preview shows two results, while the rendered view always only shows only 1 result. This happens with multiple view blocks I have created.

See the output at your frontend, not Preview section due to narrow estate confusing your judgement, and confirm if that solves it?

Proceed your debug if the above doesn't fix the issue.

> If I set the Optionset to the Default, all English and French content pages are render. However, when I set my Optionset to Carousel, the French side always only shows 1 result while the English shows the correct amount.

Looks like a problem with your own understanding about how the options work?
Until you grasp it all properly, try the defaults which you said works:
mediaQuery: min, change it to max.
perPage: 1, to the 3 or so. This is probably your other issue.
breakpoint: 1024, change it to 1023, or 1025

Other potential issue is how you set up your language settings on the Views UI itself. To narrow down such an issue is to use the regular Node page with it's Manage display > field formatter. Thus you can rule/ single out your Views mastery from the proper judgment of the problem.

The best way to judge it as a bug to use the provided Splide samples. One of them has the same exact as yours, only different combo of options.

Let me know?

Thank you.

I have usages different from yours, relevant to various Blazy options (mixed media like local video, audio, document, iframe, inline HTML like pinterest, etc.) and sub-modules' specific features however I understand your scenarios.
Perhaps marrying both is less disruptive, a matter of option so to preserve BC.

The following may need proper checks, but a good start.

A permanent solution if you or anyone want to patch:

1. Create a new option at Blazy UI to offer using internal URL for hence [data-box-url] for video lightbox HREF url so that the next change doesn't affect or break initial design. This is the #url line to modify:
   https://git.drupalcode.org/project/blazy/-/blob/3.0.13/src/Theme/Lightbo...
2. To not break the old logic flow, access and store [data-box-url] into a new $href_url variable:
   https://git.drupalcode.org/project/blazy/-/blob/3.0.13/src/Theme/Lightbo...
3. Then change into IF ELSE:
   If UI option is enabled and $href_url is not empty, then put it as #url, else use the original #url line, e.g.:
   if ($ui_enabled && $href_url = $attrs['data-box-url'] ?? NULL)

Urgent solution is similar to above, available via hook_preprocess_blazy:
Check if [data-box-url] exists and only if a lightbox, to not break other options like Link image to content, to original image, etc., override it:
$variables['url'] = [data-box-url] value;

blazy.api.php:
https://git.drupalcode.org/project/blazy/-/blob/3.0.13/blazy.api.php?ref...

Sub-modules to explore sample variables and possibilities:
https://git.drupalcode.org/project/zooming/-/blob/2.0.x/zooming.module?r...
https://git.drupalcode.org/project/splidebox/-/blob/2.0.x/src/Splidebox....
https://git.drupalcode.org/project/slick_lightbox/-/blob/8.x-1.x/slick_l...
https://git.drupalcode.org/project/intense/-/blob/3.0.x/intense.module?r...
https://git.drupalcode.org/project/elevatezoomplus/-/blob/2.0.x/src/Elev...

Zooming is the closest to your need.
Moved to Blazy for the correct patch, if any.

Let me know?

Thank you.

Short answer: yes.

> In the media view mode I used format "blazy" image - and in the settings for "Media switcher" the option "Image to Slick Lightbox".

Directly set Media switcher on the active formatter, not it's media view mode.

If using Views, read Gotchas > Use field template:
https://www.drupal.org/project/slick_views →

Let me know?

@anybody, thank you.
The commit has nothing to do with the issue, CMIIW:
https://github.com/kenwheeler/slick/commit/b17846511cabf4572c696238a8765...

This module had fixed that type of issue since the first release 10 years ago as long as you allow the module to do the fixes for you via it's options:
https://git.drupalcode.org/project/slick/-/blob/7.x-2.0-alpha1/css/theme...

Anyway, please see the project home Broken vs working library versions. There are two fundamental issues mentioned:

• Default value of rows causing broken displays, etc.
• D11 issue as the OP reported.

Without addressing both, we'd better stick to working versions with solutions by having strictly supported versions and the other as proposed above by our good fellas of Drupal.

About co-maintainership, etc., I would better leave it to their best priority, and your minor efforts as provided-above on this particular issue. Unless somebody is willing to pay my time, of course :)

Thank you.

Much better explanation, thank you!

If the previous known "destroyed" state of a one item slide doesn't answer your OP, feel free to elaborate more.

In short, to qualify as a bug report, please:

• use the provided Splide X (not the potentially problematic custom works) -- start with basic image or media to minimize variables, clone the most relevant samples, adjust the amount, Optionset, etc. This way, we can have a comparable reproduction, no more guessing around.
• describe the steps more clearly, paste your optionsets, or any setups for easy reproduction.

By then, we'll have something to work with.

Should be fine with D9-D11 or up.

You can always run composer require, and it will tell you if any compat issues.

Thank you.

Splide is fine at my D11.

Possible solutions:

• Ensure the library version is correct and has no 403 or 404 errors, see project home requirements. Just open each script files in the browser, press F12, and see if any 403 message.
• Under Load Splide globally option, everything is fine, including empty, except Without Initializer which requires you to load the Initializer script yourself. Read more the description to correctly set it up. If unsure, just leave it to -None-.

Feel free to share your findings and solutions to benefit others.

My recommendations:

• Remove conditions (IF ELSE) in #5 above. Use Splide rendering except that now knowing and understanding that 1 item is destroyed (no more drags, pagination, etc.) as OP described.
• Install Splide X, clone and limit the amount of contents to 1 to replicate your problematic situation, and others to unlimited, etc. And see if any difference. You can judge correctly given a comparison aka well-informed which one works and not.

Please share your findings and solutions to benefit others.

> With Fullscreen and only one item in it: Not OK

What is it "Not OK"?

We need to understand OK meaning here :)

To validate OK vs Not OK, try testing with with Splide field formatter/Views style.
If it is OK, then the problem is yours.
If not OK, then both are actually OK.

Why? Technically if 1 item, Splide is being destroyed, no more sliding behaviors.
Thus its "brokenness" or being destroyed or "Not OK" is actually OK :)

One obvious missing line is #settings property in the individual item loop like here:
https://git.drupalcode.org/project/splide/-/blob/2.0.x/splide.api.php?re...

There a sample of Fullscreen, IIRC. Try installing Splide X, and see if OK with your designated contents.

> programmatically

• You might mess up reserved selectors. See Splide UI for different types, reserved vs custom. Hence splide--default should not be used for custom works.
• Your JS is not using custom unique selector. Similar to point 1, only at JS.

To prove/ validate such a conflict, put each at separate pages.
To have custom works play nice with core/default, see/clone the provided sample JS initiator/loader.

Thank you.

pagination should be true, your Breakpoint says:
pagination: 'false'

drag looks correct:
drag: 'true'
Not sure, why it failed, but possible solutions/debugs:

• Verify the library version is correct, see project home.
• Disable Override Main Optionset option at your formatter or Views style
• Press CTRL/CMD + SHIFT + M to access mobile version if using laptop/desktop
• Ensure you have at least 5 slides, if perPage is 4, etc.
• Install Splide X, and verify the samples work, or not.

Let me know?

There are options at /admin/block/ULTIMENUBLOCK like Always use hamburger or Use caret which appears to result in a conflict against your logic.

Try having the same menu (clones) with different/ conflicting options as above, but placed at different pages to immediately see if any regression.

If you or anyone can verify any combo of those options are good, that would be very helpful. Otherwise I may need some time to crosscheck them.

Thank you again.

Thank you.

Your fix should be in another thread, because #2 is more than your enhancement. I don't mind it here, though. We'll change it back to a feature after commiting yours.

ATM, there are two data.hover in it, please update them both. Not sure if moving it into var data will be equally working, other than more efficient. Feel free to decide.

You are correct.

Please read project home requirements and https://www.drupal.org/docs/getting-started/system-requirements/php-requ... →

Adding useless stuffs on composer.json is useless, and not sustainable.

Composer will tell you, anyway.

Thank you for contribution.

gausarts → made their first commit to this issue’s fork.

Thank you.

Possible solutions:

• See project home for the working version. 1.8.0 has two versions. Use 1.6.0 if unsure.
• Choose a Skin at the formatter.
• Start with and verify against Slick Example.

Feel free to re-open if none of the above works.

@trafo, thank you.

Please describe a reproduction.

Bugs must have a consistent reproduction. Without one, it might be glitches, personal overrides, and many other reasons, which may or may not be valid. Only reproduction can validate it.

Feel free to re-open or create a new thread.

Thank you.

> (yes, we upgraded / changed the slick library to 1.8.0)
Your issue had been identified for years. 1.8.0 has two misleading and conflicting versions.

Please revisit the project home for the working version which is also covering the issue with Drupal 11.

Alternatively stick to v1.6, the only least problematic version.

Thank you.

Yes, it is 3.x intentional feature to avoid CSS complexity with media queries device width detection.

Since 3.0.6, you can just as easily override the ulimenu CSS files if fine-grained layouts are required, see CR:
https://www.drupal.org/node/3447576#ultimenu-touch-replacement →

However I see a point if users want to make it optional, that is, to make a configurable breakpoint for different menu displays.

Feel free to patch, or chime in for 2-3-hour works, as a new feature.

I just have time to work on this FOUC.

Ultimenu:3.0.6 should got this cover.

More details in the updated CR: https://www.drupal.org/node/3447576 →

Thank you for contribution.

gausarts → made their first commit to this issue’s fork.

The latest fix should make empty Image style fetch the Fallback image as intended in the original description.

Postponed till the actual fix lands.

Feel free to contribute on the server-side fix, too.

Thank you for contribution.

I could reproduce your issue, that is, by leaving Image style option empty.

Meaning you will have original image as the SRC value (says 2000x2000 px, etc.) once 1px placeholder is replaced, while the printed dimension is based on the default Narrow Fallback image Max 325x325 (says 325x217).

Notice the different dimensions. This might confuse the browsers.

The good news is this only affects desktop. Fine at mobile, though.

Existing/ quick solution:

• Use a smaller Image style at Blazy formatters.

We also need to correct some logic somewhere due to the current Image style description which allows empty Image style without considering the dimension difference as noted above:

The content image style. This will be treated as the fallback image to override the global option Responsive image 1px placeholder, which is normally smaller, if Responsive image are provided. Shortly, leave it empty to make Responsive image fallback respected. Otherwise this is the only image displayed. This image style is also used to provide dimensions not only for image/iframe but also any media entity like local video, where no images are even associated with, to have the designated dimensions in tandem with aspect ratio as otherwise no UI to customize for.

In short, to make Responsive image work correctly with the current logic, without your patch, use a smaller image style, says Thumbnail or hence Max 325x325 to be similar to Narrow default Fallback image. Even when you see two requests at desktop, no real double downloads (different image styles), since the last is the cached version of the same image (one image style).

Conclusion:
The actual server-side fix would be to make empty Image style have the value of Responsive image Fallback image style as properly dictated in the description. But that would be for another thread when anyone have a spare time.

It is no bugs since the solution is there all along.

However I valued your patch as a client-side enhancement, that is when users leave the Image style empty till the actual fix lands.

I haven't been able to verify your findings. I hope you understood my previous comment.

However, feel free to update your patch.

• add a sizes variable, and wrap your line with a check if the variable exists -- a must,
• provide the minified version -- optional, I'll do it later if you don't.

Thank you.

ATM, there are three solutions to double downloads:

• At your Responsive image settings, choose Fallback image _empty_.
• At Blazy UI, tick Responsive image 1px.
• At Blazy formatter, choose the smallest image for Image style option.

More details in each form item description.

All the three options deal with the image controller aka SRC attribute, ensuring no unnecessary large images are being downloaded which appears to be your OP issue.

Regarding image SIZES attribute, it is not always present. The sizes attribute is only useful when using the width descriptors. If you're using the display density descriptors, you don't need the sizes attribute.

Let me know if the solutions fix your issue?

I am not a bot expert, however years ago, I created a PHP bot which consumed Envanto sites in scheduled and targetted batches, stored the results in DB, and displayed the texts after minor grammar and word spins along with images and videos directly in my own site. I also created a Python bot which consumed sites but dumped the text into JSON files instead along with images and archive files for further PHP processing. I also created a Java bot helped with JavaScript to render dynamic JS sites, stored the texts in SQLite inside an Android app, and displayed the texts, images, podcast files and videos directly in the app.

These bots are good when I know the sites' structures. When I don't, I can also use httrack, wget or a proprietary bot software.

These six bots I had worked with have one thing in common -- they only deal with dead HTML, and static files, even when they were initially dynamic like JS or PHP sites, etc.

However, I am open to learning about Microsoft bots which sounded to directly consume or read dynamic PHP per se, if any further explanation as requested in the previous comment.

Feel free to re-open. Or alternatively use robots.txt to block useless bots.

Wondering why bots would bypass human visitors.

Please clarify, did you enable caching at performance page?

Good find, thank you.

Please provide the repro, what pages you see it, and also the entire error message.

Once provided, you may want to wrap $route_name line as a condition instead.

> added the is-ultimenu to the classes in the template for my html element
No need, already taken care of. You can remove yours.

Only page.html.twig is required for an edit.

However seeing another FOUC, what about adding is-ultidesktop class via MYTHEME_preprocess_html() function, and add conditions as needed if not sidewide.

The default is is-ultimobile since I hardly have desktop versions.

Adding both classes should not be a major issue, since one will be swapped immediately when JS kicks in.

We should add an extra variable to this function later to check for Ultimenu existence for easy copy as a condition. Not crucial for sitewide Ultimenu.

If that works, feel free to create a new bug ticket.

> however, I have an instant of jumpiness on both mobile and desktop where the menu is styled wrong for a few hundred milliseconds before it straightens itself out.
Sounds like FOUC. Visit /admin/help/ultimenu, search for FOUC.

Or re-read the provided links in the CR.

In short, if FOUC, you must update your page.html.twig with the new off-canvas classes.

Good news, SDC is in core D11.

It is very useful for themers or frontenders who like to code or work with templates and love getting their hands dirty.

This module is currently more designed for site builders who love UIs -- blocks, fields, Views, etc. instead of hand-coding while allowing hand-code, as well, only unfortunately with esoteric Drupal internals as you already said.

They both have their own relevant users. They do almost similar include or embed under the hood.

As a themer, I used to love getting my hands dirty. I hardly get myself dirty anymore when UIs can save me more time given various challenges and repetitive tasks. Once in a while is fine, though. That is why it is re-opened and moved into Splide in case any further interest in this.

Re-opening this till anyone have time to contribute on SDC. Feel free to make sub-issues with early POC, or initial implementations. Patches or backers are also welcome. We'll close it back if no further interests, though.

OOT:
> ... so this isn't criticism ...
You might have the wrong version of me :)

Although I am not responsible for what people think, as a minor clarification aka FYI, I value constructive criticism as noted in the docs:
https://git.drupalcode.org/project/blazy/-/blob/3.0.x/docs/CONTRIBUTION....

The issue is some people just don't know how to draw a line between constructive, non-constructive criticisms and insults in an advanced civilization like Drupal.

Yours have been always constructive, I noticed, and appreciated as such.

Some strangers come to your house, and yell: "You are fat!" while these not-so-civil and not-very-helpful-even-for-themselves people don't know how to distinguish fat and fit.

You have a right to educate them with proper or actual facts, hush them away, or stay in silence, thus allow them to continue their bullies.

A wise man says: do not respond to bullies for your own peace of mind. Our imported Batavia mufthi forbade aka haram us to fight against colonialism. Some of us still up vote these colonialist favorite heart warming and relaxing doctrines. And we were colonized for years for listening to them.

Learning from my own history, I normally choose the first for good sakes (facts against gossips, knowledge over misinformation, education over leaving smartas..s in the heart of darkness, etc.) risking my own self some hatred for telling what I have in mind -- some are pure, some are tainted, I know.

But again, as said, I am not responsible for what people think. Just an FYI.

Thank you.

Thank you.

::loadSafely will return default, not null. Unless you delete the default via UI (un-)intentionally which is a big no.

Solutions, one only depending on you situation:

• Choose one optionset
• Clear caches
• Uninstall, and reinstall, if deleted

Thank you for contribution.

Thank you.

We should avoid using construct like other blazy sub-modules to avoid more future issues like this.
Ajaxin was apparently left behind.

A bit cumbersome at mobile for checking :)

See project home under Versions for the correct library.

You can also copy or reuse your previous downloaded file if using 2.x.

What works at 2.x should work at 3.x.

Thank you.

Fine at my end.

Try setting folder permissions correctly: libraries, files, etc.

Thank you for contribution and patience.

gausarts → made their first commit to this issue’s fork.

> to check if the formatter was of the Blazy family of formatters was an imprecise method...
String check is not only faster but also more efficient than class check for reasons:

• We have 6, or so, formatters (blazy_text, blazy_image, blazy_media, etc.) with different base classes. One string "blazy" check is inevitably better than multiple base class lookups or imports.
• Each base class may be extended by sub-modules, I avoided and was worried to leak Blazy specific features into sub-modules last time. I haven't recapped if such worries are still reasonable, though.

No Drupal APIs are involved for both checks, IMHO. They are both native.

Thank you for appreciation :)

For doc purposes, the plugin ID is called here:
https://git.drupalcode.org/project/drupal/-/blob/11.x/core/lib/Drupal/Co...

'#formatter' => $this->getPluginId(),

The contract is set in stone. Any violation of it in custom codes is possible, but not my responsibility.

Interesting points, thank you.

Makes no sense to me, unless you help me further with proper documentation.

> might apply a delta to the formatter, ..
What you said sounded a personal prediction or assumption to me.

Mind quoting and pointing it to an exact line of documentation? With proper and documented reasonings, not predictions or assumptions, of course.

AFAIK, Plugin ID, hence Formatters ID, is always a String, never Integer, as clearly noted here:
https://git.drupalcode.org/project/drupal/-/blob/11.x/core/lib/Drupal/Co...

If you were using an integer like deltas, you violated the contract, and integers also makes no sense for plugin IDs as numbers will easily conflict.

Unless I missed the obvious, of course.

Thank you.

I am using PHP8.3, as well, and see no evils.

I'd love to see a repro.

Also paste the entire error message so we can trace the caller aka the bad boy.

Thank you.

Normally some JS errors will break other JS.

One obvious is you have incorrect closing, should be:
});

Not:
}

Press F12, click Console tab, screenshot any errors there completely.

To help you work with JS, install Eslint.
https://www.drupal.org/docs/develop/standards/javascript-coding-standard... →

That should point you in the right direction.

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.