increase memory_limit in /etc/php/XXX/fpm/pool.d/wordpress.conf

[dankerthrone]

Not sure whether to file this as a bug or a feature or even if this isn't an upstream issue but here goes:

I don't think the 64M memory limit set in /etc/php/XXX/fpm/pool.d/wordpress.conf is realistic anymore. I've spent the last few days trying to figure why my modestly sized WP instance kept crashing a couple of pages on me when all I did was do some responsive block editing - nothing fancy, really. Turns out, the pages still display fine but Gutenberg + third party theme + CSS helper plugins need some space to allow me to edit stuff. I increased memory_limit in wp.conf and in php.ini but the real culprit was kind of hidden away.

I managed to find it after a bit of research and tinkering, but in the spirit of Yunohost democratizing web gardening/publishing I think it's better to increase memory_limit so that other folks do not encounter the same problem.

[tio-trom]

Yes agree and I opened a discussion about this 3 years ago... #189

I manage around 15 WP websites and every time YNH pushes an update it is a massive headache to update then change these values for all websites.

[alexAubin]

Similarly to #189 (comment) ,

you should be able to tweak the value using

sudo yunohost app setting wordpress php_memory_limit -v 512M
sudo yunohost app upgrade wordpress --force

(and contrarily to the message about upload max filesize, there's no relation to the nginx part this time)

[CodeShakingSheep]

I agree that this issue should be addressed and the default PHP memory limit should be increased to 256M (or there should be the option to change PHP memory limit in a config panel setting). To automate increasing the memory after updates I wrote this hook which does the job.

#!/bin/bash

source /usr/share/yunohost/helpers
app_id=$YNH_APP_ID
app=$YNH_APP_INSTANCE_NAME
php_version=$(ynh_app_setting_get --app=$app --key=php_version)

if [[ "$app_id" == "wordpress" ]]; then
	sed -i 's/php_admin_value\[memory_limit\]\s*=.*/php_admin_value[memory_limit] = 256M/' /etc/php/$php_version/fpm/pool.d/$app.conf
	if systemctl --help &> /dev/null; then
		systemctl reload php$php_version-fpm
	fi
fi

This script 10-wp-increase-php-memory-limit is placed in /etc/yunohost/hooks.d/post_app_upgrade. It does the job well. Perhaps this is helpful to anyone as long as this hasn't been addressed officially in the package.

[alexAubin]

I would really recommend sticking to

sudo yunohost app setting wordpress php_memory_limit -v 512M

which is a somewhat simple command that only needs to run once (+ the force-upgrade after to fully propagate/regenerate the php config), at least it should be simpler and more reliable than a custom hook...

[tio-trom]

pm.max_children is another bit that matters a lot for many websites. I have different values for different WP installs to give some more priority over others.

Look truth is that the following can break a WP install if not correctly set up:

pm.max_children
php_admin_value[upload_max_filesize]
php_admin_value[post_max_size]
php_admin_value[memory_limit]

I manage WP websites since 2007 or so. I have seen this countless of times.

So the best would be if we can edit these values and have them be kept/migrated when updating WP.

Now I see another WP YNH update. I have 10 WP websites on one server :)). I feel like having a panic attack updating them via YNH when I know that for each of them I have to redo those settings.

So if possible if you can please let the admins choose custom values for the above and have these custom values be kept after a WP update.

;)

[dankerthrone]

I would really recommend sticking to

sudo yunohost app setting wordpress php_memory_limit -v 512M

which is a somewhat simple command that only needs to run once (+ the force-upgrade after to fully propagate/regenerate the php config), at least it should be simpler and more reliable than a custom hook...

oh! that does sound a bit easier. Will this not get overwritten by future updates?

Also, would it be possible perhaps to implement this function as a GUI item in the admin backend? Something like

How much RAM should the Wordpress service for this instance be allowed to take up? [$NumberEntryField] ⬇️⬆️

or

For advanced users: directly set wordpress php_memory_limit: [$NumberEntryField] ⬇️⬆️

[dankerthrone]

oh! that does sound a bit easier. Will this not get overwritten by future updates?

to answer my own question: after today's update, the php_memory_limit was reset again. I heeded @alexAubin's advice and it worked as described. Thank you, Alex!

(I do however still think it would be a quite useful feature to implement this function in the webadmin backend)

[bernhardkaindl]

@dankerthrone, the testing branch https://github.com/YunoHost-Apps/wordpress_ynh/compare/testing (scroll to the bottom to find the current changes to scripts/install) has increased limits for new installations:

ynh_app_setting_set_default --key=php_memory_limit --value=768M
ynh_app_setting_set_default --key=php_upload_max_filesize --value=512M
ynh_app_setting_set_default --key=php_post_max_size --value=512M
ynh_app_setting_set_default --key=php_max_file_uploads --value=512M

When testing is successful, it would become the new default WordPress application.

Note: If you'd test to change WordPress URLs, I've an incremental fix on top of the official testing branch here. This command installs a new wordpress app using my updated testing branch. The domain.tld must be changed to one already configured in your YunoHost:

sudo yunohost app install -l New-WordPress -a "domain=domain.tld&path=/&init_main_permission=visitors" https://github.com/Akzente-Training/wordpress_ynh/tree/testing

For people reading this later, after my latest PR #276 for improving the "Change URL" process, you can instead install Wordpress using the latest official testing branch:

sudo yunohost app install -l New-WordPress -a "domain=domain.tld&path=/&init_main_permission=visitors" https://github.com/YunoHost-Apps/wordpress_ynh/tree/testing

[bernhardkaindl]

@CodeShakingSheep, likewise for your information (see my previous comment in the PR for the info)