Oddly my money would be on one of the other two.
It would be great if next time you could disable them one at a time and retry between each one. That would nail it…
Tried just to refresh between every “turn off” but it didn’t change the counter… The update counter changed only by going directly to the update page… :/
But my guess would be Envato Toolkit because I’ve tried to cut Updraft before and it didn’t do the trick.
Envato Toolkit manage updates for my Customized Pixia WordPress Theme… So It could be that one, who was blocking WordPress from acknowledging all those Simple:press update…
If the problem shows up again, I will try by turning off Envato Toolkit only, but would be nice if we could know how many of those problems are linked to Customized WordPress Theme… ^_^’
I will ask if anyone else posts with the problem. Be great to hear what happens next time around and thanks for the info so far…
And the culprit (for my case) is… W3 Total Cache ! O_o
The weird part is : every bits of the Forum and Simple:Press part of my website is excluded from W3 caching process but it’s definitively that Plug who block the SP plugin upgrade (that and only that).
WordPress Admin tool don’t notice SP plugin update but pure SP update are still OK. When I deactivated W3 Total Cache, SP Plugin Update adds themselves to the count…
Everything else works perfectly fine… :/
Wow. Now that truly IS a surprise. And, of course, a lot of our users also use W3 Total Cache.I am absolutely intrigued as to what could be cause… And thanks for the info as well of course.
I’m sure I had this issue once before right? I also discovered recently that opening the site in Chrome instead of Firefox and running the updates got around the issue. Odd.
So Tal, are you experiencing this or just offering another potential workaround?
I have a similar problem, SP itself updates with W3 enabled but no SP plugins will update, they are offered but all fail, as soon as W3 is de-activated all the updates proceed normally. SP is totally excluded from the W3 cache on our system too.
I’m now in the habit of de-activating W3 before I do any updates as I’ve also had problems in the past with other WP plugins getting corrupted when the updates were performed with W3 activated.
cant think of a good reason to cache the admin either… but perhaps could be related to our ajax processing using index.php which might be on the front end and hence cached… and wont be part of the forum page…
so you could try excluding from the cache strings that contain: http://yoursite.com/index.php?sp_ahah=
I don’t understand why the admin should be affected by a cache plugin either but clearly something is going on.
If you can add that string as @mr-papa has suggested above it would be helpful if you could let us know the result next time an update comes along.