Just doing my first V6.1.1/MVC/Bootstrap/Responsive site, so quite a bit to learn on the way. I have the imaging using DAMP and CropUp. In the past I've used ImageGen to ensure the images were output at the correct pixel size while CropUp ensured the correct form factor. Now that I want the imaging to be responsive, setting the output size doesn't seem right somehow.
So, the question is, how are other people approaching this? I'd be really interested to hear others' opinions.
We're doing a combination of things depending on what kind of image it is. The trade off is between practicality and amount of effort (i.e. our time) the client will be happy paying for.
For page template/skinning images (images that we create and place and don't allow the client to change) we either drop out things like background images on smaller screens or use a lower-res one which is determined by the active media query.
For user-uploaded images we rely on server-side image resizing (using ImageResizer.NET, which does roughly the same thing as ImageGen) to our desired max desktop-mode width---this is to avoid the client uploading 4,000 pixel wide images that kill even high-end browsers---and on top of this use CSS resizing max-width:100% on them in responsive mode.
If we have a photo gallery, where for example you click on a thumbnail and then get a bigger image in a lightbox/fancybox, the thumbnails are typically around the same size anyway so not much more efficiency to be had with the server-side image resizing, but we add in a little javascript to change the "zoom picture's" hyperlinks to include approximate size of device. This works because the zoom-picture isn't loaded until you click on it, and by then the link has already been rewritten to include ?width=300 parameter or whatever. I round these widths to the nearest 100 (and never larger than 1600) so that the ImageResizer cache doesn't grow beyond a practical size. This makes image galleries very snappy on little phones.
Hey all, did you know that CropUp actually has support for responsive images? There is a bit of info on the CropUp project overview, but basically you just use it like this (classic Razor macro):
Ah, just realised you just output the thing on it's own, not as an img tag. But Crop Up didn't install a Scripts/CropUp.js so now I just have blank place holder, of the right size though.
You don't need the img tag when using the CropUpResponsive you just call @CropUpHtml.CropUpResponsive
But you reminded me, that there is also a bug in CropUp that I think is only affected by when using this method on IIS7, I actaully submitted a fix a while ago but it makes CropUp only work with Umbraco v6 so hasn't been accepted. Anyway you can download the patched files from here Just overwrite all the dll's in the bin folder (backup first!).
<bit-of-a-rant> Umbraco is becoming extremely expensive to work with. It just takes FAR too long to get anything done as it all seems to rely on undiscoverable knowledge and patches. Just getting a bit dis-heartened after all the CodeGarden excitement:( All the demos made it look easy. Documentation is SO important. Every iteration is the same, no docs = heartache. And it changes so often that you can never build anything using what you learned last time. Very time consuming and frustrating. </bit-of-a-rant>
So you mean you don't need a CropUp.js in the Scripts directory, it'll be created by the application? I had downloaded it from http://searchcode.com/codesearch/view/28139204 but it failed as I load my JQuery after the body, not in the header so it croaked on })(jQuery);
<two-pence> There is a issue around package/umbraco compatibility and also inter-package dependency and there has been some thoughts about how to deal with this on the Umbraco core Google group. I personally think the documentation to be pretty good now especially for Mvc and there are quite a few samples for the various property editors However Mvc hasn't been widely used yet and some compared to Razor macros or XSLT there is not a lot of examples. When we find that a package doesn't work properly or is not compatible with the version of Umbraco we are using and we can make a fix, we do so and submit a pull request, that of course doesn't mean that the package author accepts it though! </two-pence>
If you try the CropUp patch I sent you, then you should see that the JS paths are auto generated?
@Craig I'm going to be very cheeky here and say: me thinks you're getting old. :-) Things change at a fast pace in the software world and Umbraco is no different.
BUT(!) the current v6 is 95% compatible (yes, this is a very scientific number .. as in: bogus but with a large grain of truth) with whatever you wrote in the past 2 years. You do not HAVE to learn any of the new concepts, we've been trying to be very conservative in the last year to make sure that nobody got left behind.
We document more than we used to and we're always happy to hear about areas where Umbraco is painful and hard to get so we can improve. Also not that CropUp is not a plugin we produced, so don't blame us! ;-)
I know this sounds very defensive but let the point be that we're willing to listen, I accidentally stumbled upon this thread and your rant but I love getting constructive criticism and I hope you'll feel comfortable about bringing it up in either email, the core mailinglist, a dedicated post here tweeted to the team, etc. That way we can listen and hopefully help.
It's not about age, or not wanting to change or learn, it's about getting some lasting value out the effort you put in. I do a new Umbraco site about once every 3 or 4 months. At other times I'm doing other stuff, so I wouldn't consider myself expert in any version of Umbraco. I always use the latest version and always want to use the latest techniques, so those techniques have to be learnt. Nothing wrong with that. But it would be nice if there were some top level guide that could tell you that where you used to do A you now need to do B. That's pretty much it in a nutshell. Detailed technical info is all very well as a reference, but it can be quite daunting when you need a bit of a steer at how to acheive what you did on your last site in your new one with the new API.
I take your point about packages though. I see from Twitter just now that there are mutterings about compatibility with some of them and V6 causing some to downgrade to V4. It'll all come right soon enough. I thought the V6 eco-system was a bit more mature that it was I guess.
I'm very happy to discuss stuff in a constructive way, it's the only way;) That's what I love about the Umbraco Community, always willing to listen and improve. If I can help, I will.
@Craig Understood, but if you want lasting value then we've got your back with all the legacy that is still supported. Just for you.
If you want to learn the new and fancy way of doing things then you need to be prepared to learn. And yes, we're all about implementing cool new stuff and we document most of it these days. We even document it sometimes saying: in v4.x.y you can do it like this, in v6.x.y you can do it like that.
Your complaint was that you can't build something like you learned the last time, but you want to use the latest techniques, so which is it? Make a choice: try to keep up at cost to you or just do what you used to do in your previous project, you've got plenty of example code there.
Again, I know this sounds defensive but that's only because we've gone through great lengths to keep backwards compatibility intact as much as possible. This takes time, which is costly and frustrating for us.
v6 is very mature, in fact we're not maintaining v4 any more after tomorrow, we're very confident that we have the last kinks worked out by now. There is one package that Simon referred to on Twitter (DocType Mixins), which will mess up your document types and that is very unfortunate. I've responded to his complaints but unless he can show us how to reproduce his new problem there's not much we can do (we have had 0 reports of a similar problem). Other than that, some packages will not work but won't do much harm either.
Rant over. :-) We'll keep updating the documentation and whenever possible document the v4 and v6 ways of doing it. Other than that, you know this forum is great for getting your questions answered so make sure to keep asking and keep learning! :)
v4 not maintained anymore after tomorrow? Another surprise! Where does one learn about this stuff? Certainly not in the blog, the google dev group, or this forum. "Transparent as glass" is the motto, no? So where are these discussions, decisions, and announcements happening I wonder?
Didn't Niels H. say in the fallout of v5 in the epic "Umbraco 5 Performace Issues" thread, and I quote, "We'll support v4 until the end 2016. It's not going away anytime soon and it's getting a lot of love." ?? (Thread has been deleted from this forum, had to find this in the google cache.)
This is stuff we pitch clients when they pay for us to build them a site. We tell them, "the software your site is built upon will be supported until 2016. We will likely need to talk about you paying for a site upgrade at that point." And they agree to that. So now, in 2013, it's actually tomorrow we have to tell them? Hope there are no more security vulnerabilites found in the v4 line for the next 3 years I suppose...
OK thank you for the clarification. Your post did say "maintaining" which was ambiguous.
However my other question still remains: where is this being discussed? Do you guys (core dev group) have private channels to talk about this stuff?
Re-reading some of the old v5 fiasco stuff to find that quote I posted above, there were promises after the fallout made to be more open and more involving of the community.
I'm just wondering how or in what manner that's actually happening if a guy like myself who spends hours every week---if not every day---reading the dev group, the forums, the blog, the issue tracker, etc. is caught by surprise by these "major" announcements.
Thanks for the reply. I assume that we move on to newer versions because there's something unsatisfactory with the old versions, therefore why use them anymore? So, having chatted to various instructors I decided to jump in with V6, pay for the level 2 course and a Tea Commerce course in the hope that the new API and techniques in V6 will be around for a while. That's all good stuff you must agree. Maybe what I should now do is archive a working version locally and stick to that for all sites for a while. But I'd always think I'm missing out on some productivity enhancement:)
My comment on the lack of maturity for the V6 eco-system was just that, the eco-system, which to me means documentation and packages. We've already covered packagesin earlier comments. You mentioned you already cover the "used to do A now do B" scenario. It would be of great help to me and many others to know where this documentation is. I don't see it in the wiki or the documents section. There are cold, technical references, as there should be, but no friendly "how to" guides that I can see for the V4 to V6 transition. I would also like to suggest that if HQ know that a particular set of packages are VERY popular then they approach the package builders to update, even help them, as the packages, if popular are actually being used as if they are *core", and the lack of them would adversely affect adoption of new versions. You may already do that, I don't know, it's just a thought.
My rant of the other day was just me expressing occasional frustration. But it's good for you to see it, as it shows HQ the pinch points. It's not meant vindictively, it's more howling at the moon;) As they say in some places, "If you don't squeak, you don't get oiled" :) I never forget that this CMS is open-source, free, incredibly easy for content editors and built by the good will of a community.
Maybe it's a good idea to have a section in the documentation called "Changes between v4 and v6" that people can contribute too. I have seen some blog posts about it but I think it would be a good idea to have it also on our so people don't have to google it. I would like to contribute to this.
Also what I'm missing from the current documentation are good code examples. I've read the entire documentation and done the level 2 course in april but sometimes I still have to go and some trial and error to find out how stuff works. And I have been doing Umbraco since v3 so I know how the system works. Just look at the amount of posts about surfacecontrollers. It means the documentation is not clear enough.
But at least now there is some kind of documentation, when I just started it using Umbraco it was almost nothing available.
Hey Craig, did you download the CropUp patch I posted for you?
FYI, I have also Tweeted Niels, the creator of CropUp to remind him of the pull requests to fix the issue and he said he will review very soon, so hopefully CropUp will include the fix.
Thanks for asking. Yes I did thank, but am having some issues with images stretching and floating out of the container. I've had to work on some other stuff for a couple of days. Hope to be back to it tomorrow, but it's weird, pretty sure it's not CSS related. First time I've not used imageGen for the output so no doubt need to work through how to use CropUp for output rather than simply cropping. Will report back if the problem persists.
@Craig We're working hard on new TV episodes which show you the new way of doing things, most subjects are very difficult to document in a side-by-side way and again, almost all of the things you used to do still work. So, where it makes sense we add the version number, if not, the docs should be valid for all versions. If you must have some links:
If you're looking for tutorial content: Umbraco TV.
Anyway, we do what we can in every regard and everything we document we're considering if we need to make it version specific.
That said, I'm sure you'll be happy with the v6 courses showing you all the new ways of working with the ContentService and MediaService, it includes Umbraco TV for further learning and we currently do not have plans to introduce dramatic new changes in the APIs (except for the Members API but we also have plans to include solid samples with that so you can just steal our code ;-)).
Again, I very much value your (and everybody's input), that always plays a big role in how we look at the future.
Ps. Sorry for hijacking this thread and making it completely off-topic!
Something else that might help - we've just posted a simple package that installs the .NET port of the Adaptive Images project to Umbraco. It installs a .NET handler which automatically reduces image resolution and download size for devices with lower resolution without having to modify the source in any way. The package is called uAdaptiveImages and you can download it here...
Back to topic now, if I may :) I know it's been a while but I've been busy on other stuff. So the unfinished 6.1.1 site has today been upgraded to 6.1.3 and CropUp 1.0.0b3 upgraded to 1.0.0b9 (although it still reports itself as 1.0.0b3 in the installed packages section!). My problem is with the Crop Up Responsive stuff. This is the pertinent bits of the code I'm using:-
The paths to CropUp.js and /CropUp/{w}x{h}R/media/1016/soren_larsen.jpg" are correct, however, no image is produced, just a div of the right size with a white background. If you put the image path into a browser (/CropUp/etc.) the image is shown correctly.
Implementing Jeavon's Crop Up patch helped things a bit. I now see partial images (I'll try a partial screen shot here):-
What was the nature of the patch that improved things this far? Should I forget trying to make the images responsive and just use CropUp.GetUrl in an img tag instead?
Gives a very pleasing result on all platforms I've tried. It's probably downloading the full file size but at least they're not enormous images in this case.
However, it would be nice if I could get CropUpResponsive to work.
The patch just fixes an issue with the Umbraco startup handler which was preventing the client js file paths from being correct, hopefully this will be included in the next release of CropUp as I have submitted a new pull request on CodePlex.
Meanwhile we have been doing a lot of experimentation with CropUp responsive and while it does do some amazing client side cropping we also wanted a framework which considered devicePixelRatio so that images can be rendered in hi def for iPads etc, this has lead us to Slimmage & Slimresponse We are still experimenting with both of these but the results are looking very hopeful!
+1 for slimmage and SlimResponse - we've just it on one small thing, and it works well... my next trick is to hack slimmage to use CropUp-style URLs, so we get the intelligent cropping from CropUp too where we want different aspect ratio images.
We have Slimage/Slimresponse working with CropUp just fine, all we had to do was to disable the CropUp clean URLs (remove http handler in web.config) so that CropUp renders standard ImageResizing querystrings and then it just works perfectly.
V6.1.1 Responsive Imaging Strategies
Just doing my first V6.1.1/MVC/Bootstrap/Responsive site, so quite a bit to learn on the way. I have the imaging using DAMP and CropUp. In the past I've used ImageGen to ensure the images were output at the correct pixel size while CropUp ensured the correct form factor. Now that I want the imaging to be responsive, setting the output size doesn't seem right somehow.
So, the question is, how are other people approaching this? I'd be really interested to hear others' opinions.
Cheers,
Craig
We're doing a combination of things depending on what kind of image it is. The trade off is between practicality and amount of effort (i.e. our time) the client will be happy paying for.
For page template/skinning images (images that we create and place and don't allow the client to change) we either drop out things like background images on smaller screens or use a lower-res one which is determined by the active media query.
For user-uploaded images we rely on server-side image resizing (using ImageResizer.NET, which does roughly the same thing as ImageGen) to our desired max desktop-mode width---this is to avoid the client uploading 4,000 pixel wide images that kill even high-end browsers---and on top of this use CSS resizing max-width:100% on them in responsive mode.
If we have a photo gallery, where for example you click on a thumbnail and then get a bigger image in a lightbox/fancybox, the thumbnails are typically around the same size anyway so not much more efficiency to be had with the server-side image resizing, but we add in a little javascript to change the "zoom picture's" hyperlinks to include approximate size of device. This works because the zoom-picture isn't loaded until you click on it, and by then the link has already been rewritten to include ?width=300 parameter or whatever. I round these widths to the nearest 100 (and never larger than 1600) so that the ImageResizer cache doesn't grow beyond a practical size. This makes image galleries very snappy on little phones.
Best of luck to you, Craig!
Maybe this van help you out ?
http://offroadcode.com/blog/2013/1/31/mobile-friendly-images,-creating-responsiveadaptive-images-with-imagegen/
Hey all, did you know that CropUp actually has support for responsive images? There is a bit of info on the CropUp project overview, but basically you just use it like this (classic Razor macro):
and it does the rest :-)
Hi Jeavon,
I didn't know that...Thanks for the great tip!
Dave
Hi Dave,
Yes, I was amazed when I tried it and it just worked :-)
Jeavon
Is there anyway to do that in a partial view, not as a razor macro? I just tried it and got the following in the img src:-
src="<script type="text/javascript" src="/Scripts/CropUp.js"></script><div style="width:100%; height:285px" class="crop-up resizeable" data-gravity="0.5505,0.5627341" data-box="0,0,1,1" data-zoom="true" data-upscale-url="/CropUp/{w}x{h}R/media/1016/soren_larsen.jpg" data-upscale-step="100" ></div>"
from
<img src="@CropUpHtml.CropUpResponsive(itemPhoto.Url, upscaleStep:100,cssClass:"resizeable",style:"width:100%; height:285px")" alt="@itemPhoto.Alt" class="img-polaroid">
Cheers,
Craig
Ah, just realised you just output the thing on it's own, not as an img tag. But Crop Up didn't install a Scripts/CropUp.js so now I just have blank place holder, of the right size though.
@CropUpHtml.CropUpResponsive(itemPhoto.Url, upscaleStep: 100, cssClass: "resizeable img-polaroid", style: "width:100%; height:285px");
Craig
Hi Craig,
You don't need the img tag when using the CropUpResponsive you just call @CropUpHtml.CropUpResponsive
But you reminded me, that there is also a bug in CropUp that I think is only affected by when using this method on IIS7, I actaully submitted a fix a while ago but it makes CropUp only work with Umbraco v6 so hasn't been accepted. Anyway you can download the patched files from here Just overwrite all the dll's in the bin folder (backup first!).
Hope that sorts it out?
Cheers,
Jeavon
Yup, it's not supposed be those script urls, if you install that patch you should find that those js assets are auto managed?
<bit-of-a-rant>
Umbraco is becoming extremely expensive to work with. It just takes FAR too long to get anything done as it all seems to rely on undiscoverable knowledge and patches. Just getting a bit dis-heartened after all the CodeGarden excitement:( All the demos made it look easy. Documentation is SO important. Every iteration is the same, no docs = heartache. And it changes so often that you can never build anything using what you learned last time. Very time consuming and frustrating.
</bit-of-a-rant>
So you mean you don't need a CropUp.js in the Scripts directory, it'll be created by the application? I had downloaded it from http://searchcode.com/codesearch/view/28139204 but it failed as I load my JQuery after the body, not in the header so it croaked on })(jQuery);
Cheers,
Craig
<two-pence>
There is a issue around package/umbraco compatibility and also inter-package dependency and there has been some thoughts about how to deal with this on the Umbraco core Google group. I personally think the documentation to be pretty good now especially for Mvc and there are quite a few samples for the various property editors However Mvc hasn't been widely used yet and some compared to Razor macros or XSLT there is not a lot of examples.
When we find that a package doesn't work properly or is not compatible with the version of Umbraco we are using and we can make a fix, we do so and submit a pull request, that of course doesn't mean that the package author accepts it though!
</two-pence>
If you try the CropUp patch I sent you, then you should see that the JS paths are auto generated?
Cheers,
Jeavon
@Craig I'm going to be very cheeky here and say: me thinks you're getting old. :-) Things change at a fast pace in the software world and Umbraco is no different.
BUT(!) the current v6 is 95% compatible (yes, this is a very scientific number .. as in: bogus but with a large grain of truth) with whatever you wrote in the past 2 years. You do not HAVE to learn any of the new concepts, we've been trying to be very conservative in the last year to make sure that nobody got left behind.
We document more than we used to and we're always happy to hear about areas where Umbraco is painful and hard to get so we can improve. Also not that CropUp is not a plugin we produced, so don't blame us! ;-)
I know this sounds very defensive but let the point be that we're willing to listen, I accidentally stumbled upon this thread and your rant but I love getting constructive criticism and I hope you'll feel comfortable about bringing it up in either email, the core mailinglist, a dedicated post here tweeted to the team, etc. That way we can listen and hopefully help.
Off-topic for this thread.........
Thanks Sebastiaan,
It's not about age, or not wanting to change or learn, it's about getting some lasting value out the effort you put in. I do a new Umbraco site about once every 3 or 4 months. At other times I'm doing other stuff, so I wouldn't consider myself expert in any version of Umbraco. I always use the latest version and always want to use the latest techniques, so those techniques have to be learnt. Nothing wrong with that. But it would be nice if there were some top level guide that could tell you that where you used to do A you now need to do B. That's pretty much it in a nutshell. Detailed technical info is all very well as a reference, but it can be quite daunting when you need a bit of a steer at how to acheive what you did on your last site in your new one with the new API.
I take your point about packages though. I see from Twitter just now that there are mutterings about compatibility with some of them and V6 causing some to downgrade to V4. It'll all come right soon enough. I thought the V6 eco-system was a bit more mature that it was I guess.
I'm very happy to discuss stuff in a constructive way, it's the only way;) That's what I love about the Umbraco Community, always willing to listen and improve. If I can help, I will.
Cheers,
Craig
@Craig Understood, but if you want lasting value then we've got your back with all the legacy that is still supported. Just for you.
If you want to learn the new and fancy way of doing things then you need to be prepared to learn. And yes, we're all about implementing cool new stuff and we document most of it these days. We even document it sometimes saying: in v4.x.y you can do it like this, in v6.x.y you can do it like that.
Your complaint was that you can't build something like you learned the last time, but you want to use the latest techniques, so which is it? Make a choice: try to keep up at cost to you or just do what you used to do in your previous project, you've got plenty of example code there.
Again, I know this sounds defensive but that's only because we've gone through great lengths to keep backwards compatibility intact as much as possible. This takes time, which is costly and frustrating for us.
v6 is very mature, in fact we're not maintaining v4 any more after tomorrow, we're very confident that we have the last kinks worked out by now. There is one package that Simon referred to on Twitter (DocType Mixins), which will mess up your document types and that is very unfortunate.
I've responded to his complaints but unless he can show us how to reproduce his new problem there's not much we can do (we have had 0 reports of a similar problem). Other than that, some packages will not work but won't do much harm either.
Rant over. :-) We'll keep updating the documentation and whenever possible document the v4 and v6 ways of doing it. Other than that, you know this forum is great for getting your questions answered so make sure to keep asking and keep learning! :)
v4 not maintained anymore after tomorrow? Another surprise! Where does one learn about this stuff? Certainly not in the blog, the google dev group, or this forum. "Transparent as glass" is the motto, no? So where are these discussions, decisions, and announcements happening I wonder?
Didn't Niels H. say in the fallout of v5 in the epic "Umbraco 5 Performace Issues" thread, and I quote, "We'll support v4 until the end 2016. It's not going away anytime soon and it's getting a lot of love." ?? (Thread has been deleted from this forum, had to find this in the google cache.)
This is stuff we pitch clients when they pay for us to build them a site. We tell them, "the software your site is built upon will be supported until 2016. We will likely need to talk about you paying for a site upgrade at that point." And they agree to that. So now, in 2013, it's actually tomorrow we have to tell them? Hope there are no more security vulnerabilites found in the v4 line for the next 3 years I suppose...
Signed,
-Confused.
@Funka And we'll blog about it tomorrow.
Of course we'll do security releases when necessary and if there's really something elseseriously wrong with v4 as it is we will be updating it.
Oh and to make it clear: Support != Updates.
OK thank you for the clarification. Your post did say "maintaining" which was ambiguous.
However my other question still remains: where is this being discussed? Do you guys (core dev group) have private channels to talk about this stuff?
Re-reading some of the old v5 fiasco stuff to find that quote I posted above, there were promises after the fallout made to be more open and more involving of the community.
I'm just wondering how or in what manner that's actually happening if a guy like myself who spends hours every week---if not every day---reading the dev group, the forums, the blog, the issue tracker, etc. is caught by surprise by these "major" announcements.
Thank you.
@Sebastiaan,
Thanks for the reply. I assume that we move on to newer versions because there's something unsatisfactory with the old versions, therefore why use them anymore? So, having chatted to various instructors I decided to jump in with V6, pay for the level 2 course and a Tea Commerce course in the hope that the new API and techniques in V6 will be around for a while. That's all good stuff you must agree. Maybe what I should now do is archive a working version locally and stick to that for all sites for a while. But I'd always think I'm missing out on some productivity enhancement:)
My comment on the lack of maturity for the V6 eco-system was just that, the eco-system, which to me means documentation and packages. We've already covered packagesin earlier comments. You mentioned you already cover the "used to do A now do B" scenario. It would be of great help to me and many others to know where this documentation is. I don't see it in the wiki or the documents section. There are cold, technical references, as there should be, but no friendly "how to" guides that I can see for the V4 to V6 transition. I would also like to suggest that if HQ know that a particular set of packages are VERY popular then they approach the package builders to update, even help them, as the packages, if popular are actually being used as if they are *core", and the lack of them would adversely affect adoption of new versions. You may already do that, I don't know, it's just a thought.
My rant of the other day was just me expressing occasional frustration. But it's good for you to see it, as it shows HQ the pinch points. It's not meant vindictively, it's more howling at the moon;) As they say in some places, "If you don't squeak, you don't get oiled" :) I never forget that this CMS is open-source, free, incredibly easy for content editors and built by the good will of a community.
Keep up the good work.
Craig
@Sebastiaan, @craig
Maybe it's a good idea to have a section in the documentation called "Changes between v4 and v6" that people can contribute too. I have seen some blog posts about it but I think it would be a good idea to have it also on our so people don't have to google it. I would like to contribute to this.
Also what I'm missing from the current documentation are good code examples. I've read the entire documentation and done the level 2 course in april but sometimes I still have to go and some trial and error to find out how stuff works. And I have been doing Umbraco since v3 so I know how the system works. Just look at the amount of posts about surfacecontrollers. It means the documentation is not clear enough.
But at least now there is some kind of documentation, when I just started it using Umbraco it was almost nothing available.
Also some things are documented but I don't have a clue what is meant for : http://our.umbraco.org/documentation/Reference/Plugins/
When I created a forum post about it it got no reply so I don't think it's clear to a lot of people : http://our.umbraco.org/forum/developers/api-questions/39876-What-are-plugin-resolvers
Some tips for the use of this forum is that there should be a MVC templates section.
Dave
Hey Craig, did you download the CropUp patch I posted for you?
FYI, I have also Tweeted Niels, the creator of CropUp to remind him of the pull requests to fix the issue and he said he will review very soon, so hopefully CropUp will include the fix.
Thanks,
Jeavon
Hi Jeavon,
Thanks for asking. Yes I did thank, but am having some issues with images stretching and floating out of the container. I've had to work on some other stuff for a couple of days. Hope to be back to it tomorrow, but it's weird, pretty sure it's not CSS related. First time I've not used imageGen for the output so no doubt need to work through how to use CropUp for output rather than simply cropping. Will report back if the problem persists.
Cheers,
Craig
@Funka http://umbraco.com/follow-us/blog-archive/2013/6/28/umbraco-612-and-607-released.aspx explains our process of stopping with v4. Agreed upon by 5 MVPs, a handful of friends of the project and backed by the entire HQ. Not all of our decisions will be made in public, we'd soon end up in a "design by committee" project.
@Craig We're working hard on new TV episodes which show you the new way of doing things, most subjects are very difficult to document in a side-by-side way and again, almost all of the things you used to do still work. So, where it makes sense we add the version number, if not, the docs should be valid for all versions. If you must have some links:
http://our.umbraco.org/documentation/Using-Umbraco/Config-files/ (mentions v7 even)
v4 http://our.umbraco.org/documentation/Reference/Management/ vs.v6 http://our.umbraco.org/documentation/Reference/Management-v6/
Multiple versions listed: http://our.umbraco.org/documentation/Reference/Events/application-startup
"Applies to v4.10.x" - http://our.umbraco.org/documentation/Reference/Plugins/
If you're looking for tutorial content: Umbraco TV.
Anyway, we do what we can in every regard and everything we document we're considering if we need to make it version specific.
That said, I'm sure you'll be happy with the v6 courses showing you all the new ways of working with the ContentService and MediaService, it includes Umbraco TV for further learning and we currently do not have plans to introduce dramatic new changes in the APIs (except for the Members API but we also have plans to include solid samples with that so you can just steal our code ;-)).
Again, I very much value your (and everybody's input), that always plays a big role in how we look at the future.
Ps. Sorry for hijacking this thread and making it completely off-topic!
Something else that might help - we've just posted a simple package that installs the .NET port of the Adaptive Images project to Umbraco. It installs a .NET handler which automatically reduces image resolution and download size for devices with lower resolution without having to modify the source in any way. The package is called uAdaptiveImages and you can download it here...
Back to topic now, if I may :) I know it's been a while but I've been busy on other stuff. So the unfinished 6.1.1 site has today been upgraded to 6.1.3 and CropUp 1.0.0b3 upgraded to 1.0.0b9 (although it still reports itself as 1.0.0b3 in the installed packages section!). My problem is with the Crop Up Responsive stuff. This is the pertinent bits of the code I'm using:-
The line: @CropUpHtml.CropUpResponsive(itemPhoto.Url, upscaleStep: 200, cssClass: "img-polaroid", style:"height:200px;", id:"editor-target", cropAlias:"staffPic");
Produces HTML :
The paths to CropUp.js and /CropUp/{w}x{h}R/media/1016/soren_larsen.jpg" are correct, however, no image is produced, just a div of the right size with a white background. If you put the image path into a browser (/CropUp/etc.) the image is shown correctly.
Am I missing something here?
Thanks,
Craig
Implementing Jeavon's Crop Up patch helped things a bit. I now see partial images (I'll try a partial screen shot here):-
What was the nature of the patch that improved things this far? Should I forget trying to make the images responsive and just use CropUp.GetUrl in an img tag instead?
Cheers,
Craig
Switching this line:-
To this:-
Gives a very pleasing result on all platforms I've tried. It's probably downloading the full file size but at least they're not enormous images in this case.
However, it would be nice if I could get CropUpResponsive to work.
Cheers,
Craig
Hi Craig,
The patch just fixes an issue with the Umbraco startup handler which was preventing the client js file paths from being correct, hopefully this will be included in the next release of CropUp as I have submitted a new pull request on CodePlex.
Meanwhile we have been doing a lot of experimentation with CropUp responsive and while it does do some amazing client side cropping we also wanted a framework which considered devicePixelRatio so that images can be rendered in hi def for iPads etc, this has lead us to Slimmage & Slimresponse We are still experimenting with both of these but the results are looking very hopeful!
Although it's slightly different I have also seen a new package call uAdaptiveImages built on top of AdaptiveImages
Thanks,
Jeavon
+1 for slimmage and SlimResponse - we've just it on one small thing, and it works well... my next trick is to hack slimmage to use CropUp-style URLs, so we get the intelligent cropping from CropUp too where we want different aspect ratio images.
Phil
Hi Phil,
Did you have any joy in merging Slimmage/Slimresponse and CropUp? I'm looking to do a very similar thing.
Thanks
Hi Dan,
We have Slimage/Slimresponse working with CropUp just fine, all we had to do was to disable the CropUp clean URLs (remove http handler in web.config) so that CropUp renders standard ImageResizing querystrings and then it just works perfectly.
Thanks,
Jeavon
Cheers Jeavon. Does that work with crop aliases too?
Hi Dan, I've not actually tried it but I'm pretty sure it will work as it just adds to the querystring
is working on a reply...