literorrery

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!

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?