My hosting company uses Apache servers.
« Last edit by SteveS on Tue May 24, 2016 9:23 pm. »
Page: 1
Author | Post |
---|---|
#1 Tue May 24, 2016 9:19 pm
|
|
Member
Registered: Nov 2010
Posts: 71
|
I am accessing a single instance of the Floatbox package (v6.04) on many of my web sites (all on the same physical server). The release notes for version 7 state "a server needs to send CORS headers with the files" and some hosting companies strip out any CORS headers from font files, thereby preventing most browsers from accessing them. Is there a way (other than installing the new version of Floatbox) to determine if my hosting company strips out CORS headers? Possibly a PHP or JavaScript file. Having a single instance of Floatbox has been a real time saver when a new version is released.
My hosting company uses Apache servers. « Last edit by SteveS on Tue May 24, 2016 9:23 pm. » |
#2 Wed May 25, 2016 12:31 am
|
|
Administrator
Registered: Aug 2008
Posts: 3382
|
I agree that using a single instance of Floatbox to serve multiple sites is the way to go.
My first tests of doing this with version 7.1.1 failed and I came to the conclusion that the floatboxjs.com host (1and1.com) was stripping the CORS headers that I assigned via .htaccess to the resources/fbicon font files. The graphical controls on the displayed floatboxes were missing their font graphics (such as the X on the close button), and inspection of the network fetches for the files using multiple browsers' developer consoles showed that the assigned headers weren't present. After releasing 7.1.1, with the readme.txt file indicating that at least some hosts appeared to block cross-server font file delivery, I tried again and was successful at sharing the Floatbox package, including the font files. I don't know what accounts for the initial failure, but I am no longer confident in the claim that the host was stripping the headers. Perhaps there was a downstream caching gateway somewhere in the network route which was delivering the old header-less font files. User idiocy is another possibility. Probably the easiest way to test it is to try it (with the new version). Don't worry about pre-determining a hosts behaviour with font files as I suspect there was no problem and my initial reports about this were misinformation. I would suggest that the CORS .htaccess stuff be in place before your first test, just in case my suspicion about a downstream caching device is correct. I would also suggest you wait a couple of days for the imminent release of 7.2.0 which contains some worthwhile bug fixes and enhancements. (7.1.1 was really the "dot zero" release of version 7; the 1.1 numbering being an artifact of versioning during the internal development process.) |
#3 Wed May 25, 2016 12:34 am
|
|
Administrator
Registered: Aug 2008
Posts: 3382
|
Here is the updated section on this topic from the readme.txt file in version 7.2.0, which really is only a day or so away from release.
|
#4 Wed May 25, 2016 12:47 am
|
|
Member
Registered: Nov 2010
Posts: 71
|
Thanks - I just completed a test and a central instance with version 7 seems to be working fine. For the test I did upload the .htaccess file that is in the resources folder. The left and right navigation arrows when displaying photos work much better with version 7!
|
Page: 1