I've been using CropUp since it became available but I've never understood the licensing for the bundled library... This, however, does an awesome job of just "install and forget". Without touching anything it seems to do caching of images requested from CropUp too, which is a huge deal for us.
There is a teeny-weeny problem I'm trying to debug though, and I need to test this by disabling and enabling the processor - what's the preferred way of disabling ImageProcessor? Is there a config setting I can flip to temporarily disable it, or do I need to remove the Web.config entries?
@James: I need to completely disable it to do the testing - setting maxDays to -1 will still use the processor, I guess, so will have to do the web.config thing, as Morten suggested.
(My issue is that CropUp also accepts a "quality" parameter, so I have a feeling that when I set quality=40 that I'll actually get an image that's been reduced to 40 first by ImageProcessor, and then again by CropUp, resulting in an even lower quality... but I don't know that yet :-)
I have a similar problem where ImageProcessorModule interferes with image urls that are served from another application through a reverse proxy setting.
It would be really nice to be able to exclude paths form being processed.
For now we just disabled ImageProcessorModule in web.config.
I have a similar problem where ImageProcessorModule interferes with image urls that are served from another application through a reverse proxy setting.
Could you please be more specific. Your comment otherwise is most unhelpful. Also, please remember that this is open source and there is nothing stopping you making a contribution to the solution.
In our case we have a sub site that serves images with urls like the following:
/download/attachments/951127/System%20Overview.png?version=2&modificationDate=1249916257000&api=v2.
IIS returns a 404 and using Failed request tracking I found that ImageProcessor strips away the ?.
Thanks for the extra information, I appreciate it.
Are you planning on appending any ImageProcessor specific querystring parameters to the url?
ImageProcessor is returning a 404 as it is trying to pull the path from a local source as it knows nothing about your reverse proxy. You can see where it does this here
If you are going to use ImageProcessor to process and cache these images then I would suggest you created an implementation of IImageService. If not, would appending ipignore=true to your querystring parameters be sufficient?
ImageProcessor comes with its own configuration system so they would go in there somewhere.
That being said, I'm not actively working on this version anymore as I'm attempting to create a cross-platform imaging library for vNext. If you have some time and would like to add that functionality, get in touch and I can give you some pointers.
We are encountering the similar issue wherein the imageprocessor seems to interfere with the rendering of images via reverse proxy. We cannot remove the module since we require it for Umbraco images. . Also could not find any configuration file for ImageProcessor in the Umbraco setup wherein we can turn this off for selective paths. Is there any work around . Any help will be greatly appreciated.
Did you by any chance come up with a solution for this? I've just hit the same issue where the images just return 404 via reverse proxy. I'll dig into the docs but it would be good to know if you managed to get it working?
I'll try to explain. We have a standard Umbraco website (if there is such a thing) currently running 7.3.2, lets say http://www.website.com. We also have an old .Net 3.5 app that we need to sit beneath the same domain, say http://www.website.com/oldapp.
If we put the old app physically within the Umbraco site directory or create a virtual directory, we hit a lot of compatibility issues due to the different .Net versions. Instead we are trying to use IIS Application Request Routing (AAR) which effectively uses IIS URL Rewrite, configured within the main site web.config, to rewrite any requests on the "/oldapp/" path to a separate website. In that way we keep the 2 sites separate but they appear as one to end users.
I'm not an expert in AAR but it seems the "oldapp" application does still inherit some configuration from the parent Umbraco site. One example of this is that the ImageProcessorModule HTTP Module is still part of the pipeline. I even tried to "remove" that module in the sub app's web.config but that didn't seem to have any effect.
The result is that the sub app works and serves all requests on the http://www.website.com/oldapp path except for images. If I remove the ImageProcessorModule from the Umbraco web.config the images start working in the sub-app.
I hope that makes sense? I'll check the docs to see if there's anything covering for this scenario.
I followed the suggestion "There's extensive configuration options for ImageProcessor.Web you can find them in the documentation." I also needed to upgrade the version of image processor dll along with the required configuration which helped me to sort this issue
Thanks, I'm just trying out the same scenario on the latest Umbraco and ImageProcessor and early signs seem to be that it works. So I may just need to upgrade to the latest. I'll update here again later...
Yes it seems simply upgrading to the latest ImageProcessor.Web package has fixed this issue for me.
Is it safe to upgrade to the latest ImageProcessor.Web package but not also upgrade Umbraco? The website seems to be loading fine on first inspection, and I could do without upgrading Umbraco at the moment.
Is there an on/off switch?
Awesome package!
I've been using CropUp since it became available but I've never understood the licensing for the bundled library... This, however, does an awesome job of just "install and forget". Without touching anything it seems to do caching of images requested from CropUp too, which is a huge deal for us.
There is a teeny-weeny problem I'm trying to debug though, and I need to test this by disabling and enabling the processor - what's the preferred way of disabling ImageProcessor? Is there a config setting I can flip to temporarily disable it, or do I need to remove the Web.config entries?
/Chriztian
I think you need to remove the line
from your web.config
In the
config\imageprocessor
folder in your installation there is a file calledcache.config
If you change the
maxDays
value to -1 that will force the cache system to pull a new version every time.Any issues just give me a shout.
http://jimbobsquarepants.github.io/ImageProcessor/getting-started.html#config
Thanks guys!
@James: I need to completely disable it to do the testing - setting maxDays to -1 will still use the processor, I guess, so will have to do the web.config thing, as Morten suggested.
(My issue is that CropUp also accepts a "quality" parameter, so I have a feeling that when I set quality=40 that I'll actually get an image that's been reduced to 40 first by ImageProcessor, and then again by CropUp, resulting in an even lower quality... but I don't know that yet :-)
/Chriztian
Hi!
I have a similar problem where ImageProcessorModule interferes with image urls that are served from another application through a reverse proxy setting.
It would be really nice to be able to exclude paths form being processed.
For now we just disabled ImageProcessorModule in web.config.
/René
Hi Rene,
Could you please be more specific. Your comment otherwise is most unhelpful. Also, please remember that this is open source and there is nothing stopping you making a contribution to the solution.
James
Hi James!
In our case we have a sub site that serves images with urls like the following: /download/attachments/951127/System%20Overview.png?version=2&modificationDate=1249916257000&api=v2.
IIS returns a 404 and using Failed request tracking I found that ImageProcessor strips away the ?.
Hi René,
Thanks for the extra information, I appreciate it.
Are you planning on appending any ImageProcessor specific querystring parameters to the url?
ImageProcessor is returning a 404 as it is trying to pull the path from a local source as it knows nothing about your reverse proxy. You can see where it does this here
If you are going to use ImageProcessor to process and cache these images then I would suggest you created an implementation of
IImageService
. If not, would appendingipignore=true
to your querystring parameters be sufficient?Cheers
James
Hi James!
Thanks for your interest and time :)
In this particular installation we do not use ImageProcessor, so I just turned it off in web.config.
ipignore would not work because we do not have control over the content of the site hosting the images.
The best would be to have a setting in web.config where you could add paths that should be excluded from image processing.
/René
Hey René,
ImageProcessor comes with its own configuration system so they would go in there somewhere.
That being said, I'm not actively working on this version anymore as I'm attempting to create a cross-platform imaging library for vNext. If you have some time and would like to add that functionality, get in touch and I can give you some pointers.
James
Hi James,
We are encountering the similar issue wherein the imageprocessor seems to interfere with the rendering of images via reverse proxy. We cannot remove the module since we require it for Umbraco images. . Also could not find any configuration file for ImageProcessor in the Umbraco setup wherein we can turn this off for selective paths. Is there any work around . Any help will be greatly appreciated.
Regards Raghav
Hi Raghav,
There's extensive configuration options for ImageProcessor.Web you can find them in the documentation.
http://imageprocessor.org/imageprocessor-web/configuration/
Cheers
James
Hi Rene/Raghav,
Did you by any chance come up with a solution for this? I've just hit the same issue where the images just return 404 via reverse proxy. I'll dig into the docs but it would be good to know if you managed to get it working?
Thanks James
Can someone please draw a diagram or something that will allow me to see how your applications are working?
Hi James,
I'll try to explain. We have a standard Umbraco website (if there is such a thing) currently running 7.3.2, lets say http://www.website.com. We also have an old .Net 3.5 app that we need to sit beneath the same domain, say http://www.website.com/oldapp.
If we put the old app physically within the Umbraco site directory or create a virtual directory, we hit a lot of compatibility issues due to the different .Net versions. Instead we are trying to use IIS Application Request Routing (AAR) which effectively uses IIS URL Rewrite, configured within the main site web.config, to rewrite any requests on the "/oldapp/" path to a separate website. In that way we keep the 2 sites separate but they appear as one to end users.
I'm not an expert in AAR but it seems the "oldapp" application does still inherit some configuration from the parent Umbraco site. One example of this is that the ImageProcessorModule HTTP Module is still part of the pipeline. I even tried to "remove" that module in the sub app's web.config but that didn't seem to have any effect.
The result is that the sub app works and serves all requests on the http://www.website.com/oldapp path except for images. If I remove the ImageProcessorModule from the Umbraco web.config the images start working in the sub-app.
I hope that makes sense? I'll check the docs to see if there's anything covering for this scenario.
Thanks.
Hi ,
I followed the suggestion "There's extensive configuration options for ImageProcessor.Web you can find them in the documentation." I also needed to upgrade the version of image processor dll along with the required configuration which helped me to sort this issue
Regards Raghav
Thanks, I'm just trying out the same scenario on the latest Umbraco and ImageProcessor and early signs seem to be that it works. So I may just need to upgrade to the latest. I'll update here again later...
Yes it seems simply upgrading to the latest ImageProcessor.Web package has fixed this issue for me.
Is it safe to upgrade to the latest ImageProcessor.Web package but not also upgrade Umbraco? The website seems to be loading fine on first inspection, and I could do without upgrading Umbraco at the moment.
Totally safe to do so.
I've no idea what I would have changed in ImageProcessor.Web to make it work, let me know if any issues come up.
Cheers James. Still working well at the moment.
is working on a reply...