Hi, loving using Slimsy and the new image cropper in V7.1.6.
Little problem using it with flexslider...
If I use GetResponsiveCropUrl or GetResponsiveImageUrl, when the page first loads, all the images in the slider are pixellated. If I then resize the browser they're all perfect. This happens no matter what the initial browser window size is. I've tested it on W7 Chrome 37, IE 11 and FF 27.
If I use GetCropUrl then the images are all hi res at page load, but then I don't get the advantages of the Slimsy version.
It's like GetResponsiveCropUrl won't create full res images unless some event or other is fired first. This only affects the images shown by flexslider.
Unfortunately I'm using flexslider on the home page so this is quite visible. Is there a work-around for GetResponsiveCropUrl?
Changed #slider to my slider's ID. Ran ok but with errors, doesn't know what sliderActive is, and to be honest, neither do I. Is it something in slimsy, flexslider or am I supposed to instantiate it somehow?
Great! That snippet was just a example, but sliderActive is there to ensure it's only executed once, I don't remember if there was occurrence when it was activated more than once so it's probably irrelevant.
window.slimmage.readyCallback = function() {
//activate your slider here
}
I'm guessing the cSlider code is for the WordPress cSlider. It's also got JQuery in it so can't possibly run anyway if the code you suggest is placed with the window.slimmage = { verbose: false }; line which has to be the first line of JS, so JQuery isn't loaded yet.
So what I'd tried previously which somehow worked but gave "sliderActive is not defined" errors was, in the start of the JS loading (after all other HTML)
That looks ok, no errors is interesting. Could you try adding some console.log in key positions or use Chrome debugger to see where it's getting to and when?
Should be up on a temp test domain tomorrow but am having great trouble finding decent shared hosting. There are some muppets about! But that's another thread ;)
Cool, let me know when you have it online. I have a quick look at flexslider and I think it should be compatible. The test is if the images not in view still have computed width and height.
Two issues here, first was to add the window.slimmage.readyCallback method in common.js and second is line 40 in flexslider.css which is hiding the images initially, this prevents Slimmage from being able to calculate the "computed" image size and so defaults to first step (160). To avoid this without hacking your vendor flexsider.css file, I've added a element override in your flexslider.cshtml Partial View. <li style="display:block"> I guess with other sliders they sometimes use z-index or off screen positioning rather than display which is why they haven't had this particular issue.
Thanks Jeavon but the display:block is causing issues with the slider position. The first slide comes in correctly then jumps up 20px. The next slide comes in at the +20px position, then the first slide repeats as before. However, it does fix the resolution issue. I guess there's some more digging to be done. I was thinking that some js must be fired when the browser resizes so couldn't that be fired manually so to speak, in the common.js on page load or just after the slider is initiated? Might just be easier to swap out the slider for another one, though I do like FlexSlider.
Yeah, it might be easier to use a different one. We actually use our own JS library for sliders, but I know that Jeroen uses http://bxslider.com/ and that seems to work ok with the readyCallBack.
Ok, swapped out FlexSlider for bxSlider so problem has now gone away. Not as nice a slider though. Having done it, realised I should probably have not used slimsy for the slider. But hey-ho, got to get the site up in budget:)
Images pixellated on page load
Hi, loving using Slimsy and the new image cropper in V7.1.6.
Little problem using it with flexslider...
If I use GetResponsiveCropUrl or GetResponsiveImageUrl, when the page first loads, all the images in the slider are pixellated. If I then resize the browser they're all perfect. This happens no matter what the initial browser window size is. I've tested it on W7 Chrome 37, IE 11 and FF 27.
If I use GetCropUrl then the images are all hi res at page load, but then I don't get the advantages of the Slimsy version.
It's like GetResponsiveCropUrl won't create full res images unless some event or other is fired first. This only affects the images shown by flexslider.
Unfortunately I'm using flexslider on the home page so this is quite visible. Is there a work-around for GetResponsiveCropUrl?
Cheers,
Hi Craig,
If you have a slider that needs to be "bound" after Slimmage has done it's thing you need to use the readyCallBack, e.g.
Make sense?
Jeavon
Thanks Jeavon, it worked, but...
Changed #slider to my slider's ID. Ran ok but with errors, doesn't know what sliderActive is, and to be honest, neither do I. Is it something in slimsy, flexslider or am I supposed to instantiate it somehow?
If we can clear that up it would be great.
Cheers
Great! That snippet was just a example, but sliderActive is there to ensure it's only executed once, I don't remember if there was occurrence when it was activated more than once so it's probably irrelevant.
This gets weirder.
I'm guessing the cSlider code is for the WordPress cSlider. It's also got JQuery in it so can't possibly run anyway if the code you suggest is placed with the window.slimmage = { verbose: false }; line which has to be the first line of JS, so JQuery isn't loaded yet.
So what I'd tried previously which somehow worked but gave "sliderActive is not defined" errors was, in the start of the JS loading (after all other HTML)
Then in a common.js, loaded later, after JQuery, initiated the flexSlider:-
So modifying that setup in the light of your last answer, the initial line was left as original:-
And the common.js flexSlider initiation changed to:-
This gives no errors but the original issue remains, that of initial low res pics until resized.
Just a thought but is there not something in Slimsy that can be called from the flexSlider initiation script that can do the necessary?
Please advise.
No, this is just a front end JS issue. But it should be be like this for your jQuery plugin:
'fraid that doesn't work. Still loads low res images into the slider as before. No errors though.
So the HTML build sequence is:-
Load head with CSS
Load Google Translate script (don't ask!)
Load body
Then
Load google Analytics
The initiation script is in the common.js. Could this be the issue?
That looks ok, no errors is interesting. Could you try adding some console.log in key positions or use Chrome debugger to see where it's getting to and when?
Is this online anywhere I could view?
Should be up on a temp test domain tomorrow but am having great trouble finding decent shared hosting. There are some muppets about! But that's another thread ;)
Cool, let me know when you have it online. I have a quick look at flexslider and I think it should be compatible. The test is if the images not in view still have computed width and height.
Finally, it's on test at http://test.tighruaraidh.co.uk/ awaiting final content loading. Any advice would be appreciated.
Could you try placing Slimmage.js in the head and changing verbose to true?
Done as requested.
Thanks, strange thing is I copied your html locally and it worked fine....
Is there a chance you could give me temporary Umbraco access so that I can edit the js files to try to work out what's going on?
Sent by Twitter DM (not that I don't trust the rest of you of course ;)) lol
Ok, solved :-)
Two issues here, first was to add the
window.slimmage.readyCallback
method in common.js and second is line 40 in flexslider.css which is hiding the images initially, this prevents Slimmage from being able to calculate the "computed" image size and so defaults to first step (160). To avoid this without hacking your vendor flexsider.css file, I've added a element override in your flexslider.cshtml Partial View.<li style="display:block">
I guess with other sliders they sometimes use z-index or off screen positioning rather than display which is why they haven't had this particular issue.Jeavon
Thanks Jeavon but the display:block is causing issues with the slider position. The first slide comes in correctly then jumps up 20px. The next slide comes in at the +20px position, then the first slide repeats as before. However, it does fix the resolution issue. I guess there's some more digging to be done. I was thinking that some js must be fired when the browser resizes so couldn't that be fired manually so to speak, in the common.js on page load or just after the slider is initiated? Might just be easier to swap out the slider for another one, though I do like FlexSlider.
Yeah, it might be easier to use a different one. We actually use our own JS library for sliders, but I know that Jeroen uses http://bxslider.com/ and that seems to work ok with the readyCallBack.
Ok, swapped out FlexSlider for bxSlider so problem has now gone away. Not as nice a slider though. Having done it, realised I should probably have not used slimsy for the slider. But hey-ho, got to get the site up in budget:)
Many thanks for your help Jeavon, beers are owed.
Craig
Cool, think I will create a Slider info section somewhere in the Slimsy docs and create a list of known Slimmage compatible plugins :-)
is working on a reply...