Hi there,
Thanks for contacting Give support (and welcome to the WordPress support forums in general!).
Normally that error message indicates a server- or host-related issue (either PHP limits set too low for your specific install or the hosting itself is too limited). Sometimes that’s a conflict between Give and another plugin and sometimes Give is the “final straw” to your your server’s “camel.”
The specific thing you need to increase is the PHP post max size. Your web host should be able to help with that.
If they are not able to help with that, your next option (assuming that finding a new web host is out of the question) is to find a way to create a staging site where you can peacefully deactivate other plugins until we find a culprit. Some web hosts include this as a feature of their hosting, and other solutions exist for creating a staging site on the fly.
As I said though, many times this is less of a conflict with a specific plugin, and more of a cumulative effect of multiple plugins utilizing server resources.
I wish I had an easier option than “contact your host” but that’s where I would start.
Thanks for using Give! Have a great day.
So, thankfully, I’m my own admin on this box, but I’m not sure that’s really going to help me. I’ve already got post_max_size set to 2GB in my .htaccess for this WP install so I could upload a video file once. Before that, it was 64MB and I was having no issues. How much bigger can Give need it to realistically be?
I went ahead and took an outage, deactivated every plugin but Give and the PHP Settings I’m using to set PHP settings in a convenient spot, and no love. I upped post_max_size to 64G and still nothing. I even upgraded to php7.1 to see if it was a problem with old PHP config. Still no joy. Any other suggestions?
Also, talking with another PHP developer I know, I’m dubious about this being related to post_max_size, ’cause the repro steps don’t invoke me trying to upload anything:
1) Install plugin.
2) Activate plugin.
3) Click on Donations->Settings.
How does post_max_size impact that?
After much hacking with said PHP developer, we’ve tracked down the source of the problem:
1) In my wp-config.php from ages back, I had a standing command: $_POST['user_name'] = blah. I don’t remember why I put it there, but it was there, probably from a past hack trying to solve some problem about default user names.
2) In wp-content/plugins/give/includes/admin/class-admin-settings.php, in function output(), if $_POST isn’t empty, it tries to save. Because of the line in my wp-config.php file, $_POST isn’t empty, so it tries to save. But what does save() do?
3) In function save(), it tries to verify that the post is legitimate by doing a nonce validation. If that fails, it calls die(), which is the behavior we were observing. We confirmed this by changing the error message in the file and validating that the changed error message occurred on page-load.
4) So, what about verify_nonce()? It’s looking to see if there’s any field in the request keyed to _give-save-settings to validate if its key matches what’s in WP’s session info, presumably. If it’s not, or if it’s missing, the plugin assumes a bad actor and returns false.
So what does all this mean? That key in my wp-config.php field from a past hack was triggering Give’s “somebody tried to save settings” checker, but I hadn’t actually tried to save settings. As a result, Give assumed some kind of error and refused to load. Kudos to the development team for protecting me from bad actors and inappropriate data management. Perhaps instead of checking for the non-existence of post, the plugin could check for the existence or non-existence of a specific key within $_POST? Other plugins — or developers — may not be careful with their data management, and I can see this easily breaking others.
To be sure, my only real issue here is that the underlying culprit was a silent failure that gave no warning to the actual problem. It took one highly-qualified PHP developer and one old Perl/Java hacker a few hours to debug this, and the end diagnosis had nothing to do with the original development team’s suggested fix.
… now I have to go set post_max_size back to 64M where it used to be. Thanks!
Thanks @literorrery for that detailed update, and really glad to hear that you had a friend who could look at it closely and find the source of the issue AND that it really wasn’t Give in the end 😉
We’ll look into that to see if there’s any kind of improvement we could do on the settings page just for good measure.
Thanks for using Give!
Hi @literorrery We’re looking into that issue for improvements. Here’s the issue so you can track our progress on it:
https://github.com/WordImpress/Give/issues/2492
