[FX.php List] Strange encoding problem
bob at patin.com
Thu Sep 8 06:05:10 MDT 2011
OK, so now I know exactly why my web server was encoding the pages differently yesterday:
On Saturday I installed the Web Pub. Engine on their web server; previously, this client was using one of my existing webserver/database server pairs for its web app, but they decided they wanted their own FM Server machine in addition to their web server that they have now.
So I installed the WPE and tied it to their new FM Server machine.
At this point, the web server started encoding these old HTML pages differently, and a lot of characters rendered as broken images (apostrophes, bullets, and a few more).
If I were to take one of these almost 2 million static HTML pages and add a HEAD tag to it for UTF-8, it would work fine; naturally, this isn't a reasonable fix.
So I set their web app back to the old WPE, did an uninstall of the WPE on their web server, and everything returned to the way it was.
So my guess is that the WPE wants to see UTF-8, not old badly-rendered pages generated by a vintage copy of MS Word (which is what this guy used to create these pages).
I suppose I could dig and find the setting that was changed by the WPE, but for now I've told my client they'll have to continue to use a shared FM Server machine as they've done for almost 7 years.
Doubt this will come up for anyone else, but thought I'd post it nevertheless.
Longterm Solutions LLC
bob at longtermsolutions.com
FileMaker 9, 10 & 11 Certified Developer
Member of FileMaker Business Alliance and FileMaker TechNet
Expert FileMaker Consulting
FileMaker Hosting for all versions of FileMaker
On Sep 7, 2011, at 9:34 PM, Bob Patin wrote:
> Found it!
> To explain: when a user selects a couple of parameters (comparing 2 vehicle models), I query the database to find the static HTML page that has a report on it (they're static because that's what my client generates); the final page of the app includes the appropriate static HTML page.
> Because these awful pages are made from MS Word, which has a "create HTML" feature, they're stuffed with awful tags, including an open <html> tag and a couple of HEAD tags; when I added a UTF-8 tag, it fixed the error, but there are almost 2 million of these pages, so no way to fix them all.
> So my question was, why did this suddenly happen? I have 9 web servers here, and some would encode the page properly, some not; by comparing the modules that are enabled in OS X Server, I was able to determine that by having the "header module" OFF, and not encoding for UTF-8, the page rendered properly.
> So that's all it was; somehow the web server had the header module enabled... :)
> Bob Patin
> Longterm Solutions LLC
> P.O. Box 3408
> Brentwood, TN 37024
> bob at longtermsolutions.com
> iChat: bobpatin
> AIM: longterm1954
> Twitter: bobpatin
> Google+: http://www.longtermsolutions.com/plus
> FileMaker 9, 10 & 11 Certified Developer
> Member of FileMaker Business Alliance and FileMaker TechNet
> FileMaker hosting and consulting for all versions of FileMaker
> PHP • Full email services • Free DNS hosting • Colocation • Consulting
> On Sep 7, 2011, at 8:57 PM, Dale Bengston wrote:
>> Bob, to be clear - the files on the server are included in a parent file that talks to a database? So when you pulled the file local, you were bypassing that parent include part?
>> I find it unlikely that OS X Server would suddenly just change its encoding for web services. What else has changed on the server recently?
>> On Sep 7, 2011, at 7:49 PM, Bob Patin wrote:
>>> Here's an interesting thing: I took one of these files, copied it to the desktop, then opened it locally on the browser on the web server; looked fine.
>>> I then took the same file, put it in the website's folder, opened it on the web using the same browser, but accessed it via the site's domain name--encoding problem.
>>> I'm thinking there's something that's messed up in OS X Server that's causing this, but I can't find it... perhaps a module that isn't on any longer perhaps.
>>> Any ideas welcome!
>>> Bob Patin
>>> Longterm Solutions LLC
>>> P.O. Box 3408
>>> Brentwood, TN 37024
>>> bob at longtermsolutions.com
>>> iChat: bobpatin
>>> AIM: longterm1954
>>> Twitter: bobpatin
>>> Google+: http://www.longtermsolutions.com/plus
>>> FileMaker 9, 10 & 11 Certified Developer
>>> Member of FileMaker Business Alliance and FileMaker TechNet
>>> FileMaker hosting and consulting for all versions of FileMaker
>>> PHP • Full email services • Free DNS hosting • Colocation • Consulting
>>> On Sep 7, 2011, at 7:27 PM, Dale Bengston wrote:
>>>> Have you taken a look at the physical files, or loaded them manually in a browser outside of the database call? Just wondering if there's some corruption going on or something.
> FX.php_List mailing list
> FX.php_List at mail.iviking.org
More information about the FX.php_List