This topic is locked

Popup not working due to MIME type issues

11/26/2012 2:04:51 PM
PHPRunner Tips and Tricks
F
FunkDaddy author

Suddenly, my popup forms (add/edit/view) stopped working in PHPR 6.2 Build 13816
Upon inspection using Chrome inspector (under console) I noticed that I was receiving the following message via an infinite loop whenever I clicked on "view" icon for a record show in my list pages. The popup would not open and no error messages were displayed on the page other than in the inspector console.
The messages were basically these two:
Resource interpreted as Stylesheet but transferred with MIME type text/html:
then also
Resource interpreted as Script but transferred with MIME type text/html:
Upon investigating and double checking my server's MIME settings and content headers several times I concluded the problem was with the combo.php file which contains several query string variables which are used to call YUI files.
Anyhow, I won't get into the super technical explanation, but if you look at the combo.php file you will see the foreach loop that parses the querystring and then fetches the .js and .css files accordingly... Unfortunately, if you are on a windows server with ISAPI engine then the script in combo.php basically fails because it never calls the result of the getQueryString() function successfully because that function (which is inside of include/phpfunctions.php) relies on the _ENV superglobal and this apparently is not available via ISAPI configurations (from what I was able to gather online).
I was able to solve the issue by modifying the combo.php file by replacig the "getQueryString()" function (which was being called from the "include/phpfunctions.php" file)
I simply added this code immediately after $cCharset line (in the combo.php file...note that I did not touch the "include/phpfunctions.php" file):
=================

function getQueryString_MBR()

{

return $_SERVER['QUERY_STRING'] ? urldecode($_SERVER['QUERY_STRING']) : '';

}
//Then I updated the $queryString to be set to my new function as follows (instead of using the getQuerString() function that was already there)

$queryString = getQueryString_MBR();
=====================
The bottom line is that the built in "getenv" php function was not working when running on the domain which I had configured to use ISAPI (all my domains are hosted in the same Windows 2008 virtual machine). When I tried using the same project on another domain that was running FastCGI configuration it worked without any issue.
I ran phpinfo() on both domains to compare ISAPI vs FastCGI and sure enough the one with ISAPI was not showing any _ENV superglobals. This is what led me to figure out the issue was with calling the getenv function.. .thus I simply replaced it with the $_SERVER['QUERY_STRING'] call instead.
Feel free to post any information here regarding ISAPI and ENV variables... this whole thing seems very odd to me in the first place, but this is what worked for me.
Cheers,

F
FunkDaddy author 3/28/2013

By the way... I just had to do the same thing for a new install on a Windos 2008 server with php 5.3.
At first my own tip didn't work... so be sure to do a hard reload and empty your cache for the changes to take hold (open chrome inspector and right click on refresh page for the option to do this). Once cache picks-up new combo.php changes it fixes the issue.