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.

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.

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.

Thanks, Andy. If I get any inkling as to the root cause of the abort issue I will update this thread.

That would be appreciated.