I have a Debian Squeeze LAMP setup running ISP config. I need to set the date.timezone in the php.ini but it doesn't seem to be reading correctly.
The date.timezone setting is NOT commented out and shows as follows:
date.timezone = "Europe/London"
I had been trying to set this in /etc/php5/apache/php.ini . After inspecting phpinfo() I noticed the loaded configuration file was /etc/php5/cgi/php.ini. So I changed the website settings in ISP config from 'Fast-CGI' to 'Mod-PHP' and the loaded configuration file is now showoing correctly as /etc/php5/apache/php.ini.
Despite resolving the above issue, the phpinfo() is still showing date.timezne (both Local value and Master value) as 'no value'.
can anybody guide me as to what the next step may be?
To use a custom php.ini file with SuPHP for a website, you can define the path to the php.ini file in a .htaccess file or in the apache vhost like this:
suPHP_ConfigPath /home/websites/domain.tld/
Then add a php.ini file in the directory /home/websites/domain.tld/ which may be a copy of the global php.ini were you just changed a few settings or an empty file were you add only the settings that shall be overridden in the global PHP configuration.
If you use ISPConfig 2 or 3, you can add the suPHP_ConfigPath setting also in the apache directives field of the website in ISPConfig.
Source: http://www.faqforge.com/linux/controlpanels/ispconfig2/how-to-use-a-custom-php-ini-with-suphp/
I think it will gonna help you with your php.ini modifications.
Hope it helps
Related
When I pull up phpinfo() from my webroot it details local and master php config settings. I'm familiar with the principal -- master settings are handled in the main php.ini file and can be overridden in site directories with php.ini files, ini_set() calls, or .htaccess files (depending on how the server is configured).
For a few settings I'm seeing local values that differ from the master settings, and for the life of me, can't locate where they are coming from. The loaded/parsed php.ini section of phpinfo() doesn't shed any light, and I've grep'd the heck out of the server trying to find where specific settings are found in files, without success.
Is there any way to locate the source of a setting?
If you've already checked "loaded ini files" section, there are a few more places where the settings can be defined:
if you're running Apache module, check for php_value in its config files
check for php_value in .htaccess
if you're using fastcgi (with nginx, apache or anything else), extra parameters can be specified in the command line (although who would do this?)
there are also default PHP setting
ini_set directive in the code above or in auto-prepended file defined in auto_prepend_file directive
this page http://php.net/manual/en/configuration.changes.modes.php also mentions something about Windows registry and .user.ini (oh gosh, never thought about this!)
I am working on Zend-Framework 1.12 and had to make an https request from the application. I did it by the following way:
$client = new Zend_Http_Client($url);
$client->setAdapter($adaptor);
$client->setConfig(array('keepalive' => true));
$reCaptchaData = json_encode(array());
$client->setRawData($reCaptchaData, 'application/json');
$response = $client->request('POST');
I was getting errors like:
Error in cURL request: SSL certificate problem: unable to get local issuer certificate
Found that I had to add the CA certificates, I downloaded one and added its path to my php.ini.
curl.cainfo="path"
openssl.cafile="path"
It works fine.
But can't I add this to my application.ini? When I try it there it doesn't work.
Does application.ini work as an extension of php.ini?
But can't load modules or certificates, because that this done by Apache on a restart? Apache reads the php.ini on a restart and loads everything (I have the path for my php.ini in httpd.conf)?
According to PHP's manual (http://php.net/manual/en/openssl.configuration.php), openssl.cafile is PHP_INI_PERDIR changeable.
That means, if you read http://php.net/manual/en/configuration.changes.modes.php, that you cannot change it at a script level:
PHP_INI_PERDIR Entry can be set in php.ini, .htaccess, httpd.conf or .user.ini (since PHP 5.3)
So, no, you won't be able to set those 2 settings in Zend's application.ini, but you could do it in a .htaccess file via:
php_value curl.cainfo "path"
php_value openssl.cafile "path"
Keep in mind this will only work if PHP is loaded as an Apache module.
If you use PHP-FPM, you'll need to create a specific pool and alter the values there. It's a bit more complicated in this case, and only doable if you have access to the server's config.
application.ini is not an extension of php.ini as it's got its own syntax, like the phpSettings. prefix.
What you could also look for is .user.ini as documented here: http://php.net/manual/en/configuration.file.per-user.php
In order for this to work, you'll need to set a value for user_ini.filename in php.ini, and of course an additional user ini file (you can't use application.ini as a .user.ini file).
I am trying to use PHP's built-in function get_browser(). I followed the instructions in this useful post, but I'm still getting the error
browscap ini directive not set.
I downloaded the php_browscap.ini file and moved it into the same directory as my .htaccess file, so that its location is home/hostname/subdomain/php_browscap.ini Since I do not have access to my php.ini file, I am trying to edit the browscap property using .htaccess. This is what I entered:
php_value browscap home/hostname/subdomain/php_browscap.ini
I don't know if it matters, but below that there's some Rewrite Engine code.
As forementioned, I am still getting the error above. What did I do wrong?
Thanks.
The browscap PHP value has a changeable mode of PHP_INI_SYSTEM meaning it can only be set in php.ini or httpd.conf (not .htaccess).
Do a phpinfo() to understand your PHP runtime config. If your system is configure as "CGI/FastCGI" then it is probably running suPHP as the PHP initiator. In this case you can specify your own php.ini file. By default suPHP looks in the script directory but you can override this by the following directive in your .htaccess file:
suPHP_ConfigPath (expects a path name)
This option tells mod_suphp which path to pass on to the PHP-interpreter (by setting the PHPRC environment variable). Do NOT refer to a file but to the directory the file resists in.
E.g.: If you want to use "/path/to/server/config/php.ini", use "suPHP_Config/path/to/server/config".
If you don't use this option, PHP will use its compiled in default path.
Also you must use a properly formed path in your browsercap directive e.g.
browscap="/home/hostname/subdomain/php_browscap.ini"
(Note the leading /)
Addendum
I've just check and the Dreamhost shared hosting plan uses suEXEC. With suEXEC you can normally override the php.ini patch by copying the system php.ini (phpinfo() tells you where to find this) into a private directory, say _private as well as the browsercap.ini then adding
SetEnv PHPRC /home/hostname/_private
to your .htaccess file. If this doesn't work then the issue is specific to Dreamhost's suEXEC config and you need to ask this Q on http://discussion.dreamhost.com/
There are two potential problems here.
Perhaps your host does not allow you to override ini settings in the .htaccess file.
Maybe browscap does not like the path you have provided. Try:
php_value browscap /home/hostname/subdomain/php_browscap.ini
And ensure that permissions on that file allow the web user to read it.
If you are on a shared hosting and do not have access to the system php.ini then you can use the following standalone replacement of php's native "get_browser()" implementation.
https://github.com/garetjax/phpbrowscap
PHP configuration can be made in a number of different places:
php.ini
httpd.conf
.htaccess
within a php script via ini_set()
any more?
Some configuration settings can only be set in certain places and there's certain Apache and PHP settings that would prevent you from doing any PHP config changes in .htaccess or with your PHP script. But assuming that a given PHP setting can be set in all of the above places, in what order is this configuration read? In other words what overrides what? (I'm assuming that ini_set() overrides any of the previous settings).
There's compile-time settings before php.ini. The rest of the stages aren't really "configuration". They're more of a way to override settings established in a previous stage. PHP will quite happily run without any other config directives in php.ini/http.conf/.htaccess. php.ini does list (almost?) all the configuration settings available, but that's just a courtesy so you don't have to dig around in the docs to find the one setting you do want to override.
You named them in the correct order.
I don't recommend setting configuration in any other place than a php.ini though.
There are also per-directory php.ini configurations and I don't know which comes first, .htaccess or the directory php.ini but I would guess the .htaccess first and php.ini after.
Apache loads PHP, so Apache's config is read first. .htaccess is also handled by the webserver, so I'm guessing that will be second. Thirdly PHP is loaded. It checks for PHP.ini's in several locations. Also see here. Finally the ini_set is checked runtime.
First, You can use a user.ini file.
I think PHP will read it from the bigger to the smaller, I mean from httpd.conf -> php.ini (and then user.ini if set) -> .htacess -> ini_set()
I have a custom php.ini file I created in my public_html directory. It works as I have checked the settings set are correct using phpinfo().
But the strange problem is the php.ini settings do not seem to apply to all sub_folders in the public_html directory?
Any ideas perhaps theres a setting needed in php.ini to apply to all subdirectories in public_html?
I found the answer myself you have to add the line into .htaccess file so it uses the custom php.ini file you created in public_html instead of having to copy php.ini file in every subdirectory you create.
Add this to .htaccess does the trick obviously replacing username
SetEnv PHPRC /home/USERNAME/public_html/php.ini
Not really a solution, but you can disable overriding the display_error setting by using php_admin_flag in your sites configuration. If it still happens then, you have set an error handler which misbehaves.