I'm running Boost 6x-1.18 and creating a lot of thumbnail previews with Imagecache and Views. Multiple times per day one of my pages will show broken images to anonymous users, until I manually flush the cache for that page. Then the images show correctly. An hour or two later, those images display as broken again.

Often, clicking on the actual node will show the full image, but not always. Flushing the cache for that page works again.

Any ideas why this behavior might occur? Has this been seen by anyone else?

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

djudd’s picture

FileSize
182.04 KB

Oops, the second attachment didn't go through.

mikeytown2’s picture

are you using a CDN?

djudd’s picture

No, I am using your Parallel module, but this issue was happening before I put that in place too.

mikeytown2’s picture

Can I get a live example page with the broken images?

djudd’s picture

Sure, here is one example where nearly every images is currently broken.

http://www.svherald.com/entertainment

Now, they may not be broken after the next boost cron run as my content updates all around the clock from the Associated Press, but as of right now, the page looks like this.

I appreciate you taking the time to give me your advice and opinions, I know you're a pretty busy guy with all the projects you have going on.

mikeytown2’s picture

The filename changes
http://cdn1.svherald.com/sites/default/files/imagecache/StoryLead/nitf/0... - whats been cached
http://cdn1.svherald.com/sites/default/files/imagecache/StoryLead/nitf/0... - on the live page

How are your images setup?
Source for test: http://www.svherald.com/content/2010/05/12/idol-front-runner-has-faced-b...
Somehow the source filename changes... any idea how this happens?

djudd’s picture

All of the content which seems to be broken is pulled from a feed (FeedAPI with a custom parser) from the Associated Press.

When the story updates, the node is updated. So I suppose what could be happening is that FeedAPI is refreshing the stories in between Boost cache flush times, so yes, I guess I can see where the name of the photo might change and screw Boost up, or at least I think I understand the logic of how it could happen.

I wonder if using Filefield Paths to change the name of the photo upon node creation might help that, since the name of the photo would be set automatically.

I think I'll give that a try and let you know. Thanks for the insight.

mikeytown2’s picture

if you want to be lazy, you can use this patch and generate all presets (if in a filefield).
http://drupal.org/node/374202#comment-2955596

The alt would have the crawler parse the html and pull out all imagecache references and hit them. The reason this is happening is because of the crawler; the html is generated without the imagecache preset being generated. If you didn't delete the jpeg file on node update, I'm guessing you wouldn't encounter this bug.

djudd’s picture

I think I get what you're saying. Boost is crawling before the imagecache preset is actually generated. Is this because no live user has as yet touched that image/page?

So if I further understand correctly, the patch you linked is actually a set of three actions added to imagecache that will allow the preset to be touched upon creation?

So setting up a rule for new content being created that generates all imagecache presets should solve this problem.

Thanks a million mikeytown2. You are an awesome developer and the Drupal community appreciates you.