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.
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. tois-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.
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 htmlSee 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:
- 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.
- 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:
- Is it D11, or less? See D11 compat issues and its workaround.
- 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?
- Verify the supported Slick library 1.6-1.8.0, see project home for fake/ misleading 1.8.0.
- If using Accessible Slick, revert to original Slick.
Additional PHP checklists, might be unrelated, just to be sure:
- Is it EleveateZoom Plus? Or plain Slick?
- 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.
- 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 crafter 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!