UNPACK not working correctly?

Thanks. Will report to the Core team.

If anyone else experince the same situation, just let us know and provide specific info like @Dick_Metcalf did above.

I shut down the website, reinstalled WP backup again, then tried to use the MIGRATION .zip file… here’s what I’ve got after 45 minutes… it’s just “sitting” there…

Update ClassicPress

Downloading update from https://github.com/ClassicPress/ClassicPress-release/archive/1.0.0-beta1.zip…

Unpacking the update…

Please CANCEL the request to CORE team… I found out that I had two instances of the website running… all is good now; so far, no other errors detected

I had an issue upgrading from Alpha to Beta as well.

I used the Migration Plugin to install the Alpha, then immediately went to upgrade to the Beta and got the message:

Another update is currently in progress.

I drove into the office and tried again (27 minutes later - because I stopped for coffee) and everything upgraded correctly. May just be a timing issue.


As I said in another post, I upgraded my Alpha installation to Beta by uploading the files using FTP.

On another site, I thought I would try the migration from WP to CP Beta using the plugin.

The file is called upgrade-to-classicpress.zip which is confusing. For the Alpha migration, it was called switch-to-classicpress.zip which makes sense.

So I installed the plugin anyway and it said it was going to install the Alpha version?? It then hung, with that message:

Another update is currently in progress.

I logged out and logged back in again, but it gave me the same message. I then uploaded the Beta files via FTP instead, which worked.

I think the zip file is misleading and should be renamed. I also suspect it is actually trying to fetch the Alpha version (or the nightly build). I may be wrong, but please check that.

For a newbie to CP without the tech skills to play with backups and FTP, it could very well put them off, with a bad first impression.

1 Like

Just took a look at the update.php file and saw the following code. I may be totally wrong, but it seems to support what I saw:

// Set the migration build date.
$build_date = ‘20181120’;

// Set $_POST['version'] and $_POST['locale'] with the same
// results from our update data, so that find_core_update will return a
// result.
$_POST[‘version’] = “1.0.0-alpha1+migration.$build_date”;
$_POST[‘locale’] = ‘en_US’;
// Set $_POST['_build_url'] for classicpress_override_wp_update_api.
$_POST[’_build_url’] = ‘https://github.com/ClassyBot/ClassicPress-nightly
. “/releases/download/1.0.0-alpha1%2Bmigration.$build_date”
. “/ClassicPress-nightly-1.0.0-alpha1-migration.$build_date.zip”;

I’m no programmer, so I might be totally barking up the wrong tree.

Hi Graham,

The build you are seeing is the build from immediately before the beta release. It contains the same code and files as the 1.0.0-beta1 release.

We use a build with the alpha+migration version number here so that the site will receive the upgrade to the latest beta release immediately after migration. We’re looking at a couple of options to make this work more smoothly, but there are some challenges. Among them: the version of ClassicPress used by the migration plugin needs to be a separate build with a different file structure.

As for your other questions, I will reply here shortly, but generally it is better to create a new forum topic for each separate issue or question.

I don’t pretend to understand how these things work. If you think my posts are not helpful, feel free to delete them. I certainly don’t want to give visitors the wrong impression.

It’s after midnight here, so I won’t see any more replies tonight.

We do truly appreciate your posts, as well as you engaging with us, as this conversation will help others who have similar questions/concerns :slight_smile:

We are here if you run into anything else, or if you have any further questions or concerns!

1 Like

I think I see what you mean - it first migrates, then updates. Hence the long time delay when doing it with the plugin, as opposed to simply uploading the files by FTP.

This is mainly due to:

the version of ClassicPress used by the migration plugin needs to be a separate build with a different file structure.

Then the upgrade brings everything back in line with the current Beta build.

Yes, definitely! I didn’t mean to give any impression otherwise. The bit about making separate topics was just a tip so that the questions you ask and the information we give as answers are more easily found by others in the future.

1 Like

Usually this happens when an upgrade fails for whatever reason (timeout or temporary internet connection failure). After the failure, the upgrade process is locked for 15 minutes.

We could add a way to reset this timer, probably in the migration plugin. We need to be careful though, because this update lock serves a legitimate function too.

I see 3 reports of this message above. One was the lock working as intended when it prevented Dick from upgrading the same site two times at once. The other two sound like they were probably errors.

1 Like

Since this is showing to be an issue, wouldn’t it be wise to make this a priority? I know, not that many people may use the BETA version, as with the Alpha version. But a lot of people who do try something are people who spread the word.

Those people pay attention to the steps the migration is taking. I don’t agree that the Alpha version should first be installed and then update to the BETA. It confuses people, very easily. Much like the "Upgrade to ClassicPress label, directly under “Upgrade Network” for multisite.

One thing I know is that whatever steps need to be taken to accomplish the goal, it should be either explained in detail before hand or during the process so that there are no surprises (as much as possible).

It isn’t coming across as “smooth”. IMO

That’s fair. I also think where we are is fair considering that we’re still in the beta release stage.

The easiest thing to do about this (which is not a permanent solution) is to update the build used by the plugin to one like 1.0.0-beta1+migration.20181122. I’ll be doing this sometime in the next few days.

I just “RE-upgraded” my production site, http://rotcodzzaj.com I encountered NO ERRORS this time, and EVERYTHING appears to be working properly… just letting y’all know


Depends on what level you want others to think we are operating at.

I realize it is a lot of work, but do we really want to give others the weapons they need to point out things aren’t really going smoothly, and that it is okay because we are just testing?

When I write something (coming VERY soon), should I give that as a quote?

1 Like

I guess you can if you want, but pointing out that “a beta release has some rough edges” feels a bit dismissive of the hard work we’ve been putting in.

We are finishing the many tasks needed for our final release, and as part of that, we are actively looking for and implementing ways to make the experience smoother.

If you or anyone else are experiencing an issue or inconvenience with ClassicPress, the best thing you can do is report it so that it’s on our radar, as you’ve done here.

I haven’t experienced ANY problems with CP, on both my test site and my production site