depwl9992
Forum Replies Created
-
Now that I look at it, though, it appears like the PHP warning is generated before even the <!doctype>, meaning it occurs outside of the theme parser.
I wondered if anything was resetting the global variable, but found that it’s still intact, as a quick
echo intval(WP_DEBUG);directly after <!DOCTYPE html> in header.php of the theme shows it as still set to 0.So all I can figure is something is ignoring it, or the warning is coming directly from PHP and bypassing WordPress altogether. Though
@ini_set("error_reporting",0);also does not do anything. Still, in either case, @-ing the parse_url() function in request.php still reliably gets rid of this instance of warnings.Regarding the wp-config debug directives edit, I have tried all of this. Errors like this are still visible within the browser.
As for
php -v, I’m told we’re using:PHP 5.2.10 (cli) (built: Nov 13 2009 11:24:03) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies with Zend Optimizer v3.3.9, Copyright (c) 1998-2009, by Zend TechnologiesDefinitely outdated (new versions of plugins like Easy WP STMP break the site completely), and like so many folks out there, there’s no way for me to upgrade this as it’s third-party hosted. Though said third party SAYS they plan to upgrade everyone to cPanel in the next few months, so my outdated PHP problems will hopefully be solved eventually.
Agreed. I have re-written wf503.php and wfLockedOut.php and will manually re-copy them into the lib folder every time I do an upgrade of the plugin. Not the best solution as it never permanently sticks, but at least it works and isn’t terribly inconvenient.
But this I think is more an overlooked thing, as it’s a bonafide PHP error/warning, and not something that Wordfence intentionally generates
I have had this issue as well, but more due to our hosting issues. The www-data user on the remote server is not controllable by the ssh login user given to us by our content provider, nor are there any groups that both users belong to.
The solution I found, which is very likely a bad bad idea, but seems to work is to set the following recursive permissions to 777, which are the only three directories set to this in the entire WP installation:
- wp-content/wflogs
- wp-content/wfcache
- wp-content/plugins/wordfence/tmp
I know I’m probably playing with fire here, but so far in the last six months I have not had any issues.
My suspicion of the root cause is that for whatever reason, my host (or possibly misconfigured fwrite() operations from WF) automatically assumes the ownership of every php-generated file to nobody.nogroup with permissions 660, where as I need these files to be chowned to my ssh user so that I can at least set a global permission to allow Apache’s www-data user access.
I know this is more of a “me too” than a viable solution, but hopefully there are a few details here that will help track down or generate a realistic fix.