WP Updates not showing latest WP version available

Ok, and just to clarify, these are all on the same server, but only some refuse to update?

Have you added any wacky security rules into the .htaccess files on the ones refusing to update?

Hi Drumology2001,

I ran into this a little while ago, with two WordPress 4.0 sites that didn’t think they needed to upgrade. It was a similar situation to what you’re describing. I worked around it, but to this day (3 months later) it bugs me that I didn’t know why.

In one case, I had previously installed the WordPress Beta Tester plugin (before we went to 4.0). I removed that plugin, as well as disabling everything else, and still no “upgrade” message.

Then, I did a manual upgrade of WordPress. This has resolved the issue for both sites, which are now telling me I should Upgrade to 4.1.1.

Good luck resolving this.

James: Yes, all are on the same VPS server; some are on different disks/partitions within the server, but there are sites on each disk that auto-update and don’t auto update, so there’s no correlation there.

As far as the .htaccess file: I use the All-In-One WordPress Security (AIOWPS) plugin for the majority of our sites. It makes alterations to the .htaccess file, but nothing “wacky.” I have checked the settings I use in that plugin (comparing one on an updated install and one on an outdated install) and they have the same settings, so I’ve been ruling that out as a possibility, as well. (I even posted a new thread in the plugin developer’s support page to ask if there were settings that could cause this issue; you can see that thread here.)

Ancawonka: I’m not sure I understand your suggestion. I am trying to avoid having to do manual updates (if at all possible) by figuring out why the automatic updates aren’t being triggered in the first place. I’m sure I could go through and manually update the sites to 4.1.1, but I’d have to do this across 14 different websites, and that would eat up a lot of time — especially if there’s a file setting or checkbox somewhere that I’m missing that would trigger the auto update. :]

Thanks, ancawonka!

Since you have 14 affected sites, this gives us an opportunity to try two things separately.

1. Manually update one not-4.1 site to WordPress 4.1 from https://www.ads-software.com/download/release-archive/ following the guide at https://codex.www.ads-software.com/Upgrading_WordPress_Extended

If that worked, you’ll be prompted to update to 4.1.1.

2. On a different site, download a fresh copy of WordPress, and using wp-config-sample.php, build that site a fresh wp-config.php file adjusting only the database details.

Fingers crossed, one of those will work.

James: I’m not sure I follow what you’re suggesting here. See my questions below:

1.) Is the theory here that if I update a 3.9 site to 4.1, we’re trying to see if it will automatically prompt me to update to 4.1.1 after the upgrade is complete?

2.) On this one, I’m not sure how it’s different? When you say “a fresh copy of WordPress,” do you mean I should do a 4.1.1 manual upgrade on another site? And should I do this on an existing site, or a blank WordPress install?

If you can clarify, I’ll give these a try tomorrow when I get into the office.

1. Yes, we’re trying to see if manually updating one site fixes the problem as ancawonka suggested. If it does, then you’ll need to manually update all 14 just this once, and the problem should be fixed going forward.

2. No, I mean you should download a fresh copy of WordPress from https://www.ads-software.com/download/ and take out the wp-config-sample.php file. Then, pick another one of the broken sites (separate from the one you’re manually updating) and replace that site’s wp-config.php file with the fresh one, keeping *only* the database connection details. Besides the database connection details, leave the rest of the new wp-config.php file untouched and do not bring anything else over from the old wp-config.php file.

In 1, we’re trying to see if the core files were corrupted at some point. In 2, we’re trying to see if something in the existing wp-config.php file was fouling up the process.

Are you certain you’re connecting to WP.org for updates? Can you try running a traceroute the www.ads-software.com? Can you do a curl -O https://www.ads-software.com/latest.tar.gz and actually download a copy of WP latest?

Also, in your database in the wp_options (or whatever your table prefix is), there might be an option name _site_transient_update_core. That’s a cache of the last time core checked for updates. Try deleting that option or using a plugin to delete your transients. They might not be getting updated for some reason.

Voldemortensen: I’m not sure how to do a curl (other than the kind at the gym). ??

On your second suggestion: if I delete that option from the database, do I run any risk of messing up my site? What you’re suggesting is very similar to another solution I saw for an earlier version of WordPress, and I’m more than willing to try it, but just want to double check that removing that line from the table isn’t going to crash everything.

James: If Voldemortensen’s idea doesn’t work, I’ll be doing your two-part method and reporting back.

To do a curl you would need to ssh in to your server, if you’re not comfortable with command line I wouldn’t worry about trying it.

You should be pretty safe to delete that option. It’s just a cache of the last time your install checked www.ads-software.com for updates. This would be roughly the equivalent of clearing your browsers cache.

Voldemortensen: I deleted the line you specified out of the database, then logged back into the Admin back end, and nothing changed — it’s still not recognizing that it needs an update.

As for your earlier question about whether the sites are able to connect to WP.org, I am using the Background Update Tester plugin, which reports the following:

PASS: Your WordPress install can communicate with www.ads-software.com securely.
PASS: No version control systems were detected.
PASS: Your installation of WordPress doesn’t require FTP credentials to perform updates.
PASS: All of your WordPress files are writable.

This site is able to apply these updates automatically. Cool!

However, despite that report, core files aren’t getting updated. :/

Any news on the two tests from earlier?

Did you get this figured out? I’d love to know if you found the answer!

Exactly the same issue here.
Several recently commissioned sites do not show core update alerts as described above.
In fact the whole section referring to the version number etc is missing from the WordPress Updates page.
I’m also using mainWP and this doesn’t show the updates either although I’m not sure how this gets the version number etc.
From mainWP it looks like it correctly notifies of updates on all sites running less than 4.1
4.1 does not appear to register an update on my system at least.

Hey guys! I figured it out!

It appears that the cPanel was adding modified code to the WordPress install. I was using the cPanel’s native “Site Software” feature to install WordPress, and for certain installs, cPanel was altering the code in the following files:

wp-admin/includes/update.php
wp-admin/update-core.php
wp-admin/includes/class-wp-upgrader.php

And here is the code that was happening in each:

update.php

Should have been:

30	function get_core_updates( $options = array() ) {
31	   $options = array_merge( array( 'available' => true, 'dismissed' => false ), $options );
32	   $dismissed = get_site_option( 'dismissed_update_core' );

But instead, it was:

30      function get_core_updates( $options = array() ) {
31	   # cPanel override: Disable all core updates to prevent conflict with cPAddons.
32	   return false;
33
34	   $options = array_merge( array( 'available' => true, 'dismissed' => false ), $options );

update-core.php

Should have been:

141	   function core_upgrade_preamble() {
142	   global $wp_version, $required_php_version, $required_mysql_version;
143
144	   $updates = get_core_updates();

But instead, it was:

141	function core_upgrade_preamble() {
142	   # cPanel override: Do not display the current or the latest version, because we've disabled updates.
143	   return;
144
145	   global $wp_version, $required_php_version, $required_mysql_version;
146
147	   $updates = get_core_updates();

class-wp-upgrader.php

Should have been:

1807	   public function is_disabled() {
1808	       // Background updates are disabled if you don't want file changes.
1809	       if ( defined( 'DISALLOW_FILE_MODS' ) && DISALLOW_FILE_MODS )
1810	           return true;

But instead, it was:

1807	   public function is_disabled() {
1808	       return true; // Force this functionality to disabled because it is incompatible with cPAddons.
1809
1810	       // Background updates are disabled if you don't want file changes.
1811	       if ( defined( 'DISALLOW_FILE_MODS' ) && DISALLOW_FILE_MODS )
1812	           return true;

How did I find all these? I simply downloaded the Wordfence plugin and ran a scan; the scan notified me that these files didn’t match up with what the WordPress repository shows for that code. All I did was clicked on “Restore the original version of this file” for each of the 3 files, and once that’s done, click on “Dashboard > Home”. Once the files are restored to their original version, the WP update reminder link shows up, and I am able to do one-click upgrades again!

I wish I had found this workaround sooner! It has saved me SO MUCH work! ??

@drumology2001 that is awersome! Thanks for sharing your fix!