Hi,
Only direct editing is allowed for mod_php, cgi and cli in Webmin > Tools > PHP Configuration page,
please add support for PHP FPM ini files in next releases.
Regards
mod_php breaks all other execution modes. You should not have installed it.
I’m pretty sure we do allow editing configs for PHP-FPM, as well…looks like it’s in Services->PHP-FPM Configuration. I don’t know why it’s in a different place (though it does allow more config options than the other execution modes, as each domain gets its own PHP with PHP-FPM, so maybe that’s why).
You will note there is only one option on mine because only one version of PHP is installed. The Global page is reached by clicking the gear and list all options, not options available on what is actually installed. There’s a big difference between the two pages.
If you have mod_php listed on this page, you should uninstall it.
What I directed you to is not global PHP-FPM configuration. It is for the currently selected virtual server. Note under the title it’ll say something like /etc/php-fpm.d/161703721891639.conf. Each domain has its own FPM configuration.
That was not always so, but it should be now, at least with recent systems and recently created virtual servers.
What the OP is saying here is
using webmin->tools->php configuration he can not see all php ini files
I have a staging server running wmin/vmin gpl (this is where I test everything before release) and this server does list all php.ini files (even the cli ones)
my production server is running wmin/vmin pro which does not show all php.ini filess
staging
not that it bothers me in production it just works (nearly but that’s another story) but as a php coder access to the global ini files is useful and luckily on my staging server it works
I am a php developer and develop using apache in fpm mode, this works most of the time
my development cycle is dev machine → real world testing server → end user
I have had, on occasions the following :
dev machine → code working
real world testing → code working
end user → code fails
the error was the end users system was using mod_php as the execution mode for php, which his hosting supplier could/would not change. In the end I installed mod_php on both the dev server & the real world testing server and wrote around the issue. since then I have a domain setup to work with mod_php on the real world testing server to test out my code works in this execution mode.The real world testing server is managed by vmin and has been setup like this for quite some time with no detriment to vmin or other domains on the server. Net result is if you know what your doing there is no need to remove mod_php but remember don’t use it where it’s not required
Fun Fact: mod_php breaks just about everything it touches in Virtualmin. It is, to my knowledge, the number one cause of basic issues and has been for a long time.
That is why @Joe has constantly preached to never install it and get rid of it if you have. It simply breaks far more than it fixes.