I know in the cases where I had this problem with sites hosted by HostGator, they needed to make exceptions in Apache’s mod_security. I sorry I don’t know the specifics of what changes they needed to make, but they were able to look at log files after I got the error and figure out what needed to be opened.
Thanks Matt,
obviously my hosters are more lazy than yours. I hope someone can at least highliht me the direction to the solution.
i don’t know if it’ll tell you anything new, but it may be worth trying this tool?
background updates tester
we’ve seen a few times where this couldn’t catch the issue lately, but usually it does
And my situation is one of these…
This site is able to apply these updates automatically. Cool!
The point is, that it really does… The problem takes place with plugins and themes only.
cool, well no easy answer there 😛
have you already tried turning on WP_DEBUG?
the codex on wordpress debugging has some tips on this. again it may not provide anything new, but i’d be surprised if you didn’t get something by turning WP_DEBUG to true and maybe even setting php to output all warnings
if interested int he php debug output, you can add these lines to the top of your .htaccess file: (assuming the host allows override of these from their php.ini)
php_flag display_errors on
php_value error_reporting -1
Thanks, bernbe01. I added the lines, no change so far.
define(‘WP_DEBUG’, true);
define(‘WP_DEBUG_LOG’, true);
define(‘WP_DEBUG_DISPLAY’, true);
define(‘SCRIPT_DEBUG’, true);
and still only the same error messages, no new information.
darn!
want to try an manual reinstall?
0. take a backup of your existing system (files & database – let me know if you need help)
1. download the your version of wordpress from the release archive (it’s recommended to go to current 4.1.1 unless you have reason not to)
2. unzip it locally on your computer
3. connect to your server using an ftp client, selecting option to see hidden files if available
4. delete from your server everything in wordpress’s install folder except wp-config.php and wp-content/
5. upload from the newly unzipped wordpress files all files and folders except wp-content/ (there will not be a wp-config.php in the newly unzip wordpress)
bernbe01, I really appreciate your help 🙂 Thanks! Sorry for the delay.
The point is that the copy ow WP I am running was installed in the way U described. More than, I reinstalled it couple of times in the same way.
Another seed of craziness is that there is a second site running the same WP on the same vhost – and it doesn’t have the problem.
And yes, I have already copied the engine files of one site to another, changing the .cfg – with no success, as U can see.
I suggest that we focus on the diagnostics of what goes wrong with the connection. That’s what I’ve got as a dump of raw_response of line 457:
URL:string(50) "https://api.wordpress.org/themes/update-check/1.1/"
RAW_RESPONSE:object(WP_Error)#4259 (2) { ["errors":"WP_Error":private]=> array(1) { ["http_request_failed"]=> array(1) { [0]=> string(65) "Operation timed out after 3000 milliseconds with 0 bytes received" } } ["error_data":"WP_Error":private]=> array(0) { } }
Meanwhile http://novorossinfo.org/wp.php
$url = 'https://api.wordpress.org/themes/update-check/1.1/';
print_r(get_headers($url));
opens the same URL with the following result:
Array ( [0] => HTTP/1.1 200 OK [1] => Server: nginx [2] => Date: Sat, 28 Feb 2015 07:20:48 GMT [3] => Content-Type: text/plain; charset=utf-8 [4] => Connection: close [5] => X-Frame-Options: SAMEORIGIN )
I can’t really figure out why this time-out occurs in the first case if in the 2nd it runs fine.
Thanks again.
Try this out, scan your website, I was able to see that my apache server was out of date http://sitecheck.sucuri.net
