Support Forum
Support Forum
Offline
The auto-upload failed a few days ago due to, I believe, either a WP issue or a permissions issue on the server. I did not record the WP error msg for the SP upgrade but this example for Super Cache upgrade appears to be identical:
The update process is starting. This process may take a while on some hosts, so please be patient.
Enabling Maintenance mode…
Updating Plugin WP Super Cache (1/1)
Downloading update from https://downloads.wordpress.or......1.4.7.zip…
Unpacking the update…
Installing the latest version…
Removing the old version of the plugin…
Plugin update failed.
An error occurred while updating WP Super Cache: Could not create directory. /public_html/wp-content/plugins/wp-super-cache/
Today I can attend to it. First, I installed the current SP ver, then restored a previous backup of the DB (10 days old) so as to enable the plugin to do the DB upgrade again. WP ran its own DB upgrade, then I attempted to run the SP upgrade. But I get this error msg:
Upgrade Simple:Press From Version 5.5.11 to 5.6.1 (Build 13318 to Build 13700)
Upgrade Aborted
current build: 13318
%%%marker%%%{"status":"success","type":"upgrade","section":13495,"response":"Build upgrade section 13495 executing. Status: success
","error":""}%%%marker%%%
Offline
The update process uses a series of AJAX transactions and expects an explicit set of data to be returned from the server after each section. If that data is not what is expected it stops the process - it has to as there can no longer be a reliable marker as to where the process is up to.
Every now and then we come across an instance like this and there have been two main culprits in the past. One - the rarest - is when the website calls for extra authentication for each request to the server and the3 other - more likely - is when another process hijacks the AJAX call.
I know it is a pain but if you are able - deactivate a plugin or two that you think might be performing such ajax calls - or keep deactivating until the process completes as expected and the culprit found. This has proved successful for, I believe, more or less everyone who has had this problem in the past although just now and then it has proved to be the WP theme they are using.
Of course - everything can be returned to normal after the upgrade is performed.
For the record - the changes between 5.5.11 and 5.6.1 are small and could easily be made manually to the database if you are able and want to take that route. But it would be useful information for the future to know what is causing the block.
 |
YELLOW
SWORDFISH
|
Offline
Thanks for the detailed info, Andy.
No luck, though. I deactivated each plugin individually without success. Eventually I deactivated all of them but it still did not work.
Please let me have the manual instructions - ideally SQL statements, or whatever guidelines you can provide.
There is still something wrong with the server set-up I think. Automatic plugin upgrades still fail at the last step as detailed above. Web host support cannot figure it out - but I can live with it. However, it may be related to the SP DB upgrade issue. I have no idea.
Offline
It is actually two values that need changing and they can be done via a tool like phpMyAdmin with ease.
Both are in the table xxx_sfoptions where 'xxx' is your WP prefix.
You need to find the entry where 'option_name' = 'sfversion' and change the value to '5.6.1'
The you need to entry where 'option_name' = 'sfbuild' and change that value to '13700'
If you sort the option_id column then you will almost certainly find these two entries in ids 1 and 2.
And when you have made those 2 changes you be set to go.
|
YELLOW
SWORDFISH
|
All RSS1 Guest(s)