Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Images disappear #18

designerdean opened this Issue Oct 7, 2011 · 40 comments


None yet
6 participants

I tried implementing this but when I tried navigating to my website the image paths appeared broken. I was referencing them in the HTML as img src="img/IMAGENAME.jpg". Have you encountered this problem? If so, how do I fix it? I was sure to set everything up as outlined (added .htaccess, adaptive-images.php, and writable ai-cache directory to root, added line of script to head of HTML page). Thanks for the help!


MattWilcox commented Oct 8, 2011

Hi there,

no i haven't, but I've also never tried it with relative paths in the mark-up like you have there. It shouldn't make any difference though. When you say they are broken, are they showing anything at all? If AI errors it generally spits out an error message inside the image, rather than no image at all.

I was having the same issue on Hostgator when using their default IP address/~username path to access my site. All the images were showing as 404 errors when I looked in Fiddler. Once I had a real domain name pointing at the site everything works fine, though. Maybe that's the issue you're seeing?

I've tested it in production and I still get the problem. I actually narrowed it down to the .htaccess file - once I add that, the image paths break. I'm not a PHP guy at all, so maybe I'm missing some key element here...

I'm an idiot - I just read the part in the documentation that said the htaccess file assumes your images are in an assets folder. I just changed the

RewriteCond %{REQUEST_URI} !assets
RewriteCond %{REQUEST_URI} !img (because my images are in the img folder)

Should this work?

@designerdean designerdean reopened this Oct 15, 2011


MattWilcox commented Oct 17, 2011

No, it should work as is - note the exclamation mark - that means (as mentioned in the comment above that code) that AI will apply to all images in all folders except the ones listed. It sounds like a host configuration problem, but I won't have chance to test for another few days, sorry.

@MattWilcox MattWilcox closed this Oct 17, 2011

Would you have time to look at this and see what's going on? http://www.silvermaplephotography.com


MattWilcox commented Dec 23, 2011

Well you've commented out the AI JS, so nothing at all will be going on I imagine :)

Yeah, I know, sorry. When I implement all the Adaptive Images stuff the site becomes unusable, and I don't have a testing environment so I don't like leaving it unusable for very long. I'll implement it all now in the hopes you can look at it soon :)


MattWilcox commented Dec 23, 2011


It's not finding any of your images, they are all becoming 404's. That would indicate that the path in the .htaccess file is not valid for your server. What's the directory structure on your server, and where are the files?

This SilverMaplePhotography.com is not the default website on my hosting account - so it's in a folder on the root where the domain points to. I'm not sure if that's what you're looking for, I'm not super knowledgable with hosting and such.


MattWilcox commented Dec 23, 2011

That's likely to be the problem right there.

In your .htaccess try this:

RewriteRule .(?:jpe?g|gif|png)$ /YOUR-SITE-FOLDER-NAME/adaptive-images.php

That didn't seem to work...


MattWilcox commented Dec 23, 2011

Hmmm, try making it relative then?

RewriteRule .(?:jpe?g|gif|png)$ adaptive-images.php

The adaptive-images.php will need to be in the same level as the .htaccess, and both of those should be in your site root folder.

Yeah it's all on the root of that website folder. The htaccess, html pages, adaptive-images.php, ai-cache, they're all on the root. And the relative path would just be what was already in the htaccess file.


MattWilcox commented Dec 23, 2011

That's confusing, I can't imagine why the paths are wrong then.

For the sake of finding where the problem is, can you change the .htaccess to this:

RewriteRule .(?:jpe?g|gif|png)$ img/home/078.jpg

That should remove all of the php processing and will simply make every image load that one. If that works then we know the problem is in the PHP file and not the htaccess.

Updated and deployed. Looks like that one image is appearing on the home page (scroll to the right to see).


MattWilcox commented Dec 23, 2011

Wow, well THAT is quite the bizarre result!

I have no idea why it is doing that. The instruction tells apache to take any request for any JPG/JPEG/PNG/GIF and instead return the img/home/078.jpg image. They should all be that image, not just that one. Is there anything else in your htaccess file?

No, it's literally just the file downloaded from the AI zip folder. My web pages aren't PHP by the way, they're HTML - that's not causing the problem, is it?


MattWilcox commented Dec 23, 2011

No that won't cause a problem, AI will work with anything as long as PHP is available on the server.

It looks like the problem is with Apache (which is parsing the .htaccess file). We can tell it's Apache because with the last .htaccess rule we made sure that none of the PHP is getting run, so neither the PHP nor the cookie are relevant with the last test.

The problem now is that I have no idea why Apache would be producing such an odd result, and I'm definitely not an Apache expert so I can't help you any further :( I'll put a call out on Twitter.

Thanks for the help Matt, much appreciated.

I'm on GoDaddy hosting, not sure if that information helps.


MattWilcox commented Dec 23, 2011

Sorry you're having such issues :( Hopefully someone can answer this puzzle.

So I should add that code before the RewriteCond line?


MattWilcox commented Dec 23, 2011

By the looks of it, yes :)


MattWilcox commented Dec 23, 2011

Looking into it further, put it right at the top of the file.


I might be setting it up wrong but none of those seem to work

Joshua, I checked the page you provided, http://www.silvermaplephotography.com , and found that the front page loads pictures worth of 35MBs immediately after I open your front page.

Please consider that it is - let's put it this way - not the best practice. Just imagine those who happen to open your site from a connection where they have to pay per kilobytes (quite common on mobile). Or what if they only came for a phone number on the contact page?

Users should either receive a warning to data heavy content, or be enabled to make the choice if they want to load in the 35MB or not (I'm not talking about saving those pics on disk: as soon as you caught a glimpse of them on the screen they have already eaten up the bandwidth). So it's better to have a subpage for the gallery too: whoever opens it, they should be clever enough to expect the data heavy content - but they were given at least the choice.

Should you decide to carry out changes accordingly, this might be useful:

instead of: img src="img/home/011.jpg"

could use: img src="/img/home/011.jpg" // note the slash the path begins with!

the message of that slash is that the img folder is sitting right in the document root - regardless of where the .html file is in the directory structure in which you define this path.

relative path: img/home/something.file //relates to the position of the .html file it is defined in

semi-absolute path: /img/home/something.file //always the document root of that domain

absolute path: yourdomain.com/img/home/something.file //absolute shot, but may become a burden if you migrate the pages to a different domain

(I hope I used the terms in their right place)

I know it's not best practice, that's why I am trying to implement Adaptive Images, which states, "On those devices your desktop-centric images load slowly, cause UI lag, and cost you and your visitors un-necessary bandwidth and money. Adaptive Images fixes that." If this would work, it would resolve that problem. And I disagree with what you say about having a subpage for the gallery. I mean, what year is this, 1999??

Having a slash at the beginning of the source doesn't work. It shouldn't even matter since both the HTML files and the img folder are on the same level (at the root).

Thanks for trying to help!


ghost commented May 5, 2012

I got the same issue, but to make things clear, I will explain my own case.

1st, I got 500 Internal server error. I found out the cause is because my shared hosting Apache server configuration is : "AllowOverride AuthConfig Limit FileInfo Indexes" which pretty much said "Options is blocked" due to security reason. The temporary solution for that is just basically comment out the Options +FollowSymlinks

Then, I got the page back but all the images are disappeared. I did the RewriteRule .(?:jpe?g|gif|png)$ img/home/078.jpg as mentioned above to check the error and I got the same symptoms just like Joshua. However, spending hours, basically you just need to add RewriteBase / (where / means your server root). Now all the images are converted into the one defined from the link.

However, as I changed this back into adaptive-images.php, it shows the images, but nothing happen. Any idea what's happening now?


ghost commented May 5, 2012

More update:
I used the guide in #32
and looks the .htaccess is working now because I got the black error image.

This is what it said:
Adaptive Images encountered a problem:
there is a problem

potentially useful information:

DOCUMENT ROOT IS : /s/lab.richardtirta.com/www
REQUESTED URI WAS: /images/gallery/frezty.01.jpg
SOURCE FILE IS: /s/lab/lab.richardtirta.com/www/images/gallery/frezty/01.jpg

Noted that I did put my images in /image/gallery/frezty/
Gee,, how come I got all the problems listed here....


MattWilcox commented May 5, 2012

It looks like your server config is unusual is why you have problems.

When AI reports an error using the black images, it should spit out the cause of the second line - where you are seeing "there is a problem". If you're using the latest version (1.5.2) then that string doesn't exist and the only errors reported should be:

"Failed to create cache directory..."
"The cache directory is not writable..."
"Failed to create image..."

Try using 1.5.2 and seeing which of those is it reporting.


ghost commented May 5, 2012

No good, I used the latest one already.



MattWilcox commented May 5, 2012

There is something wrong - the string "there is a problem" does not exist in the adaptive-images.php file, which means your server can not be using the 1.5.2 version of AI. Maybe an old one is cached? Perhaps the image has been cached? Very very weird.


ghost commented May 5, 2012

Ah! As per #32
I put sendErrorImage("there is a problem"); in the adaptive-images.php

Otherwise all the image will be shown but nothing will happen (ai-cache is not created and so on).


MattWilcox commented May 5, 2012

Right... then you're forcing an error.

If you're seeing images without having put that error in there, then AI is already working properly. There is nothing wrong with it. If the source image was large enough to require shrinking, and AI failed to do that then you would be seeing an error message image saying so. Chances are that you're testing this on a large monitor at a break-point that's larger than your source image?

Try changing the JS to force AI to believe you're on a mobile phone:

<script>document.cookie='resolution=480; path=/';</script>

You should now see an ai-cache directory being created. Be sure to change the JS back to the real one once you've confirmed that it was working.


ghost commented May 5, 2012

Ah yeah! It works! Thanks a lot!
Btw, I think you need to put RewriteBase / in your .htaccess code (or at least in installation instruction) because it set the root mod_rewrite to the correct root.


MattWilcox commented May 5, 2012

Awesome, thanks for that tip - I'll have a play and see if that does what we want it to - I'm no Apache / ModRewrite expert and that's been annoying me.

In case anyone else has this same issue, I did, and the fix for me was to add, as suggested by DragoWater:

RewriteBase /

above my RewriteCond line(s)in .htaccess, and then it started working.

Thank you ryanschweitzer for the above!!!!! i could kiss you :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment