/wp-admin/customize.php is a standard URL that typically have to be white-listed because of some action it (validly) does that the firewall will otherwise block. The POST parameters are “suspicious”.
Need to white-list that URL on the firewall page.
Can be done manually, but another way is likely to switch WordFence to learning mode, run the customize.php functionality, watch WordFence complain, block it, and ask you what to do. Then declare it a false positive. That will automatically add the right parameters into the white-list table.
Yeah, on paper that’s a great idea… in reality, the whitelisting feature on Firewall page doesn’t work, and whatever parameters I add in there and try to whitelist do not apply whatsoever (I keep getting 500 Errors), so I’m not sure how I have to frame this URL (with domain.com/wp-admin/customize.php or just /wp-admin/customize.php) in order to make this work, as I’ve got every single combination and permutation of it in there and it still hangs with 500 Error.
And no, when I run the /wp-admin/customize.php Wordfence doesn’t end up complaining – I just get a 500 error, so there is no way of whitelisting or blocking it right there and then.
Hmm.. Then I guess the 500 errors will have to be investigated especially.
I do know that the automated while-listing of /wp-admin/customize.php is how mine got white-listed.
I specifically remember the puke WordFence did on that URL, where I had to claim it as OK, adding it as an exception. And it is the only URL at all that is white listed in my config.
As it states in the listing “Whitelisted by via false positive dialog”.
In the table as
Filter URL: “/wp-admin/customize.php”
Filter Param string: “request.queryString[return]”
I tried adding that manually as well, no luck.
I guess you’d have to actually debug. 🙂
Do you have display_errors tuned on for that back-end section, so you can see any PHP errors or stack-traces that pop up? Might be needed to tell you what’s going on behind those curtains.
How would I turn that on in the backend?
Well.. The fastest would be to simply turn it on for the whole site. In your PHP.ini, .user.ini, or .htaccess file.
Since your failure is in the back-end, it’s not like your front-end visitors would see a difference, since thats not where the failure is.
To turn it on Only for the back-end, you would have to turn it on depending on the scripts called.
The simplest and fastest is the ugly way. Temporarily edit the affected PHP file(s) in /wp-admin and add
ini_set(‘display_errors’, ‘1’);
in PHP directly. Adding it to the top of customize.php would be my first step.
Another way would be to set it, without editing the PHP file(s) is to set it from .htaccess on a conditional of the path used. For example turning on for all paths matching ‘^/wp-admin/’
In htaccess it is turned on using a line like
php_flag display_errors on
Might wanna add
php_flag display_startup_errors on
php_flag html_errors on
as well, while at it. Just in case.
in PHP.ini/.user.ini, the format is
display_errors = 1
or
display_errors = On
Tried all of the above, and nothing in the browser, but in the /wp-admin/error_log I see these:
[11-Aug-2017 17:28:04 UTC] PHP Warning: DOMDocument::loadHTML(): End tag : expected ‘>’ in Entity, line: 1 in /home/public_html/wp-includes/widgets/class-wp-widget-text.php on line 122
[11-Aug-2017 17:28:04 UTC] PHP Warning: DOMDocument::loadHTML(): htmlParseEntityRef: no name in Entity, line: 1 in /home/public_html/wp-includes/widgets/class-wp-widget-text.php on line 122
Any idea if that is the cause of any sort of a problem here and how to fix it, or if it’s just some random unrelated error?
It could be unrelated.
class-wp-widget-text is WordPress’ standard text widget. Either called alone, or through an Extending widget installed on your site. So that is easy to check out.
Go to your widget panel and disable any Text-based widgets you are using. (“text” here also means that they can contain HTML.)
Temporarily park that/those widget(s) in the disabled area to save and keep their configurations for later.)
That would make the DOM problems seize to exist, since you no longer use the text widget. The DOM problem is likely because some invalid HTML was typed or pasted into that text widget’s value field.
With the widget(s) disabled, you would see whether that also have an impact on your 500 errors.
@crazyserb Just another recommended way to debug this server error, you can edit (wp-config.php) file and replace this line:
define('WP_DEBUG', false);
with:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
Now, when you access the Customize page and get “Server error 500” again, you can check this file (/wp-content/debug.log) for any error messages.
Thanks.
Nope, none of those helped… I seriously can’t figure out what’s causing it all.
Will have to keep Wordfence disabled until further notice, it seems.
