php_value in .hiawatha
Martin Lesser
15 July 2009, 19:46
Migrating some sites from apache with mod_php to Hiawatha with php_fcgi I ran into an error and have no idea how to solve it:
The former sites hat .htaccess files which set some php-values, i.e.:
php_value auto_prepend_file "some_file.php"
php_value include_path ".:/some_path/phpinc"
php_value sendmail_from "me@nowhere"
...
Putting the same lines in a .hiawatha file raised 500-error. How could I solve this issue?
TIA, Martin
Hiawatha version: 6.15
Operating System: FreeBSD 7.2
Hugo Leisink
15 July 2009, 20:23
php_value is a Apache specific thing. There is no Hiawatha equivalent. What you can do is use a seperate FastCGI daemon for that website which has it's own php.ini (can be assigned in php-fcgi.conf).
Another thing you can try is by using the PHPRC environment variable. Set it with the 'setenv' configuration option. Google for 'PHPRC' to read more about it.
If that doesn't solve your problem, please let me know. We'll find something else.
Martin Lesser
15 July 2009, 22:50
Hugo: Thanks for your fast reply.
Parts of my problem were solved in the meantime - others are not.
Perhaps it's an chicken/egg problem which I cannot solve at the moment:
Until now (with mod_php) each customer using a simple CMS had individual settings mentioned in my first posting, these variables set i.e. DB-name, paths for templates and so on.
I tried to replace these settings via an individual php.ini and adding
Setenv PHPRC=/path/to/site/php.ini
to the .hiawatha in the main-path of the customer but that resulted in a 500-error:
[line not postable because forum-parser treats it as spam? Annoying...]
So it looks like php does not get the Setenv-command.
The only way to get this one site up and running is to set these variables in the global php.ini but then it's not possible to use it for more than one site.
Starting several php-fcgi's for each site is also not the preferred way.
So at the moment I have no idea how I could solve this.
One OT-request for the next release of hiawatha: It would be very great if a UrlToolkit-Logger could be implemented where one could trace the url-rewriting and is not lost if a rewrite does not work as expected.
Cheers, Martin
Martin Lesser
16 July 2009, 01:36
Addendum:
Switching from FCGI to CGI did it also that's not the final solution.
The problem probably is that starting a fcgi-prog makes it impossible to change paths etc. of this fcgi-process when it gets really invoked. But I did not look through the fcgi-requirements in depth.
Hugo Leisink
16 July 2009, 12:17
Why do you wanna have those settings in your webserver configuration? Those settings are webapplications settings, not webserver settings. Don't you think it's best to have those settings set somewhere in the application? Via an include or something? That would solve your problem and make your application more webserver indepenent (which is always good in my opinion).
About the UrlToolkit logger, you can use the wigwam tool to test toolkit rules. This way you can see if a certain URL is rewrited as expected.
This topic has been closed.