Best strategy for handling custom php.ini files?

[b00gizm]

trafficstars

Is there a way to import a custom php.ini file instead of the default one?

I found a more or less decent workaround for my virtual hosts, by providing all custom settings as FastCGI params, but that does not apply to the CLI.

I thought about an additional *.ini file to parse the missing settings from, but this seems to me like a dirty hack.

So what is the "official way" to handle custom php.ini settings?

[mattheath]

@b00giZm Currently there is no official way to set a custom .ini file unfortunately, though I would welcome suggestions. The problem stems from PHP only allowing a single php.ini file (or a set) to be parsed for a specific version of PHP, so per project settings are not possible.

The PHP project manifest then allows a version of PHP to be defined per project, which then includes the appropriate versions and sets up the services. Puppet only allows a resource to be defined once, so this is done by moving the resource definition to the php version manifest files and including one of these each time (we can include a class multiple times). Unfortunately, this then means settings can't be defined on a project basis.

So, tl;dr is that we could change the module to allow a custom php ini file as long as the PHP version was defined at a higher scope than a project and only defined once, but defining on a per project basis precludes this. I'm not sure if there is some crazy puppetry which could be done to get around the problem!

[b00gizm]

@mattheath I wouldn't say that a per-project php.ini is necessary for now. It would be sufficient to have control over the php.ini for a specific PHP version. It's not a totally satisfying solution, but that's due to PHP's own limitations concerning the php.ini. But yeah, at least it's something ;)

[mattheath]

Yeah PHP is never going to allow per project .ini files, what I meant was that allowing a custom .ini file will mean PHP will have to be declared at a higher level - eg. site.pp or in a custom class within your boxen. With the current module layout it won't be possible to use the PHP project class at all.

[b00gizm]

That's what I'm talking about :)

Declaring the php.ini at a higher level would be sufficient. What about:

define php::version(
  $ensure    = 'installed',
  $version   = $name,
  $php_ini   = undef
) {
 ...
}

You could still use the shorthand include php::version { '5.4.10' }, but also add the path to a custom php.ini.

[b00gizm]

Any progress on that? :)

[mattheath]

Sorry, I've not had a chance to look - pull requests welcome! ;)

[EugenMayer]

i worked on that and implemented it here https://github.com/EugenMayer/puppet-php/commit/3ed20dae3576f78b051904352e6004de81efb29d .. but still that wont help, as i stumbled uppon.

There is no way to deploy your own php::version {'own 5.3.23': phpini_template=> "...."} since you would get a dublicate error.

In addition, php::version is wrapped by php_XXXX classes and you need to proxy pass those values. Currently, iam not sure which approach to take, but for now, this holds for nearly all boxes recipes ... they are all very limited and bascially build to be forked and replicated

[nomasprime]

A temporary fix, for me at least, would be to stop this module overwriting php.ini every time boxen is run. Does anybody know how to do this?

[webflo]

Put your own php.ini in /opt/boxen/config/php/[version]/conf.d all ini files in conf.d are automatically included and override previous defined config parameter. You don´t need a complete php.ini file, just override the parameters you need.

[nomasprime]

@webflo I was thinking of using puppet to override the file with my own but didn't realise you could do this. Cleaner solution, thanks.

[clempat]

For the override solution using an personalised template:

$mainVersion = '5.4.29'
File <| title == "${php::config::configdir}/${mainVersion}/php.ini" |> {
        content => template('base/php.ini.erb')
}

with module base and file php.ini.erb