For best compatibility it would be great, if all Nextcloud related PHP configurations could be moved from php.ini (or the related modules ini) into the .htaccess/.user.ini inside Nextcloud directory. So other webservices would be not affected and could use their own settings again.
The default .htaccess already contains PHP settings. Of course it would be great to check for active PHP modules, before setting the related values (e.g. for APCu, OPCache, MySQL, Redis). I guess extension_loaded('name') ? would not work inside .htaccess, right?
Would this be possible and working without problems/risks to add these settings to the end of the default .htaccess?
Thanks in advance and every participation to the github issue would be welcome!
So should work at least with apache+mod_php. Instead of manipulating the .htaccess which comes with nextcloud it could be also done via nextcloud vhost inside <directory> statement. But still, I don’t find a way to check for installed/activated php modules there. Will check, if syntax error arrives in case, or if the php settings are available/set anyway, in case without effect.
_€: One correction about it: “opcache.enable 1” inside vhost produces an nextcloud log error. I thought it was solved by removing the duplicate in php.ini/opcache.ini but it was not/reappearing. Seems this value can/should not be set outside of default php config files: https://support.plesk.com/hc/en-us/articles/115001622189-A-lot-of-errors-in-php-fpm-log-ERROR-Unable-to-set-php-value-opcache-enable-_ But opcache still worked as intended with the correct local settings, which I also tested by copying the dietpi’s opcache.php into the nextcloud folder. And it defaults to “1”/enabled anyway, so can be just left out.
The mysql configuration (given in admin manual) is actually obsolete, as all this defaults already and I am not sure, if those settings are actually used for pdo_mysql php module.
The settings are well active just for the nextcloud folder, which I checked with phpinfo(). This way it would not affect other web services and can be easily plug&played together with nextcloud.
Checking for installed/active php modules seems not to be necessary, as wrong entries are just ignored on my system. No error log or something at all.
So I am still not sure about possible other problems/risks by using this instead of doing the php settings via php.ini/sub conf files globally.
In /var/www/opcache.php and /var/www/nextcloud/opcache.php it shows now the correct adjusted different settings. But scripts from within nextcloud are now cached in both “instances”, lets say they block a certain amount of the 32 MB available cache size outside /nextcloud and also from the 128 MB available inside.
I am not sure how this is handled in that case, if opcache now blocks 32 MB + 128 MB or if inside /nextcloud the global 32 MB are just extended. The latter fits to what I see, as php files from within /nextcloud are visible on both opcache.php pages. Actually both pages show all files, the same free cache size, just different used+available cache size.
As I see this now, >100 MB blocked cache size inside nextcloud folder looks too much for me, the additional cache here seems to be shown always as used. You see there is clarification needed here .
Btw: You can open /nextcloud/opcache.php just, if you did not apply the ht rewrite base in config.php or in case remove it and also comment out the related rewrite entries in .htaccess .
If you want to preserve settings, you can do this directly in your apache-configuration, then it will also survive updates. The problem with .htaccess is that you would need to reliably detect user modifications. Nextcloud itself does some modifications depending on the setup (so it’s not identical for all setups), so it is hard to build in a reliable way. On top of that, if the .htaccess changes, it could break something with your modifications and then you end up with a non-working version. This will be hard to detect, a lot of people would complain and you can’t test such things reliably. It does not only have to work in your case, it has to work in all cases where people modify their .htaccess…
It is painful to do changes manually after each update but it’s reproducible and works.
Yeah .htaccess (and now also the occ .htaccess update command created an .user.ini, never saw that so far) are really not the best places for that, as you stated. And as I stated above it anyway just allows a small amount of settings to be changed, nearly non of the opcache settings, that pop up on admin panel if not adjusted.
Using php.ini of course should be the default way for people to optimize their php settings, after enabling certain modules. This also survives updates etc. But it is only possible to change the values globally there (for all php using web services / sites), which is what I try to bypass for an automated installation script, where you don’t know what else people use the system for, which might break by using the settings.
As /etc/apache2/sites-enabled/nextcloud.conf is so far created manually (if even), it will not be manipulated by nextcloud nor by any other software, upgrade etc. Also it does allow to set the “admin” settings for just one folder, as shown above.
Thus it looks like a perfect solution for me so far, as far as it does really work as intended. I am still not to sure about it, because these php “system” settings are actually made to NOT being set locally and it looks like quite a trick/hack that they are used locally by setting them inside <Directory /var/www/nextcloud/>.
I am just not sure how check that everything is really working fine that way. As shown above at least the opcache size, analysed by the opcache.php script (see above) leave open questions in how the cache is really set and used.
Found it there and on other places that adjusting PHP_INI_SYSTEM values per directory by placing them inside apache <directory> is a common trick. Especially interesting:
PHP_INI_SYSTEM can be configured per-directory by placing it inside a per-directory block in httpd.conf
# Selectively enable APC for wildly popular directories
# apc.enabled is Off in php.ini to reduce memory use
<directory /usr/local/apache2/public_html/forum>
php_flag apc.enabled On
</directory>
This of course does not make any sense inside webserver config:
CLI requests go via /etc/php/7.0/cli/ and bypass the webserver config of course.
Just web requests via /etc/php/7.0/apache2/ respectively /etc/php/7.0/fpm/get the additional/adjusted php values.
Thus cron jobs will still produce the [info] log about missing APCu for CLI.
OPcache warnings are gone, but CLI requests do not get the adjusted values.
So you anyway want to adjust the php ini files to resolve everything correctly.
The MySQL can be left out. They are shown on admin manual, but not as recommendations, just as examples which values exist/could be adjusted. Sometimes I misinterpret, if it says something like: “your settings could look like this” Recommendation about how it could/should look like, or hint, what settings you might see, if you open it the first time?
.
!
.