Just an FYI:
The Blazy Views field lightbox issue should be fixed in Blazy:3.0.9.
Thank you.
8.x-1.x is only up to D10 to avoid PHP8 vs. PHP7 complication.
2.x was created for D11+.
Glad you did it :)
Thanks for the follow up.
Thank you.
You are correct.
Most libraries, not all, even some commercial ones I purchased, are dead at one point in time.
People got priority, of course.
However, dead or alive, is no problem. What matters is functionality and feature. Non-critical bugs are common and fine, workarounds would do in the least.
No plan to replace it, it is currently feature -complete, IMHO, however Mason alternatives exist:
- GridStack 3.x is much more robust, responsive, and less buggier. It has Layout Builder integration. It appears to be bloated at first glance, but actually no JS libraries are loaded at frontend whenever it acts as Layout builder with CSS frameworks like Bootstrap or Foundation, or even just Native Grid. The bloat was its admin interface which is hardly an issue for frontend usages. Frontends can go without its JS libraries.
- Blazy grids as formatter and views style, including its 3.x Blazy layout for Layout Builder. It only lacks of paragraphs, but can be easily added if any demand. What Mason and GridStack have has already been in Blazy, named Native Grid, in its simplest pure CSS form, even before those two modules existed. Blazy 3.0.7+ allows multiple Native Grids and Flexbox for medium and large devices with minimal JS. Previously, only large devices, and the rest are plain columns, due to pure CSS. Browsers' supports for Native Grid are great, except for IE and other minorities:
https://caniuse.com/?search=grid
On second thoughts, while fine for Slick/Splide displays, this might break static grid functionality.
What do you think?
Thank you.
I would normally add spaces around locked elements using just CSS so to keep the scroll functionality as needed.
But your solution makes sense, too.
For blazy:3.0.7+, we have an internal method to detect touch devices, $.isTouch() with a callback. Since pseudo :hover is not available in touch devices, perhaps we can use it:
https://git.drupalcode.org/project/blazy/-/blob/3.0.8/js/src/dblazy.js?r...
Or just use window.matchMedia() either as listener, or direct method.
But yours is fine, too, if the library considered pseudo :active which is available at touch devices, but not :hover.
7.x was retired.
3.x was out with some mobile fixes.
I would be happy to work on this if any sponsorship.
Feel free to get in touch.
Thank you.
2.x was retired.
3.x was out with some mobile fixes.
I would be happy to work on this if any sponsorship.
Feel free to get in touch.
Thank you.
2.x was retired.
3.x was out with some mobile fixes.
I would be happy to work on this if any sponsorship.
Feel free to get in touch.
Thank you.
2.x was retired.
3.x was out with some mobile fixes.
IMHO IE was no longer supported by Miscrosoft nor Drupal 9+.
Feel free to re-open if still an issue. Be sure to mark it 3.x.
Thank you.
2.x was retired.
3.x was out with some mobile fixes.
The OP feature request was in 3.x, but not 2.x.
Feel free to re-open if still an issue. Be sure to mark it 3.x.
Thank you.
2.x was retired.
3.x was out with some mobile fixes.
Feel free to re-open if still an issue. Be sure to mark it 3.x.
Thank you.
2.x was retired.
3.x was out with some mobile fixes.
Feel free to re-open if still an issue. Be sure to mark it 3.x.
Thank you.
2.x was retired.
3.x was out with some mobile fixes.
Feel free to re-open if still an issue. Be sure to mark it 3.x.
Thank you.
2.x was retired.
3.x was out with some mobile fixes.
Feel free to re-open if still an issue. Be sure to mark it 3.x.
Thank you.
Feel free to re-open if still an issue.
Thank you.
One obvious mistake (not expected selector) is Off-canvas element.
It must be the previous sibling of On-canvas element.
Press F12, Inspect the Header element, or any container siblings to the On-canvas element(s). Put its ID or class if it has no ID.
More details:
https://git.drupalcode.org/project/ultimenu/-/blob/3.0.x/docs/STYLING.md...
Be sure to save /admin/structure/ultimenu to remove old settings which may break the updated structure.
Let me know?
Please screenshot your ultimenu block form?
Be sure to re-save and re-configure both forms as noted in UPDATING section:
- /admin/structure/ultimenu
- /admin/structure/ultimenu/ULTIMENUMAINNAVIGATION
The capital needs adjusting, different from theme to theme.
To disable hamburger for desktop, uncheck Always use hamburger at admin block.
More details in UPDATING and STYLING sections.
In case you don't have device emulators, if firefox, try installing Firefox developer version. Chrome should do by default IIRC.
See the screenshot for what I meant.
Thank you.
> "Dekstop Menu" not hidden when browser width decrease to small width (phone portrait)
You are correct, resizing is abandoned, the latest approach is based on touch vs. no-touch devices, not device width anymore.
Try pressing CTRL/CMD + SHIF + M, and change to any mobile device accordingly.
Shortly, do not resize from desktop to mobile. Use the provided browser device simulators.
You can however use old approach with media queries to hide and show based on device width, see and override css/*.css
> The hamburger icon when click has no effect.
It should work when you follow the steps above. Let me know if persists?
Also just in case, did you customize anything? If so, please follow up here:
https://www.drupal.org/node/3447576 →
Thank you.
Mind replacing this line:
https://git.drupalcode.org/project/gridstack/-/blob/3.0.x/src/Engine/Gri...
From:
'box' => $this->manager->toHashtag($item, 'box'),
to
'box' => $this->manager->toHashtag($item, 'box') ?: [$item],
I'll need to check this later if any side effects, but if that works for you, it will be a good start.
Thank you.
Any screenshots of Blazy formatter form, please?
> blazy is not generating the image correct to pdf. The result of the image is a very blury image.
Blazy does not generate any image. It picks up what is given. Please follow the steps:
- At your Media types > Document > Edit/manage fields.
- Add an existing, not new, Image field, named field_media_image, exactly as what core Media already provided.
- Upload your hi-res image preview for PDF with this Image field.
- At Blazy formatter, choose this Image under Main stage option. Please read its description, it explains what you need.
Be sure to repeat the same procedure for (Remote| local) Video, Audio, etc.
That way Blazy will display this preview whenever needed.
Let me know if still an issue?
The latest fix should remove the needs for the OP workarounds, i.e.: adding processed class ala jQuery.once.
With or without current workarounds should work without issues as seen at grids (without workarounds) and the rest left intact (with some workarounds).
We'll not backport this to avoid potential regressions.
Leaving this open till the next few releases to verify if regressions.
If anyone found any regressions or misses, feel free to update or report.
Thank you.
Two posssibilities:
- Outdated blazy version which may contain this issue as said previously. Please update.
- Folder permissions. I deleted styles folder twice, and image derivatives are generated without issues, so no repro.
About is_file, it is perfectly fine, however better and normally scoped: checking library files at install, can be disabled via UI like blur, dead zone of PHP like filter, or any permanently cached data etc., not on frequently used methods.
Should be outdated, but fixed to avoid dups in the next two weeks.
Feel free to re-open should you or anyone have persistent issues.
Thank you.
Thank you.
It should be a bug if I could reproduce it. I'll see to it later. Or if anyone could confirm?
I did notice an issue with image derivatives, IIRC in Views due to missing itok and double path styles, but thought it was already fixed some time ago, not sure about lightboxes.
What is your blazy version?
Still an issue with the latest?
About the patch, please change condition from $style to use $styleable as done in the previous line so to exclude SVG.
Updated attributes to img_attributes in case copied as is and conflicting with normal theme reserved attributes.
Feel free to share your findings.
Thank you.
It was a @todo, and is done now.
This will do for now.
If any issue with this change, we'll fix it later.
Thank you.
Also noticed a more strict check with undefined ID check for pinterest which is good.
gausarts → created an issue.
> image hard-coded into a theme
If you could place your code, I might be able to help better?
However, hard-coded or not, Blazy works perfectly fine with dead or archived HTML, twig, and PHP. It started with dead HTML, anyway.
To get a better idea on how Blazy works, try viewing the existing Blazy formatter output, CTRL/CMD + U.
The following should give you a big picture in TWIG usages.
See blazy.libraries.yml for more advanced usages:
{{ attach_library('blazy/load') }}
{{ attach_library('blazy/ratio') }}
The SVG placeholder is better than gif, but just longer and uglier:
{% set placeholder = "data:image/svg+xml;charset=utf-8,%3Csvg%20xmlns%3D'http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg'%20viewBox%3D'0%200%201%201'%2F%3E" %}
{% set url = 'https://www.drupal.org/files/One.gif' %}
{%
set attributes = create_attribute({
'data-src': url,
'src': placeholder,
'loading': 'lazy',
'class': ['media__element', 'b-lazy'],
'width': 640,
'height': 360,
'alt': 'Preview',
})
%}
For more aspect ratio, see <em>css/components/blazy.ratio.css</em>
<div class="media media--ratio media--ratio--169">
<img{{ attributes }}/>
</div>
Or the simplest, but needs more theming to avoid collapsed images, etc:
{{ attach_library('blazy/load') }}
<img data-src="{{ url }}" src="{{ placeholder }}" alt="{{ 'Preview'|t }}" class="b-lazy" loading="lazy" width="640" height="360" />
placeholder can be:
'/blank.svg'
'/blank.gif'
'data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7'
"data:image/svg+xml;charset=utf-8,%3Csvg%20xmlns%3D'http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg'%20viewBox%3D'0%200%201%201'%2F%3E"
The first two hit your server with HTTP requests, bad but can be handy from within Views results as noted at project home.
The last (data URI) won't, normal Blazy usages.
For dynamic/ field image urls, use core function here
https://www.drupal.org/node/2486991#s-file-urluri →
, or twig_tweak module for more functionality.
Pro tip:
Don't be fooled by Console Inspector (F12), use its Network tabs to verify the lazy load workflow.
Assumed calling this internal method externally without expected parameters which is not supported, anyway.
However added the proposed check for potential external usages.
Thank you.
About lightbox correct aspect.
Hm, not sure what missed. It is defined by Lightbox media/video style option. Or do you have different video aspect ratios? If so, not supported by this single option, yet. But as with many features, it can always be solved if any backers :)
About unpleasant local video procedure.
Not sure what you meant, but sounded slowness to load the video, or other problems? If so:
- try optimizing the MP4 file. Many online video compressors to reduce file sizes to dramatically improve loading speed.
- use the previously mentioned local Video uploaded Image field for posters to avoid browsers expensively generating dynamic previews. Posters should be statically ready to avoid browsers' hardworks.
About Splidebox caption.
It is hidden in the question mark button in the top row to avoid blocking image/ video displays. Captions are only immediately visible for a single display, though. But I think, we should improve it by forcing to display it once on the initial encounter so that visitors are informed that the captions are there in the question mark. Then hidden later.
About Splide slowness.
Some reported major improvement in Splide performance compared to Slick. Maybe not Splide, just Splidebox. Two possibility:
1. You just need to enable Drupal aggregation and caching. And try viewing it as an anonymous user.
2. Improve Splidebox internal optimization. Admittedly, it currently relies on browsers lazyload, but technically can be optimized more by partial markup buildups/ additions for large galleries.
About gutter spacing setting in Blazy grid.
Custom CSS should do:
- override the padding:
https://git.drupalcode.org/project/blazy/-/blob/3.0.x/css/components/gri... - and also the margin:
https://git.drupalcode.org/project/blazy/-/blob/3.0.x/css/components/gri...
At least, we should consider a special CSS class is-b-gapless to remove spacing.
About uninstall problem.
It is a known issue with easy solution, especially with Views:
- Be sure you enable Default display at Views settings UI.
- Then before uninstallation, always remove the traces of the module being uninstalled from Default displays. The traces to remove are normally in Views LHS > Format and Fields.
Normally Default display is hidden and keeping the remnants of module dependencies causing ramified uninstallation.
About OOT.
No worries, comparisons of the same feather birds are still in topics :)
The OP problem remains as limitations in this particular module till backers come :)
However the documentation part is assumed fixed or work as designed for now.
Your observations are mostly correct.
What you have found with Blazy Views field and PhotoSwipe is called limitations.
They can be solved once I have a client who pay for the job, like the case with Splidebox. Maybe you would like to pay 1-2 hour work for this, says around $100?
To prove it, just try Splidebox for your particular need with Blazy views field. PhotoSwipe is less updated than Splidebox due to paying clients :)
Setting up lightboxes inside a Views UI also require you to read the Blazy for Multimedia Gallery via Views UI + Lightboxes sections for details of instructions. Failing to follow these up may cause you unnecessary failures. See /admin/help/blazy_ui.
About Blazy Views field.
This one has indeed very poor and limited info about field data causing limited features and other limitations to lightboxes.
Too many limited info here. Most lightboxes, including PhotoSwipe, even have no idea to treat local videos, etc. due to no field info.
Only Splidebox is more educated so far on this regard, not PhotoSwipe, etc. thanks to paying clients :)
The most important is you must have Blazy Grid under Views LHS Format.
If you are just starting out, always start from the basics -- Content types > Article|Page > Manage display formatters, not Views UI.
Views UI has some quirks and limitations, not to mention it might also require you to setup relationship, filter criteria, toggle Use field template, etc. Aside from Blazy limited options in there if using Blazy views field. Once you are familiar with node display, you'll advanve to Views UI with some familiarity of expectations.
About poster images.
This is already described in the form description, only clarified more:
(Re-)Use the same field image normally field_media_image for all other Media entities other than Media Image as the thumbnail/ hires image previews. This way, local video/ audio will have poster image, similar to normal Image. Remote videos will have the same hires image, too.
Steps:
Visit Media types > Video > Manage fields > Add a new field > Re-use existing field > Select Image field named field_media_image. The same workflow applies to audio, remote videos, documents, etc.
Then upload an image to that new field to have poster images.
The following may apply outside Blazy Views field.
About swipeable local videos.
It is not exactly the video interface being swipeable, but more about its horizontal surrroundings are. Yet, swipeable anyway.
Similar to how Media instagram, pinterest, etc. are being swipeable in the lightbox interfaces like in Splidebox, but not PhotoSwipe for now.
For remote videos, it is indeed swipeable, since it uses image preview, not iframes.
About playable media in lightboxes.
Not all lightboxes support this feature, not even when using Blazy Views field. Only Splidebox does as said above.
You are correct.
Changed the contract without changing the implementation :)
We should also update sub-module description overrides with this new contract later.
Thank you for contribution.
Thank you.
Try searching Gin on the main Slick module for solutions, even a permanent one exists.
Thank you.
Mind providing detailed repro steps?
I couldn't reproduce it with tons of samples, but happy to see the underlying cause.
Also you may want to update the non-minified JS here as well:
https://git.drupalcode.org/project/blazy/-/blob/8.x-2.x/js/src/plugin/bl...
Thank you.
The quickest is install the included Splide X, put the blocks and edit its options. Clone anything provided, or just edit.
Arrows and dot pagination are parts of an optionset.
All optionsets can be edited at Admin > Config > Media > Splide UI.
Be sure to enable Splide UI sub-module.
Arrows and dot pagination can be disabled there, or via Override main optionset.
If you want to change default values, avoid choosing Default for both Optionset options.
Default optionset must not be edited!
Create your own, or install Splide X for quick samples.
3.x is out.
Any betterment should start here and may or may not be backported later.
Thank you.
3.x is out.
Any betterment should start here and may or may not be backported later.
Thank you.
3.x is out.
Any betterment should start here and may or may not be backported later.
Thank you.
This is an unfortunate optimization byproduct and a problematic ID option identified later, I am afraid.
One thing for sure, the risk of workarounds is fragile, and can be gone and forgotten anytime.
I have said what I had to say above and also in the linked issue, including alternative solutions. If any betterment, they can go to 3.x.
3.x is out.
Any contribution should refer to the provided docs as outlined at project home:
https://git.drupalcode.org/project/slick/-/blob/3.0.x/docs/CONTRIBUTION....
Thank you.
3.x is out.
Any contribution should refer to the provided docs as outlined at project home:
https://git.drupalcode.org/project/slick/-/blob/3.0.x/docs/CONTRIBUTION....
3.x is out.
Any contribution should refer to the provided docs as outlined at project home:
https://git.drupalcode.org/project/slick/-/blob/3.0.x/docs/CONTRIBUTION....
Anyone concerned about performance should consider using data, docs, and proper tools in the light of the fundamental Drupal knowledge and the web vitals.
We had an intro talk on web vitals at Blazy some time before you posted this issue:
🌱
Blazy 3.x Roadmap
Fixed
Important!
There is also a link at Slick project home about performance benchmark. Just press CTRL + F at project home, and type "benchmark" to go to the link.
Extraordinary claim does require extraordinary evidence as they said, but so far we just don't want to boast anything, that is why the link is not so prominent. It is just a regular humble contribution anyway, IMHO.
However, be sure you know how isolation works and have something equal to compare with along with extreme condition so to have better and purer benchmarking should you want to run your own benchmarking.
Blazy strived to address web vitals with its configurable options. Not all, not perfect either, but fairly serious and comprehensive. Not to mention those outside visible config, async decoding and the most underrated byte size where every byte counts I learned from mortendk.
Failing to understand web vitals will not only make Blazy options useless and absurd, but also may lead to a disaster as mentioned in this OP and hinted in that thread.
The same disaster applies to Drupal as well. It is a snail until you enable caches and asset aggregations at /admin/config/development/performance. Note the "performance" word at the end of the url. Failing to see to that performance page will equally lead to a disaster as seen at some invalid performance issues at this very project. Some people just don't know that performance page, and immediately jump posting wrong negativity which is not perfectly fine but also improper.
Again negativity would be fine if anyone had done their own homework in the least with fair data or benchmarks. That is why I still appreciated the OP regardless of the devastating title because he has done enough homeworks and showed more interests in having solutions than celebrating problems.
All this has been outlined in the contribution section at Slick, Blazy, etc. and their docs in general.
In short, always spend 5-15 reading and understanding your "enemies" before attacking them blindly, or worse offhandedly.
That would save us both from unnecessary inconvenience and help improve contribution quality in the long run.
Feel free to update your findings should you have one.
Thank you.
3.x is out.
Any contribution should refer to the provided docs as outlined at project home:
https://git.drupalcode.org/project/slick/-/blob/3.0.x/docs/CONTRIBUTION....
3.x is out.
Any contribution should refer to the provided docs as outlined at project home:
https://git.drupalcode.org/project/slick/-/blob/3.0.x/docs/CONTRIBUTION....
3.x is out.
Any contribution should refer to the provided docs as outlined at project home:
https://git.drupalcode.org/project/slick/-/blob/3.0.x/docs/CONTRIBUTION....
3.x is out.
Any contribution should refer to the provided docs as outlined at project home:
https://git.drupalcode.org/project/slick/-/blob/3.0.x/docs/CONTRIBUTION....
3.x is out.
Any contribution should refer to the provided docs as outlined at project home:
https://git.drupalcode.org/project/slick/-/blob/3.0.x/docs/CONTRIBUTION....
3.x is out.
Any contribution should refer to the provided docs as outlined at project home:
https://git.drupalcode.org/project/slick/-/blob/3.0.x/docs/CONTRIBUTION....
3.x is out.
Any contribution should refer to the provided docs as outlined at project home:
https://git.drupalcode.org/project/slick/-/blob/3.0.x/docs/CONTRIBUTION....
3.x is out.
Any betterment should start here, and may or may not be backported.
3.x is out.
Any betterment should start here, and may or may not be backported.
3.x. is out.
Feel free to patch if any betterment in another thread to keep things organized.
Thank you.
3.x is out.
The roadmap was pretty straight forward and enough as said in #2 and project home.
Thank you.
Should be fine.
composer update drupal/blazy -W -n
Should be:
composer update -W -n
Thank you.
Versions 8.x can only support up to D10.
For D11+ compat, we had created 3.x branch so to have a more semantic versioning as well.
Thank you.
Versions 8.x can only support up to D10.
For D11+ compat, we had created 2.x branch so to have a more semantic versioning as well.
Thank you.
Versions 8.x can only support up to D10.
For D11+ compat, we had created 3.x branch so to have a more semantic versioning as well.
Thank you.
Versions 8.x can only support up to D10.
For D11+ compat, we had created 3.x branch so to have a more semantic versioning as well.
Thank you.
Versions 8.x can only support up to D10.
For D11+ compat, we had created 2.x branch so to have a more semantic versioning as well.
Feel free to re-open if still an issue.
Thanks.
Feel free to re-open if still an issue.
Thanks.
Thank you.
Actually I was expecting use cases in more atomic designs as said in #4, not changing the container template + preprocess (theme_splide()) into components. Losing the benefit of the theme_splide() will disintegrate it from Views and fields UI, and likely bring out more preprocess complication at its parent container, says node.html.twig.
AFAIK, the point of SDC is reusable micro components, not negating the current macro template + preprocess (theme_splide()) at container level otherwise that would risk unnecessary duplication given various skins and options and also variable complication.
Simply put, the theme_splide() is intact since it is required for versatility and consistency along with direct Views and field integrations, but its items (theme_splide_slide(), theme_splide_vanilla(), thumbnails, grids, etc.) can be more atomic to make them behave like components.
However I agree we should consider using SDC more when it is out of Experimental flag.
This would do for now.
Improvements are welcome.
Thank you.
IIRC, previously using non-indices keys for UI objects appeared to fail, but now works.
But then indices caused duplicated elements on subsequent launches, so I changed:
Drupal.blazyPhotoSwipe.ui[0] = {}, etc.
to non-indices keys:
Drupal.blazyPhotoSwipe.ui.customCaption = {}, etc.
The patch will make immutable pswp object available globally, while make it possible to work with individual elements.
The last was taken from Slick convention which stores JS instance in the individual gallery element.
This sample will go to Drupal.behaviors.attach block:
var bps = Drupal.blazyPhotoSwipe || false;
// DOM ready fix.
setTimeout(function () {
var items = context.querySelectorAll('[data-photoswipe-gallery]');
if (items.length) {
items.forEach(function (el) {
var pswp = el.pswp;
console.log('pswp', pswp);
if (bps && bps.init) {
Drupal.blazyPhotoSwipe.ui = bps.ui || {};
var lightbox = bps.lightbox;
console.log('lightbox', lightbox);
if (lightbox) {
Drupal.blazyPhotoSwipe.ui.test = {
name: 'test-button',
ariaLabel: 'Toggle zoom',
order: 9,
isButton: true,
html: 'Test',
onClick: (event, el) => {
if (confirm('Do you want to toggle zoom?')) {
console.log('event', event);
lightbox.pswp.toggleZoom();
}
}
};
pswp.on('beforeOpen', function (item) {
console.log('beforeOpen', item);
});
pswp.on('initialLayout', function (item) {
console.log('initialLayout', item);
});
}
}
});
}
});
Adjust ES6 mix above accordingly, but fine though.
Also works fine with sample from #3.
Let me know if any betterment for this?
This is another sample for download link:
https://www.drupal.org/project/blazy_photoswipe/issues/3389181#comment-1...
✨
Photoswipe 5: provide a download link
Fixed
Thank you.
Registering UI appears to work, however the current implementation is not really working well to accommodate events due to empty pswp.pswp object as per this writing.
var bps = Drupal.blazyPhotoSwipe || false;
// DOM ready fix.
setTimeout(function () {
if (bps && bps.init) {
// Merge other UI providers, if any.
Drupal.blazyPhotoSwipe.ui = bps.ui || {};
bps.init.finally(function () {
// @todo this object has empty pswp object.
var pswp = bps.beforeInit;
console.log('pswp', pswp);
if (pswp) {
Drupal.blazyPhotoSwipe.ui.test = {
name: 'test-button',
ariaLabel: 'Toggle zoom',
order: 9,
isButton: true,
html: 'Test',
onClick: (event, el) => {
if (confirm('Do you want to toggle zoom?')) {
// @todo pswp.pswp.toggleZoom();
}
}
};
}
});
}
});
Conclusion, we need to inject pswp object manually, or refactor to use gallery element to support multiple instances rather than relying on global Drupal.blazyPhotoSwipe.beforeInit.
Yes, that is why I said dead configs.
Committed. Thank you for contribution.
Ah, makes sense.
So we got configurable UI for this now?
When it was written, there was no UI for that.
If there is UI, this should be changed, then.
Thank you.
I don't remember precisely, but two reasons:
- I don't like the original module default values, due to issues I also don' t remember :)
- They are both equally default aka dead configs, so it makes no difference.
Could you confirm those defaults are different for some values?
If no difference, worth your reversal.
If any difference, I might remember the issues.
Noted, thank you.
One thing for sure: while some design challenges can be easily solved by mere CSS, and probably very minimal JS like the OP use case, they may also require extensive works of Twig, hook_alters, etc. depending on the complexity, of course.
> if the modules were more component based, the provided examples would be the actual starting point for your development.
Interesting and worth trying, indeed. Appreciated!
Mind providing 3-5 screenshots or samples of dummy designs that you have success with SDC? Or at least a single paragraph description about the task or challenge.
Your OP last paragraph is a very clear challenge sample, it has a Drupal field context with a requirement to display it based on the design. That would do, too.
I am interested in seeing the success stories of SDCs especially when it is in core already so I'll have a better idea about its use cases and the potentials of its integration in this or any modules I maintain.
I am also interested in seeing the failures or misses of traditional (pre-D10.1 SDC) approaches with your use cases. This part I may be able to explore after hearing your use cases.
I hope you can make it one way or another :)
> What I want to do is show the first image in a media field ...
Try CSS display:none for any field__item selector, or any relevant lightbox containers (li, .grid, etc.), except the first. That way you will see only the first item while the rest are hidden. Lightbox will continue working, hopefully :)
If still an issue, please update to Splidebox:2.x which works with Blazy:2.x and D8.8 since Splidebox:2.0.4.
Closing this since 1.x is no longer supported.
Thank you.
Glad you did it :)
Thanks for the follow up and your solutions.
We are not going to support 1.x any longer. Please upgrade to 2.x.
Is this still an issue with the latest 2.x releases?
The doc comments below @file line actually mentioned the dual usages for both vanilla and navigation.
However I agreed to update @file comment as suggested.
Regarding template overrides, you can do regular copy procedures into your theme.
Just be sure to keep the relevant conditions as recommended in the doc comment top distinguish Vanilla from navigation.
In case misunderstood, unlike Slick, Splide supports navigation within Vanilla as documented in project home as long as Thumbnail style or Thumbnail caption is provided. I understand this might confuse you. However the current approach is a more simplified version of Slick's while having more advanced features.
More betterment is always welcome should you have one.
Thank you for contribution.
Committed. Thank you for contribution and patience.
I'd be happy to write it whenever I have a project which requires it.
Patches are welcome :)
You or anyone else are also humbly welcome to sponsor it for 2-3 hours work, less than $150. Shamelessly I put the number so anyone can chime in if that sounds reasonable :)
Feel free to get in touch.
Otherwise you might have to wait for our requirements to get it for free.
Thank you.
Noted, thanks.
I'd love to embrace this new system to ease things up, but so far worried about giving incorrect credits as previously described.
Your comments help me see this new system better, although honestly I am still a bit confused seeing those MR commit messages conflicting my usual old CLI commit messages :)
I don't quite understand #26 :)
I thought it would say ... authored by KarlShea.
But I assumed it is the way it is, correct?
> the commit author doesn't matter with regards to issue credits
My, this is truly relieving, but also shocking to me :)
Because then it was the opposite of previous system when authorship matters and determines the authorship credit.
The merge looks good now, thanks.
Hm, weird indeed :)
As seen in the commit message #16 I did credit @KarlShea alone, and under Merge I select the first option which was correct. But the author was still @ravikant.
However based on the previous #16 commit, I tend to think, the first author of an MR always got the authorship credit even though I have excluded @ravikant and my name from the credit table.
> I'm not really concerned about the issue credit...
Got it, thanks. I am just not comfortable to give incorrect credits with this new system :)
I merged your MR!6 now, but the system failed even though I had reverted the #16 commit. See screenshot and the previous system message exactly before this comment.
Maybe I'll need to use CLI later, but then I have no other way to put --author line for commit message copy/pasta as mentioned in the core issue above.
While I know you are fine with credits, however I am more concerned about the new system byproduct so that I could give proper credits later on. I will see if anyone had this issue, and commit it using CLI if anything failed.
Unless any server-side issues with composer.lock or permissions, one obvious potential issue is locked versions like so:
composer require drupal/blazy:2.22
Should be generic:
composer require drupal/blazy:^2.0
Note the difference with caret ^ and trailing 0.
Locking is only necessary if any instruction to do so like our previous dev storms after 2.6, so last time locking to 2.5 is the only recommended way to avoid potential errors. Or if you knew for sure the next version is buggier.
But gone were the stormy days since 2.17. You can set up your composer directives like the generic one from now on.
Then on every updates, simply run regular swap command:
composer update -W -n
To update all contrib things once without any more individual composer require + versions which is the point of composer -- simplifying dependency managements. Unless as said a stormy dev warning were published for version locks.
The next 2.24 update SOP covers such potential composer.lock problems under WSOD which might also be applied to your situations after correcting the locked version issue, only if the generic one alone failed:
https://git.drupalcode.org/project/blazy/-/blob/8.x-2.x/docs/UPDATING.md...
Thank you.
You didn't give enough info about your actual problems, if any. Honestly not sure what you are talking about, but it doesn't seem a problem to me except about "does-nothing update" perception?
If so, there are things (update messages, codebase synching, etc.) not always immediately visible unless you run the update process properly.
And any update doesn't guarantee any visible messages or changes, either.
Often times, they are only some under-the-hood changes like triggering asset regenerations cache clearings, or service updates in case aggregations and caches are being enabled so to ensure things are updated.
This update triggers or any empty updates may "do nothing" visibly, but it is not anything to worry about.
However you may want to trace changes using your git tools to see what is going on under the hood only if you are concerned. But IMHO most people hardly care about, except for any regressions or newly covered issues due to updates.
Most reported update errors, if any, are due to failing to follow update SOP.
In short, drush cr drush updb drush cr. Not just drush cr.
Nothing to worry about though if you did update SOP correctly. Be sure to check out Update SOP link at project home for more details.
@KarlShea, I tried reverting this MR for my education purposes so to get the correct authorship credit.
And see if I can choose your new MR to get the correct credit about which I doubted if using MR !5 which was initially authored by @ravikant?
@KarlShea, I suspected you might need to create MR !6 or so on your own so to get correct authorship credit, not using MR!5 which was authored by @ravikant?
If not, do not hesitate to shed the light.
Thank you.
Oh, no.
I credited @KarlShea alone, and it did merged @KarlShea's MR, only now authored by @ravikant?
I am sorry, I don't understand this MR selection stuff as predicted. The select options are not very clear to choose from even after correct credit.
We'll need a revert?
@KarlShea, merged, thank you.
@ravikant, thank you anyway.
IIRC, this is my first time using a cellphone to commit an MR :)
There is always a first time for everything.
I hope I did it right, thus having credited @KarlShea alone since I can no longer assign author to choose one from two. Previously I could credit many, and chose one author, but not now, so I am a bit careful with this new UI stuffs till I figure it out any better.
Feel free to CMIIW.
@KarlShea, please confirm if you got your credit correctly.
Good to hear it, thank you.
When core has it builtin, we should remove our own minification. It will have more benefits like easy debug without hustles, and less maintenance.
Perhaps when min core requirements D10, or even sooner whenever I got a chance to update them since I can always to D10 just as easily. Patches are welcome at another thread.
The only reason I minified all my JS is because I don't always use advagg, and core didn't have it till D10 :)
> Maybe merging the MR will automatically do it?
That's it. Just found the relevant issue:
https://www.drupal.org/project/drupalorg/issues/3177220
📌
Remove commit author radios in the "Credit & committing" section.
Fixed
But then, gitlab MR appears to be unlinked from regular commit pushes when not using MR for old commits. Not sure :)
Yes, we should update the minified, as well. Or you can use this online service which I normally use since mostly finer than offline ones: https://jscompress.com
@KarlShea, thank you.
Removing the offending lines should be good. Hopefully rewind does the job, but not crucial.
OOT, I am just losing my Drupal permissions to give proper credits to your or others' authorships.
Previously I could tick you as an option for the author, but now I couldn't. I haven't got a chance to search nor report this issue to d.o. as it makes no sense if maintainers who should be able to commit and give credits to authors like you are no longer seeing you or others as an option for authors. I thought it was a temporary miss, but has been a while, though.
I saw Author column before like this:
https://www.drupal.org/files/GitAttributionUI_0.png →
https://www.drupal.org/docs/develop/issues/issue-procedures-and-etiquett... →
But now I don't see it like in my screenshot.
Please allow me some time to report about this credit issue, or kindly shed the light in case I missed the obvious with recent d.o. changes.
Thank you
@KarlShea, you are correct.
It was a new 2.0.3 module feature to remove disabled arrows/ buttons specific for Slide, mostly related to Splidebox.
Unfortunately, poorly executed.
Honesty, I didn't know rewind was what I was looking. My mindset was it was autoplay-related option :)
But if it does the job as you said, removing the offending line is the correct one.
@ravi kant, libraries definition change was only for debug purposes IMHO.
Thank you.
You are correct. Maybe we should add it over here:
https://git.drupalcode.org/project/splide/-/blob/1.0.x/modules/splide_ui...
So that its absense doesn't pollute non-steppable form item values?
I am away from laptop to see things clearly in a cellphone, would it do?