Mawhorter.net Forums

Issue 1 - Fonts are generally replacing fine however on some refreshes certain elements won't show the FLIR font (Lithograph). The main navigation, all heading tags, and the left column links should all be Lithograph. Sometimes half of the nav will be Lithograph, other half non-FLIR font.

I can't get this to happen.  I refreshed many times with my cache enabled/disabled.  Every time it downloaded the image. 

Issue 2 - occasionally when I click a link in the site I get a Firefox pop up saying I've chosen to download an "application octet-stream".  Similar in IE.

Hmm... you say it happens in IE?  One other person complained of a similar problem but I chalked it up to a bug with a FF extension.  I had a similar problem with more than FLIR sites until I disabled some extensions.  There is no reason that Facelift should be causing this, though... it doesn't do anything to the actual links and just puts an image in between the <a></a>.

I'm curious, what exactly do you get in IE?

Hmm. I take some of that back. I'm still getting the pop up in both IE6 and FF3 PC occasionally.

Also in FF3 PC, I'm sometimes getting the issue with fonts not transforming for half of the nav/list items, *some* of the time. When I refresh or bounce around and come back to the same page they'll all transform.

Yeah, I have a folder in the root containing FLIR. Same with WordPress, then when it launches I'll hide the wp directory using htaccess.

So, I have
root/flir/ flir files
root/wp/ wordpress files

I finally got back to this. Backtracked, installed the WP plugin for FLIR instead of doing it manually in case I was messing things up :-)

The pop up still appears from time to time in FF3 (PC) and IE6.

I'm still getting those caching headers, but with a 1984 expiry instead of 1981. I removed the line with pingback_url from my header.php and WP appears to insert the pingback line in the header no matter what. No idea where that date is coming from... WP post dates are correct so the system seems to know the time.

If all else fails, is there a way to disable the plugin by browser? Something I could do in a browser-sniff or conditional comment for IE?

Thanks for all your help. Much appreciated!

I've had these same issues in all browsers on all systems.
Not only with my FLIR installs but on the FLIR site itself.
http://facelift.mawhorter.net/

Your site's header sometimes doesn't replace correctly on my Mac with Safari and FF.

But my sites are having these crazy issues with both Mac and PC on IE7, FF, and Safari.

What was the difference?
I thought for a while and I came to a conclusion.
The servers.

I think it is a conflict with the resource URI for each FLIR image.
It is the long GET request attached to the generate.php resource.
It may have correct headers within the php, but that doesn't mean a browser will cache it, because Apache's default is to not cache requested php files.
So some of us might or might not have control over this setting within Apache's config.
Although PHP is supposed to override this, us PHP developers are at the mercy of PHP, Browsers, and Apache.

That being said, I think trying to use a more standard approach might be the answer.
I changed the condition in the generate.php file from calling the output function to simply a php header redirect to the cache file itself.

This changed some things, by the fact that some images were being cached, and others were not.
Sometimes the images cached were suddenly not cached.
So I continued thinking...

I think a server side redirect is a step in the right direction, but isn't enough here because an Apache server still may not cache the image if it is redirected to from a server side page (again based on Apache's cache settings combined with Browser behavior)

So I stopped there, I think somehow the javascript should do the cache redirect before ever getting to the generate.php.

I am not a javascript master, so I am not even sure if this can be done.
I'm not sure if it is possible to keep the javascript down to a minimum of 1 request, while still checking for the cache file. Maybe this doesn't matter as long as a Site's administrator makes sure he/she caches all the images before putting the site live. So he/she might go through multiple javascript requests to get an image saved, but the users of the site will still only make one request for the image already cached, and the administrator can rest assured that FLIR is simply calling the cached images. Browsers should cache fine, and users should see a speed increase on refresh.

There might also be a more simple solution to use mod_rewrite to fool the browser (with Apache) that it is looking for an image rather than a php file. Maybe then the browser will cache fine, but I haven't tried this yet...

Thoughts?

EDIT:
I take back what I said about changing to a server side redirect not caching correctly.
I checked, and checked again, and after a while I noticed that all my images were being cached by the browser, it just took a couple of tries. This was because changing to a server redirect created a new bug. Sometimes images are simply not found. This is remedied by a browser refresh, and it doesn't happen again until I clear the browser's cache.
What I've noticed is that this new 'not found' error is in place of all the weird things that were happening previously with the images not being rendered correctly, and never being cached by the browser.

Last edited by jimisaacs (2009-02-07 20:46:39)