# Proposal: allow for includes in php.ini - Thread: https://externals.io/message/46502 - Original archive: https://news-web.php.net/php.internals/46502 - Started by Michael Shadle on 2009-12-23T12:40:17+00:00 - Messages: 16 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #46502 — Michael Shadle — 2009-12-23T12:40:17+00:00 URL: https://externals.io/message/46502#46502 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? --- ## #46503 — johannes@schlueters.de — 2009-12-23T13:47:04+00:00 URL: https://externals.io/message/46502#46503 · In reply to: #46502 > 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 --- ## #46504 — Tjerk Meesters — 2009-12-23T14:21:16+00:00 URL: https://externals.io/message/46502#46504 · In reply to: #46503 On 23-Dec-2009, at 21:47, Johannes Schlüter wrote: > > > […] > > 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. --- ## #46510 — Michael Shadle — 2009-12-23T18:08:43+00:00 URL: https://externals.io/message/46502#46510 · In reply to: #46504 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 : > > > > […] > 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. --- ## #46511 — Mikko Koppanen — 2009-12-23T18:13:17+00:00 URL: https://externals.io/message/46502#46511 · In reply to: #46510 2009/12/23 Michael Shadle : > 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 --- ## #46512 — Michael Shadle — 2009-12-23T18:20:06+00:00 URL: https://externals.io/message/46502#46512 · In reply to: #46511 > 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 :) --- ## #46513 — Pierre Joye — 2009-12-23T18:47:45+00:00 URL: https://externals.io/message/46502#46513 · In reply to: #46512 > > > > […] > > 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 http://blog.thepimp.net | http://www.libgd.org --- ## #46514 — Tjerk Meesters — 2009-12-23T19:08:31+00:00 URL: https://externals.io/message/46502#46514 · In reply to: #46513 > On Wed, Dec 23, 2009 at 7:20 PM, Michael Shadle > wrote: > > […] > > 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 > > http://blog.thepimp.net | http://www.libgd.org --- ## #46515 — Michael Shadle — 2009-12-23T21:25:42+00:00 URL: https://externals.io/message/46502#46515 · In reply to: #46513 > 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... --- ## #46516 — Pierre Joye — 2009-12-23T22:23:49+00:00 URL: https://externals.io/message/46502#46516 · In reply to: #46515 > > > > […] > > 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 http://blog.thepimp.net | http://www.libgd.org --- ## #46518 — Michael Shadle — 2009-12-24T00:55:24+00:00 URL: https://externals.io/message/46502#46518 · In reply to: #46516 > 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. --- ## #46519 — Mikko Koppanen — 2009-12-24T01:12:53+00:00 URL: https://externals.io/message/46502#46519 · In reply to: #46516 > 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 --- ## #46520 — Michael Shadle — 2009-12-24T01:28:39+00:00 URL: https://externals.io/message/46502#46520 · In reply to: #46519 > Hi, > > I think this is the feature (in trunk currently): > > http://svn.php.net/viewvc?view=revision&revision=28287 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. --- ## #46521 — Tjerk Anne Meesters — 2009-12-24T03:07:50+00:00 URL: https://externals.io/message/46502#46521 · In reply to: #46520 > > > […] > > 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. --- ## #46540 — Richard Quadling — 2009-12-28T09:43:45+00:00 URL: https://externals.io/message/46502#46540 · In reply to: #46514 2009/12/23 Tjerk Meesters : > > > > […] > 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. > > […] > > -- > > > > 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 --- ## #46555 — Tjerk Meesters — 2009-12-28T15:30:49+00:00 URL: https://externals.io/message/46502#46555 · In reply to: #46540 On 28-Dec-2009, at 17:43, Richard Quadling wrote: > 2009/12/23 Tjerk Meesters : > > […] > > 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