Windows Server 2008r2
Apache 2.4.4 in 64-bit
PHP 5.4.13 as 32 bit
SM v 1.4.22
When using the method of loadmodule to load PHP 64bit as a DLL, things work fine.
But as noted above, we are trying to run PHP 32bit. The only way to do that is by using loadmodule mod_fcgid.so in apache 64bit for a 32 bit php to work. Everything else we use (group office for example) works perfectly when we do so. But SquirrelMail develops a corrupted URI for all of the top menu links (Compose, Options, etc). Instead of showing the https://ourdomain.com/mail/src/... it drops the entire URL and instead makes those links appear as c:\mail\src...
It seems to begin at base_uri in the functions\page_header.php file but I can't seem to trace that back further. Short of me hard coding our website URL into the files, I can't get our webmail to work this way. But I have to use 32 bit PHP to use ioncube loaders for another package.
That's what $config_location_base is for in the config.php file. You should be able to override the base URI with that. See also conf.pl configuration tool, ==> 4. General Options ==> 15. Location base
If you want to help debug the auto-detect code, due to the obscure setup you're using, we'd need you to do that work for us - patches are welcome.
Thanks
Obscure setup? It's the newest versions of everything. I would gladly use the 64 bit PHP compile but ioncube loaders will not run under 64 bit php compiles.
Is there somewhere with a detailed listing of all the config.php values? I had no idea that config_location_base was for entering the base URL of the site. I've been using SM for 5 years and never had to set it, it just worked.
So I waited until this late hour (12am) to try this approach of setting the location base variable. Sadly, it hasn't made any difference at all. The top menu links still end up changing into c:\mail\src... references when SM runs with PHP loaded through FCGID. I even did a total reboot of the server just to be sure all config files were being forced to be re-read. Running the configtest.php file also shows that SM says it sees https://ourdomain.com is the base path it would be using. But clearly it is not doing that, and just completely ignores the setting in the configuration.
Somehow base_uri is being grabbed from something else, somewhere else.Do you have any other suggestions as to how I can affect this variable to force the correct url path?