CentOS 7: Changes To Php.ini

Home » CentOS » CentOS 7: Changes To Php.ini
CentOS 6 Comments

Hi,

I’m hosting a few web apps like OwnCloud, WordPress and Dolibarr on CentOS 7 that require a handful of changes to php.ini. I have to define some custom values for post_max_size, upload_max_filesize, etc.

I don’t know if I’m supposed to edit /etc/php.ini directly or if changes should be put in a configuration file stub in /etc/php.d. For example, I
followed the recommendations of a fellow CentOS user and defined date.timezone by edit /etc/php.d/date.ini like this.

[Date]
; Defines the default timezone used by the date functions
; http://php.net/date.timezone date.timezone = Europe/Paris

Am I supposed to do something similar for other PHP variables?

Cheers,

Niki

Microlinux – Solutions informatiques durables
7, place de l’église – 30730 Montpezat Web : http://www.microlinux.fr Mail : info@microlinux.fr Tél. : 04 66 63 10 32

6 thoughts on - CentOS 7: Changes To Php.ini

  • In the beginning I edited those values in php.ini. Got tired of having to remake the changes in php.ini, whenever php-updates were installed, so eventually began setting the needed values directly in the Owncloud-GUI.

    Dates however are a different thing. I really always want to see and use ISO-dates and times regardless of it’s OC or whatever – so I edit the php.ini in that case.

  • I for one do all changes I need (like timezone, memory, upload size, etc)
    in /etc/php.ini or its equivalent (on FreeBSD it will be
    /usr/local/etc/php.ini). Package managers are smart to not overwrite (or delete when package is uninstalled) configuration files. I’m sure config files in php.d are read after /etc/php.ini so they have “final word” on what some variable will be. Making habit to put things there is good in respect you will check/edit in place that will be overriding other places like /etc/php.ini. As I am one sysadmin in the team, I prefer slight convenience (or indulge my laziness) of doing it /etc/php.ini. So, it basically can be just your own habit.

    Just my $0.02

    Valeri

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

  • When you have different applications with different needs it’s best to either use mod_php specific directives within that virtualhost such as here:

    https://src.fedoraproject.org/rpms/owncloud/blob/master/f/owncloud-defaults.inc

    Or honestly better still to not use mod_php and instead switch to php-fpm with separate application pools which each have their own php settings like this nginx based setup:

    https://src.fedoraproject.org/rpms/owncloud/blob/master/f/owncloud-conf-nginx.conf

    https://src.fedoraproject.org/rpms/owncloud/blob/master/f/owncloud-el7-php-fpm.conf

  • Valeri Galtsev wrote:

    Y’all should note the existence of yum-posttransaction-actions, which allows you to create scripts to be automagically run after a yum update. I, specifically, use it to keep apcupsd from either screaming and screaming, as happens with an extension, by just using sed -i to change
    /etc/apcupsd/appcontrol (which is *not* a configuration file, and so is overwritten) so that SHUTDOWN=/bin/false, rather than /sbin/shutdown

    mark

  • here:
    like

    Would that be true even for really small installs. Like running one server with one, maybe two services relying on php?
    It feels rather over the top.

    I use Apache and php because most good howto’s out there are based on those assumptions.