Support » Plugins » WF not scanning is a symptom of a larger problem

  • arcane

    (@arcarcane2012)


    First, I apologize that this is very long, I wanted to make sure that I included anything I’ve discovered that could be causing this problem. I can post the full outputs of the plugins I mention here. For now for brevity (HA!) I’ve copied only the failures.

    I’m having a problem that’s affecting WF along with the sites themselves. I’m posting here in hopes that a clue as to why WF isn’t scanning unless manually initiated might point me to the root cause of all of the problems.

    I’m using the latest version of WF – 6.0.15 but this was updated today. I know for a fact that the below issues are present with 5.x that I upgrade from a couple of weeks ago and in 6.0.14 which I manually upgraded from this afternoon.

    This is a self-hosted Ubuntu Linux 14.04LTS/Apache/ISPConfig server that had 2 WP installations (two others were dropped but WP is not being run in multi-site configuration) migrated to it in April from a server that was running a no longer supported version of the same OS. I -think- what I did was copy the directories, set permissions, create and import the databases. It was done in a marathon build/migration and a few things are foggy. 😉

    Ever since the migration, a few things have been happening in WP.
    1. WF does not scan unless manually initiated. When I looked on 07/29/2015 (I have screenies), the last scans were on April 29th and May 07th for the 2 sites. Today, My last scans were 07/29/2015 – so only manual scans are occurring, unless I add a plug-in which seems to spur the automatic process and then complains about WP being out of date and WF being out of date – 2 items that should automatically update – then if left alone they both update by themselves, then not again until the next time I log in and add a plug-in.

    Periodically – not all the time – I see the following at the top of the Live Traffic page: “Notice: An unexpected error occurred. Something may be wrong with WordPress.org or this server’s configuration.” There’s more but it’s cut off on my screen – it’s to the effect of try the support forums for help. I’ve googled and prowled the support forums for hours and not found a solution to this particular server’s setup/problem. I’ve seen it elsewhere too, but I don’t recall where – probably in the updates screen but it was two weeks ago that I last saw it.

    2. Within WP itself, No plug-ins are flagged as needing to be updated, nor are the updates to core. Once I go to “Add Plug-ins” I can often see that there are some that need to be updated. Once I do this or sometimes if I initiate a manual WF scan – finally I will see updates that need to be done. Sometimes this does and sometimes it doesn’t include WP core. I currently have one site that’s convinced that 4.2.3 is the latest, and the other updated “automatically” to 4.2.4 today after I went in and tricked it into realizing it was out of date – by going to add plug-ins and installing HTTPS-Debugger. The second site was still unconvinced though even after adding HD.

    3. Any admin screens are terribly slow – 30 seconds to display to approve comments, save a draft, etc.

    As best I can tell, most of the people complaining of this are having https problems connecting to http://api.wordpress.org. I ran the https-debugger plug-in right after installing it this afternoon and everything looked good – all steps green / passed. When I ran it a few minutes ago, it failed step 7:

    7: [FAIL]: Verifying api.wordpress.org resolves correctly. 66.155.40.203

    I ran the Background Update tester – all pass but the last one:

    WARNING: Couldn#8217;t retrieve a list of the checksums for WordPress 4.2.4. This could mean that connections are failing to WordPress.org

    Which from my reading is a problem I probably can’t fix and some think might be transient. The thing is, every single time I check in Background Update Tester, it’s failing and I sincerely doubt that those WP servers are that unreliable. Either way, I suspect that this is the core of the problem that’s making WP painfully slow and making WF not scan.

    When I use Core Control and look in the logs, it looks like connections to http://api.wordpress.org are timing out.

    When I ping manually from the server that runs these WP sites, or on my desktop – both in the same network – I get responses. The first response on the server after the DNS lookup seems reasonable (60.2ms) The second response takes longer (320ms) and the others are somewhere in between. Dig works fine and returns 4 possible IP addresses.

    In CC in the Filesystem Access section, the only transport not available is SSH2. In the External HTTP access section, cURL is currently enabled and testing the transport indicates that it’s working – I’ve tried with it both enabled and disabled – no noticeable change.

    I’ve also played with the version of PHP/CGI available. PHP-FPM (default), Fast-CGI and CGI all give the same result.

    All of this has the unfortunate result of making me not work on / take care of the site. The front end is a little slow – seems a 5 second delay consistently when first loading the site, but page clicks are OK as long as a long delay between the clicks doesn’t happen. Almost like something is needing to “wakeup” if left too long between clicks.

    The only possible work around I can come up with is threefold:
    1. change the timeout length – in hopes of letting checks for plug-ins and WP updates to succeed,
    2. disable cURL – some people especially if they’re having trouble with that secure connection to WP have luck with this, and
    3. set WP_HTTP_BLOCK_EXTERNAL in the hopes of speeding up the back-end.

    It seems though that I shouldn’t have to do all of this to an install that used to run just fine on another server. Not to mention I don’t know the full ramifications of what else it would affect. I’d rather just find the configuration problem.

    Any suggestions are extremely welcome! I’m tearing my hair out at this point.

Viewing 9 replies - 1 through 9 (of 9 total)
  • You should post directly to the WF forum.
    https://wordpress.org/support/plugin/wordfence

    Thread Starter arcane

    (@arcarcane2012)

    Thanks kmessinger – This isn’t specific to Wordfence though. I can put it there, for some reason, that’s where I thought I was – started the post 2 weeks ago. As the title mentions though the WF behavior is another symptom of a larger problem.

    Have you disabled all plugins and switched to the 2014 theme?

    In your wp-config.sys change define('WP_DEBUG', false); to define('WP_DEBUG', true);

    Also please post a url using the word dot instead of a .

    Thread Starter arcane

    (@arcarcane2012)

    I’m sorry, I should have mentioned that. One site is using the 2014 theme as its default. The other was using Weaver, and I’ve temporarily changed it as well as disabling all plugins. The one using weaver is the one convinced that 4.2.3 is the latest WP version, so that’s the one I’ll work with for now.

    I have wp-config.php no wp-config.sys
    The setting has been changed.

    URL is www dot stormi dot ca

    I should note too that I had replaced the update.php from a tar file I’d downloaded straight from WP 2 weeks ago and it didn’t resolve the issue.

    With debug mode enabled, I get the following when checking for updates:

    Warning: An unexpected error occurred. Something may be wrong with WordPress.org or this server’s configuration. If you continue to have problems, please try the support forums. (WordPress could not establish a secure connection to WordPress.org. Please contact your server administrator.) in /var/www/clients/client2/web1/web/wp-includes/update.php on line 295

    Warning: An unexpected error occurred. Something may be wrong with WordPress.org or this server’s configuration. If you continue to have problems, please try the support forums. (WordPress could not establish a secure connection to WordPress.org. Please contact your server administrator.) in /var/www/clients/client2/web1/web/wp-includes/update.php on line 457

    Warning: An unexpected error occurred. Something may be wrong with WordPress.org or this server’s configuration. If you continue to have problems, please try the support forums. (WordPress could not establish a secure connection to WordPress.org. Please contact your server administrator.) in /var/www/clients/client2/web1/web/wp-includes/update.php on line 119

    Last checked on August 11, 2015 at 3:29 pm. Check Again
    You have the latest version of WordPress. Future security updates will be applied automatically.

    If you need to re-install version 4.2.3, you can do so here or download the package and re-install manually:

    Thread Starter arcane

    (@arcarcane2012)

    This is the output of HTTPS tester as of 3:36pm MST: (I re-enabled this plugin for this test and disabled it right after)

    HTTPS Tester

    Since WordPress 3.7, all communication to WordPress.org is attempted over HTTPS, this is to improve security and make it harder for someone to perform a MITM attack against a WordPress site.

    Unfortunately, there have been reports that some hosts configurations are not allowing it to work, this plugin is used to debug it and find out what’s going on.

    [PASS]: Your WordPress install claims to support HTTPS Connections
    [PASS]: Checking that the HTTPS Root Certificate bundle exists and is accessible
    [PASS]: cURL is installed and supports SSL communication, cURL Details: version_number=467712; age=3; features=50877; ssl_version_number=0; version=7.35.0; host=x86_64-pc-linux-gnu; ssl_version=OpenSSL/1.0.1f; libz_version=1.2.8; protocols=dict,file,ftp,ftps,gopher,http,https,imap,imaps,ldap,ldaps,pop3,pop3s,rtmp,rtsp,smtp,smtps,telnet,tftp
    [PASS]: OpenSSL is installed. OpenSSL 1.0.1f 6 Jan 2014 268439663
    [PASS]: Checking if stream_socket_client exists
    [PASS]: Checking if openssl_x509_parse exists
    [PASS]: Verifying api.wordpress.org resolves correctly.
    [PASS]: [Streams] Communication with WordPress.org suceeded, it took 5.292 seconds
    [PASS]: [Streams with a POST body] Communication with WordPress.org suceeded, it took 5.293 seconds
    [PASS]: [cURL] Communication with WordPress.org suceeded, it took 5.792 seconds
    [PASS]: [cURL with a POST body] Communication with WordPress.org suceeded, it took 0.276 seconds
    [INFO]: PHP Version: 5.5.9-1ubuntu4.11

    Yes, php not sys.

    That message is 99% of the time caused by the server.

    Who is your host? You should let them know about the message. Your test shows the server passes cURL which is sometimes the problem.

    Sorry out of time now.

    Thread Starter arcane

    (@arcarcane2012)

    As mentioned above, this is a self-hosted server. I am my host. I have been notified. 😉

    With cURL enabled or not, interestingly that HTTPS-Tester talks about cURL.

    I just followed a long rabbit hole from another thread that pointed to a TRAC ticket where someone else was talking about ipV6 causing trouble and am wondering something… my server has both ipv4 and ipv6 enabled. My ISP only uses ipv4 at this time. I’m considering enabling (uncommenting)

    precedence ::ffff:0:0/96 100

    in /etc/gai.conf

    I’m thinking, if the issue (definitely related to cURL – based on the error messages changing while playing with enabling and disabling it and testing updates, etc) is related to ipv6 having to time out first, this may stop it? This is new territory for me though and I didn’t see a lot with I looked for wordpress related ipv6 stuff. Thoughts?

    Thread Starter arcane

    (@arcarcane2012)

    I experimented with the “precedence ::ffff:0:0/96 100” I mentioned above along with curl being disabled. Most page loads / post saves now take about 8 – 10 seconds in the backend, and WF scans appear to be running on their own at the moment.

    I’m not quite ready to call it fixed, only because cURL used to run just fine but doesn’t on this server. (And one site had cURL disabled and one had it enabled prior to today’s testing) We have however made huge strides in the speed of things, hopefully to the point where I won’t avoid the site work now and will start to post again to both sites.

    For the night, I’ve turned off Debug mode which has gotten rid of the undefined index (sslcertificates) notices in the Core Control plug-in and re-enabled my main security type plug-ins (WordFence, Akismet, Captcha) as well as Jetpack. That’s really all of them anyway other than the diagnostic plug-ins.

    I will have to watch for updates and WF scans to run though to know if updates are happening properly since both my WF plug-in and WP itself updated while testing but I don’t know what was toggled when they updated automatically. Once I know that, I will update to let people know if this is “fixed” by the 2 changes above.

    Thread Starter arcane

    (@arcarcane2012)

    Just an update:

    I have a new rabbit hole to charge down. One of the 2 sites is updating or at least alerting me to updates and WF is running. The other isn’t. That seems to indicate that it’s a site configuration problem that’s left and not a system configuration. I think the precedence and the cURL settings made a difference but tomorrow morning, I’m going to compare all of the rest – ISPConfig settings and everything in WP and see where the difference is. I’ll report back on what I find.

Viewing 9 replies - 1 through 9 (of 9 total)
  • The topic ‘WF not scanning is a symptom of a larger problem’ is closed to new replies.