Bump: _media not being resolved when image placed via editor in contentbox

I am reposting this previous topic, as I am having a really hard time with it and I would very much appreciate any help. But I am having the same problem as Lee in the previous post, where an image will not display on the page. No errors are generated when the page loads, other than the “image not found” icon.

It seems as if the __media route is not being “translated” properly. When I view source on the page, the img src for the image is simply . Trying to access that URL directly results in a 404 error. If I hard-code the URL, such as https://mysite.com/modules_app/contentbox-custom/_content/myImage.jpg, then the image displays fine.

Note that the media manager itself works fine as far as uploading images, showing what is in the folder, and so on. But trying to insert an image will result in the same “image not found” behavior, even in the preview function of the media manager.

I am using vanilla ACF 2016, IIS 8.5 on Windows Server 2012, ContentBox 4.2.1. I have tried editing / adding routes and mappings in ContentBox and ColdBox. I have tried CF mappings, and even rewrite rules on IIS. Nothing defeats __media! :slight_smile:

Let me know if I can provide any further information! Thank you very much!

Following up on this… I have reached out to my hosting company for help. They are suggesting URL rewrites in IIS, but they are not working either. There seems to be something going on “under the hood” with the ContentBox installation that just does not seem to be working properly.

Here are some things I have noticed:

  1. Installed on my laptop, accessed locally, it works fine – ACF 2016, Lucee, does not matter

  2. Does not work on production server with ACF 2016 installed.

  3. Does not work on production server using canned ACF 2016 and Lucee servers.

  4. Other services using the same URL routing pattern do work, such as https://mysite.com/__search.

I don’t know much about ContentBox, but it seems as if the __media route is somehow being set as “canonical” somewhere, and I do not seem to be able to override it or change it in anyway. Here is what I have tried:

Changed settings in cbadmin to tell the application where the root directory of my content is located.

Made changes in \modules\contentbox\modules\contentbox-ui\ModuleConfig.cfc.

Made changes in \modules\contentbox\modules\contentbox-ui\handlers\media.cfc.

Tried creating new routes or URL rewrites in the ColdBox.

Created ColdFusion mappings and URL rewrite rules in IIS.

None of these changes had any impact at all – the __media pattern seems impervious to anything I throw at it. Note, I restart the application – and usually ColdFusion itself – each time I make changes. I have cleared CF’s template cache.

Is there some way I can simply turn off the __media route altogether, and just use the full normal URL? It seems a shame to have to do that, but I will be unable to use ContentBox for our websites if I cannot get this resolved. And so far, I am completely stumped! Thanks a lot!

Did you try to add a simple mapping to the main application context? That is what I would try to do, add a mapping of the url that is retrieving the 404 to the physical path.

Thanks a lot Andreas, I did try that, but perhaps I did it wrong. I added this to the main application.cfc:

this.mappings[ “/__media” ] = COLDBOX_APP_ROOT_PATH & “/modules_app/contentbox-custom/_content”;

I reinitialized and am still getting the 404 error when I browse to https://mysite.org/__media/d-1007.jpg, but https://mysite.org/modules_app/contentbox-custom/_content/d-1007.jpg works.

Any more suggestions? I really appreciate the response.

Hi Randy,

I see. I was on my mobile, now I am reading all your post. So you’ve posted that you are fronting with IIS. I work on Railo/Lucee since 2010, so sorry if I can’t give you more detailed information with ACF. But as this having to do with an image, I suppose it is a direct IIS problem, because usually if you front your application with IIS, only CFM/CFC files get through to tomcat, unless you change that behaviour. That means that any change in tomcat or paths in application.cfc won’t change anything, because it is missing in IIS.

What I would do:

Connect to your remote machine, and from there open a browser and try to load the image directly on IIS port 443 ( https://mysite.com/__media/my-pic.jpg ). Does the image show up?

Yes: If you can see the image loaded from the browser on your remote machine, then check if you still can’t access the image from the browser of your development machine. If it can’t be loaded from your dev machine, there is something else causing this (example firewall with some type of URL-Filter).

No: What is the exact detailed 404.x Error you are getting? The x stands for the detailed type of error, such as 404.13 for content-lenght maximun exceeded, or 404.2 for ISAPI restrictions)? This error is shown very differently from the one you would get when accessing with a browser from your development machine (the public version hasn’t any detailed sensitive information that is causing the 404 error, it won’t show any detailed information). By doing this you will see what exactly is causing the error. It could be a simple url-filter in IIS , a permission issue, or another thing. Check that. Also take a look into your event viewer. this type of error should pop up there also.

Additionally: Check if you have an virtual directory "/__media/ " added pointing to the path with that images. If not done, right click on the root directory, add it there.

Hope that may point to some type of direction. Good luck and please keep us informed about any progress.

I mean do that in the Microsofts IIS Web Manager:
"Additionally: Check if you have an virtual directory “/__media/ " added pointing to the path with that images. If not done, right click on the root directory, add it there.”

Hello Andreas, thank you so much for the help! The IIS logs only showed a simple 404.0 error, and nothing else was having any impact, so upon your troubleshooting advice I started looking more closely at the IIS rewrite rules I was trying out. And that ended up being the fix!

Here is the rule that ended up doing the trick, in case anybody else might find it helpful. I did not add a virtual directory; this rule seems to be working well so far, both on the public-facing web pages as well as within the ContentBox editor and admin interface.

Thanks for pointing me in the right direction, Andreas! Your advice really helped narrow it down for me. I appreciate you taking the time. Have a great weekend!

Hi Randy, really, really glad you got it working. From my perspective, you got it working all by yourself! You only needed a slightly hint to identify what was going on. The url-rewrite is a good working solution. I am sure the virtual directory would do it also. Both solutions are very valid. Glad you’ve done it. Glad I could give you some inspiration. Thanks for sharing your working solution. Best wishes, be safe and have a very good weekend also.

Just a little side note... Your rule will be applied to jpgs only. Don't know contentbox that well, but because this media directory is a directory for uploaded media files, please keep in mind that whenever you upload a media file with a different file extension than .jpg (e.g. .jpeg .png .gif ), you'll need to adapt/update the url rewrite rule to work for them also.

Best wishes.

wow, that is so tricky.

Where do you think it would be best to add to the docs about this, ideas?

Hello Andy, thanks for the reply! You make a good point, and I always get confused by IIS rewrite rules anyways, so I took another look at your suggestion of a virtual directory, and that seems to be working just as well! Better, in fact, since I do not have to update it or worry about adding new file types in the future. It tried it on a gif as well as a png in s subdirectory – no problems. Much easier than messing with rewrite rules. Thank you so much for the advice!

PS sorry I called you Andreas earlier – I was reading on a phone also and did not pay close enough attention!

Hi Luis, I think one good place would be in the Getting Started guide, System Requirements > URL Rewrites section, since IIS rewrites are already being discussed there. A quick caveat that IIS users might need to follow Andy’s advice and create a virtual directory for __media that points to modules_app\contentbox-custom_content might be very helpful. It would have saved me a lot of time, that is for sure! :slight_smile:

And this does seem to be IIS-specific. I had noted in earlier posts that __media works fine on my dev machine, but I remembered later that it was running Apache. I spun up a Windows VM with IIS and had the exact same problem, even though it too was all localhost. I do not know about nginx.

Side note, we are switching some sites away from WordPress and so far, our content people are very happy with ContentBox. Great work!!

Hahaha… You were not wrong by calling me Andreas. My real name is Andreas (in reality this is my second name). Once I’ve put my name as Andy here, because here in Germany some people think it sounds somehow cooler in English. But you can call me however you want. Andreas or Andy is totally ok!

@Luis… Thanks for chiming in. I thought something like an Frequent Asked Questions section with some common pitfalls might be a good place. I really wouldn’t put it directly in the middle of the documentation, because it is not a problem of contentbox per se. It pops up when you have a webserver fronted and some mapped virtual directories for static files that are setup in the servlet container webserver, are not set in the fronted webserver. That also happens in pure Lucee installation, when you try to access its installed default webapp or the server/web admin over IIS (port 80 or 443). I’ll think about it and will come back to you soon.

Have a nice day.