NOTE: I just remembered there -is- a config-file-scan-dir option at
compile time. However, what about doing away with this and making it
inline in php.ini, the syntax can match mysql, as it uses ini files as
well.
This mainly will help with programatically creating PHP-FPM pool
config files, but could open up to other distro-specific or helpful
things.
This could allow for say, Ubuntu's php5-apc package to not modify
php.ini, but include an apc.ini in /etc/php5/conf.d/ for example
(which it might actually do already. I can't install it without
messing up my box as I compile my own PHP)
Since the scanning code is already there, seems like pretty trivial
changes to the config file parser to add in an include declaration
that behaves the same way (and supports wildcards!) - this would also
allow for multiple locations to be scanned, not just the one defined
at compile time. (I'm thinking of repos who have precompiled the PHP
binary, so there is no flexibility there for users of
repository-created packages)
I'd submit a patch but I don't know C.
Thoughts?
NOTE: I just remembered there -is- a config-file-scan-dir option at
compile time. However, what about doing away with this and making it
inline in php.ini, the syntax can match mysql, as it uses ini files as
well.
I think the --with-config-file-scan-dir is the perfect thing for this,
having includes means having wild dependencies ... and to answer to your
example: Ubuntu would still have to edit a php.ini file to add a new
include, with scan dir: add a file,restart server, done.
johannes
On 23-Dec-2009, at 21:47, Johannes Schlüter johannes@schlueters.de
wrote:
NOTE: I just remembered there -is- a config-file-scan-dir option at
compile time. However, what about doing away with this and making it
inline in php.ini, the syntax can match mysql, as it uses ini files
as
well.I think the --with-config-file-scan-dir is the perfect thing for this,
having includes means having wild dependencies ... and to answer to
your
example: Ubuntu would still have to edit a php.ini file to add a new
include, with scan dir: add a file,restart server, done.johannes
Why not have both? Combining these two methods allow for more
flexibility, though if anything I would vote for wildcards in include
statements to make it more powerful.
i am fine with both too. i just think it's sorely lacking to be able
to do it any other time than at compile time -and- that only provides
you one location.
could be very powerful to allow for any location to be scanned for ini files.
2009/12/23 Tjerk Meesters tjerk.meesters@gmail.com:
NOTE: I just remembered there -is- a config-file-scan-dir option at
compile time. However, what about doing away with this and making it
inline in php.ini, the syntax can match mysql, as it uses ini files as
well.I think the --with-config-file-scan-dir is the perfect thing for this,
having includes means having wild dependencies ... and to answer to your
example: Ubuntu would still have to edit a php.ini file to add a new
include, with scan dir: add a file,restart server, done.johannes
Why not have both? Combining these two methods allow for more flexibility,
though if anything I would vote for wildcards in include statements to make
it more powerful.
2009/12/23 Michael Shadle mike503@gmail.com:
i am fine with both too. i just think it's sorely lacking to be able
to do it any other time than at compile time -and- that only provides
you one location.could be very powerful to allow for any location to be scanned for ini files.
Hello,
I think you can use PHP_INI_SCAN_DIR environment variable which should
work runtime as well.
--
Mikko Koppanen
Hello,
I think you can use PHP_INI_SCAN_DIR environment variable which should
work runtime as well.
still seems a bit archaic. i don''t see any reason why include support
can't be added in php.ini. it will probably wind up becoming more
popular and widely used than the configure option too, or the
environment option...
this requires the environment variable to be set prior to launching
the php-cgi or php-fpm processes. while it can override the static
location done at configure time it still doesn't seem flexible. i'm
thinking of includes and the ability to include them as many times as
you want inside of php.ini :)
Hello,
I think you can use PHP_INI_SCAN_DIR environment variable which should
work runtime as well.still seems a bit archaic. i don''t see any reason why include support
can't be added in php.ini. it will probably wind up becoming more
popular and widely used than the configure option too, or the
environment option...
Please tell me one benefit except "we support include"? I don't see
any. The extra files are still there, they will be loaded too, etc.
Cheers,
Pierre
On Wed, Dec 23, 2009 at 7:20 PM, Michael Shadle mike503@gmail.com
wrote:On Wed, Dec 23, 2009 at 10:13 AM, Mikko Koppanen
mkoppanen@php.net wrote:Hello,
I think you can use PHP_INI_SCAN_DIR environment variable which
should
work runtime as well.still seems a bit archaic. i don''t see any reason why include
support
can't be added in php.ini. it will probably wind up becoming more
popular and widely used than the configure option too, or the
environment option...Please tell me one benefit except "we support include"? I don't see
any. The extra files are still there, they will be loaded too, etc.
The most tempting reason for me would be to have easier control of
what gets loaded between SAPI's, eg load this ini for cli but not for
cgi, etc. Right now this is only possible by compiling each Sapi with
its own search path, which is more cumbersome.
Cheers,
Pierre
2009/12/23 Tjerk Meesters tjerk.meesters@gmail.com:
On Wed, Dec 23, 2009 at 10:13 AM, Mikko Koppanen mkoppanen@php.net
wrote:Hello,
I think you can use PHP_INI_SCAN_DIR environment variable which should
work runtime as well.still seems a bit archaic. i don''t see any reason why include support
can't be added in php.ini. it will probably wind up becoming more
popular and widely used than the configure option too, or the
environment option...Please tell me one benefit except "we support include"? I don't see
any. The extra files are still there, they will be loaded too, etc.The most tempting reason for me would be to have easier control of what gets
loaded between SAPI's, eg load this ini for cli but not for cgi, etc. Right
now this is only possible by compiling each Sapi with its own search path,
which is more cumbersome.Cheers,
Pierre
--
For different SAPIs ...
php-cli.ini, php-isapi.ini, php-cgi-fcgi.ini, etc. is what I use on Windows.
Combined with registry settings for PHP (Prior to PHP5), PHP5 and
PHP6, I can very easily dictate which INI file will be loaded for
which version of PHP and for which SAPI.
Beyond that, I can use [HOST=] for some host specific settings.
All of this is with the standard windows pre-compiled binaries.
--
Richard Quadling
"Standing on the shoulders of some very clever giants!"
EE : http://www.experts-exchange.com/M_248814.html
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
ZOPA : http://uk.zopa.com/member/RQuadling
On 28-Dec-2009, at 17:43, Richard Quadling rquadling@googlemail.com
wrote:
2009/12/23 Tjerk Meesters tjerk.meesters@gmail.com:
On Wed, Dec 23, 2009 at 7:20 PM, Michael Shadle
mike503@gmail.com wrote:On Wed, Dec 23, 2009 at 10:13 AM, Mikko Koppanen
mkoppanen@php.net
wrote:Hello,
I think you can use PHP_INI_SCAN_DIR environment variable which
should
work runtime as well.still seems a bit archaic. i don''t see any reason why include
support
can't be added in php.ini. it will probably wind up becoming more
popular and widely used than the configure option too, or the
environment option...Please tell me one benefit except "we support include"? I don't see
any. The extra files are still there, they will be loaded too, etc.The most tempting reason for me would be to have easier control of
what gets
loaded between SAPI's, eg load this ini for cli but not for cgi,
etc. Right
now this is only possible by compiling each Sapi with its own
search path,
which is more cumbersome.Cheers,
Pierre
--
For different SAPIs ...
php-cli.ini, php-isapi.ini, php-cgi-fcgi.ini, etc. is what I use on
Windows.Combined with registry settings for PHP (Prior to PHP5), PHP5 and
PHP6, I can very easily dictate which INI file will be loaded for
which version of PHP and for which SAPI.Beyond that, I can use [HOST=] for some host specific settings.
All of this is with the standard windows pre-compiled binaries.
I'm not sure what registry settings do, haven't seen that in Linux yet.
The additional use case would be to have all common configuration
settings into one ini file that would get included by the different
SAPI ini files.
--
Richard Quadling
"Standing on the shoulders of some very clever giants!"
EE : http://www.experts-exchange.com/M_248814.html
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
ZOPA : http://uk.zopa.com/member/RQuadling
Please tell me one benefit except "we support include"? I don't see
any. The extra files are still there, they will be loaded too, etc.
Instead of a -single location- being defined at compile time or
execution of PHP time, this allows it N number of include directories.
It opens up multiple usage models. for example, cpanel puts a
per-account apache configuration inside of /home/$account/ - it just
seems like a more flexible solution instead of static configure
location. and environment variable override for a web-driven thing
like php-cgi or php fpm has to be done before it is launched...
Please tell me one benefit except "we support include"? I don't see
any. The extra files are still there, they will be loaded too, etc.Instead of a -single location- being defined at compile time or
execution of PHP time, this allows it N number of include directories.
So what you need is multiple ini dirs, not actually include. I think
there is a patch somewhere for this feature, or it may even be already
in. If not, that could be something useful.
Cheers,
Pierre
So what you need is multiple ini dirs, not actually include. I think
there is a patch somewhere for this feature, or it may even be already
in. If not, that could be something useful.
To me, it solves all of the usage models currently provided and
allows for infinite/future growth and usage models.
So what you need is multiple ini dirs, not actually include. I think
there is a patch somewhere for this feature, or it may even be already
in. If not, that could be something useful.
Hi,
I think this is the feature (in trunk currently):
http://svn.php.net/viewvc?view=revision&revision=282878
--
Mikko Koppanen
Hi,
I think this is the feature (in trunk currently):
This is not the same, this is just an additional way to still have
static dirs defined only at compile time, or maybe environment
variable.
Am I not explaining this properly enough? It should be supported from
the configuration file itself. This feature in trunk doesn't add
anything new for me.
Hi,
I think this is the feature (in trunk currently):
This is not the same, this is just an additional way to still have
static dirs defined only at compile time, or maybe environment
variable.Am I not explaining this properly enough? It should be supported from
the configuration file itself. This feature in trunk doesn't add
anything new for me.
Sorry for reposting this; my last reply didn't make it onto the list
due to my lovely iPod =X
The most tempting reason for me to support include support (or better
yet, include glob support) would be to have better control of what
gets loaded for each SAPI; for instance, load module A for CLI, load
module A+B for CGI, but only only module B for fpm, etc.
This would otherwise only be possible by compiling each binary
separately and running ./configure && make && make install for each.