php-fpm.conf for server hostname

Thanks. Yes I will consider it. Please note that I have not yet changed to php-fpm on the servers that is holding my customers. Still doing testing on server without customers. It would be great to not having to think about php_flag when doing the migration to php-fpm, yes. :)
 
Enabling and use user.ini for the things you can't do with htaccess in PHP-FPM, her working, also the user can decide themselves to use the handler in htacces, while static total none php html then is less load en somewhat faster wen not using this in htaccess and httpd for that userdomain( used to be?)

This in htaccess if the handler is needed then
<FilesMatch "\.(inc|php||html|phtml|phps|php56)$">
AddHandler "proxy:unix:/usr/local/php56/sockets/hereusername.sock|fcgi://localhost" .inc .php .html .phtml .php5
</FilesMatch>

I did a quick lookup for the user.ini but you can find more on the web about is
https://stackoverflow.com/questions/35265082/equivalent-of-php-value-under-apache-php-fpm
So you can create .user.ini files analogue to .htaccess, but in ini style format.

So normally you have to inform users about that to have ready a working (htaccess and user.ini) wen updating/changing to php-fpm , for the mosts things it could be already done and testes before ( not for the handler if needed per user on htaccess base ofcourse mayby with a if<>then rule ;) )

Somewhat the same htaccess style user informing used to do with updating to apache 2.2. to 2.4. if 2.2 then and so on in htaccess

Here the da setting i believe
per-User php.ini settings in php-fpm
https://help.directadmin.com/item.php?id=636
per-path php settings, controllable by the User
https://help.directadmin.com/item.php?id=682
Per-Domain php.ini settings - start point
https://help.directadmin.com/item.php?id=672
The last one say:
php-fpm
php-fpm is handy for multiple instances of php, allowing the User to change php version from within their User Level area. php-fpm does not support .htaccess changes as php-fpm is it's own stand-alone php server, but you can use

php-fpmXX.conf custom settings
php [PATH] or [HOST] sections
User controlled .user.ini
 
Last edited:
[cut]
I think it's a very good option to have that module enabled. You recently migrated from mod_php to php-fpm, so that module is definitely much more compatible for you than having it off (before all users were able to use .htaccess to modify php, now none of your users are able to)...

After looking more at htscanner, I don't think I will enable it because it has not been updated since 2012 https://pecl.php.net/package/htscanner and because of potential compability problems with new php releases, like this bug that seem to affect both php 7.0.x and 7.1.x (read all the comments): https://bugs.php.net/bug.php?id=72269

Also it is not really needed when I can offer a per user .ini file instead.
 
Yes you can ;)

But this means (YOUR) Users must make some changes before updating to phpfpm in such cases ( and to inform them), i strugled at the beginning of switching phpfm to with this and the adhandler. ;)

Same as some htaccess rules are not fully compatible when updating apache 2.2. to 2.4.


But ( bij mopperen) if they want php 7x working well you can say "yes i can" if you yourself takes care of this... ;)

with htscanner it is guessing if with next future updates still 100% working and/or someone takes care of patching

Still you as admin should though better take care of the max/min settings and wich are allowed to change ins shared hosting
 
Last edited:
I am now only left with one question I have not found the answer for: When using a secondary level file based cache with "opcache.file_cache=/home/USER/.opcache" - is it needed to delete all the files caches in /home/USER/.opcache directories after each time I upgrade to a new PHP version?

If so, even harder it seems, how can I create a command to delete all the contents in ALL the .opcache directories? Because they are spread across each user wich all have their own /.opcache directory in /home/USER - I have spent several hours searching for a solution, but not found one yet.
 
Back
Top