Drumology2001

It turns out that this problem is due to the WooCommerce Extra Product Options plugin. I have reached out their developer to see if they can take a look at making it compatible with yours plugin. If not, I will have to use a different one for Wholesale pricing, it sounds like (which I hope I don’t have to, since I really like the simplicity of yours)!

Also, I am happy to provide you credentials to the site if you’d like to go take a look directly. Please let me know what e-mail address to send them to.

They started around mid-September, I believe? Might have been earlier, but the person who manages the back end of the website day-to-day says she had been deleting duplicate entires from the back end for a while, so I couldn’t give you an exact day that it started — other than it’s been going on for the last 4-5 weeks or so, most likely.

Since I have no way of finding your e-mail and you didn’t provide it, I’ll drop a Dropbox link here with the screenshot:

https://www.dropbox.com/s/r8de7jvj9cxqw07/DeadSpace.png?dl=0

As you can see, it’s adding extra space at the top, and the bit of code I highlighted at the bottom of the screenshot shows the code that appears to be causing it.

Whoops! Sorry, was working on another aspect of the site. It is back up now. Thanks for the quick response! I look forward to hearing what you are able to find. 🙂

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! 🙂

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.

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. :]