Migrating back to CP after server mistake

Support Version 1.x
1

Had site problems (sluggishness, database exports not completing). Chatted with support agent at host, no resolution. He mentioned that he would try to clear some cache in the server. I think he also wanted to check core, files, which is where I suspect he created the problem, thinking it was a WP site.

After leaving the chat, I found that the site was completely down: login page was white, front-end home page was white.

I immediately called support at the host. She mentioned a 500 error, said she could fix it. After 15 minutes or so, she said it was fixed.

But it was not: she had reverted the site to WP 4.9.23. They had no idea that the site was not a WP site.

I uploaded the migration plugin. → Tools → Switch to Classic Press, but got the message:

Sorry, we can’t switch this site to ClassicPress at this time.
Message: Could not communicate with the ClassicPress API server {“status”:“cURL error 60: SSL certificate problem: certificate has expired”}

I don’t know how to fix this issue. I think the same issue on the forum previously elicited this response:

https://forums.classicpress.net/t/error-migrating-could-not-communicate-with-the-classicpress-api-server/3809

Your server is running out of date software and root certificates, see https://github.com/ClassicPress-research/cp-ssl-fix for a workaround.

But I’m afraid this fix may be out of my technical reach. Can anyone help? I would greatly appreciate assistance. The migration plugin is still installed.

Edit: I uploaded the ClassicPress SSL Fix plugin, activated it, and got the third message, namely, that the site is not able to make either of the API-v1 requests. I enabled the 3-minute insecure requests and tried to migrate but got the same messages about being unable to switch.

2

Im not 100% on this!

I think if they have installed a modern version of WordPress in a server system with a built in installer there may be issues as the installer may confuse classicpress with an older version of WordPress.

All depends on what the server is running.

My opinion.

There is no excuse for assuming you were running a standard wp package tho, thats plain ignorance, if that was my server provider they would be in very deep water legally while i put my sites on a new server provider.

1 Like
3

Me think that your best option assuming you have an old backup is delete the mess they made or ask for hosting space reset, install CP again and import the backup.

In the case your host has an old backup, you can ask they restore that.

And be VERY specific in explaining that this is NOT a WP site.

Then lawyer up and sue them because of the damage they made…

4

Your best option might be to manually upload CP files to replace whatever core files are currently on the server. If it’s cPanel, this can be done through File Manager. Otherwise, through FTP client.

With so many variables that may have changed, it’s hard to say what exactly might be wrong.

I’ll be at my desk in a few hours. If you still can’t figure it out, send me PM here.

1 Like
5

Thanks @DepreciatedProgrammer, @ElisabettaCarrara, and @viktor for your quick replies. I have initiated a full restore from the host. Their most recent backup was from yesterday, presumably (and hopefully) before last night’s damage was done. They estimate “24 to 48 hours,” so we’ll see. Otherwise I’ll PM you, viktor (for which many thanks), to see what options remain. BTW I was at CP 1.5.3.

3 Likes
6

Were you able to recover your site from the backup?

7

Thank you @viktor for checking back; much appreciated. I was very fortunate that the most recent backup at the host was earlier the same day as the wreck, so as far as I know I recovered everything + (surprise) the default Twenty-Seventeen WP theme that somehow got thrown into the mix but which I had deleted back in 2019. Go figure.

But the original problem remains (see my first post above), though now it is also impossible to download my public_html via FTP unless I want to wait 20+ (!) hours (previously took 4 minutes). I had a couple more exchanges with the host, whose support has reached an all-time low, and am about to migrate to a new host recommended earlier on this forum. I was planning to report back here when the migration is complete, which I will still do.

Many thanks again for checking back.

2 Likes
8

Make sure you don’t have any large backup files in your public_html, that’s what usually increases size and archiving time unnecessarily.

I would also recommend setting up your own backups to an off-site location, such as Backblaze B2. UpdraftPlus is a good option and is compatible with CP.

Let us know if you need any more help.

1 Like
9

Another vote for UpdraftPlus here!

1 Like
10

Thanks for the suggestions @viktor and @timkaye. I used UpdraftPlus for several years but was unsure how useful the multiple split files would be to someone trying to do a restoration. I eventually had to use very small splits or it would not work.

After that I began exporting the database from phpMyAdmin directly to my hard drive, then saving public_html directly via FTP.

I don’t know for sure, but I don’t think the database export leaves anything on the server, or?

After the public_html is safely on my hard drive, I immediately delete the tar.gz file on the server; so there are no backups in my server account; I don’t know where the host keeps its backups.

Both files, in a dated folder on my hard drive, are then automatically saved to:

the icloud, to Carbonite, to the external Apple G-Drive Mobile time machine, and manually to 2 separate flash drives.

I only keep 2 backups of each, not 3, so after each save I delete the oldest folder, though the Apple time machine always has everything, even the deleted ones, back to, at least at this point, about 2018. So I always have at least the 2 latest saves on my hard drive, on 2 different clouds, and on 3 external devices.

UpdraftPlus also had a peculiar requirement that the site receive a certain level of visitor activity to keep one of its automatic functions running. It nagged me several times about this, but I don’t recall what the function was or is.

So unless I am misunderstanding something, there are never any backups, at least that I have created, on my server.

11

What you’re doing is simply a manual process, which is still good because you have your backups. If you’re happy with it, I wouldn’t change anything.

With UpdraftPlus, depending on your hosting, you may need to split up the files. But the idea is that you will use UpdraftPlus to restore the website from those backup files. So it shouldn’t matter how many smaller files you have for each backup.

The visitor requirement is due to how WP/CP internal cron system works. By default, you need a few visitors daily to trigger the system to run automatic processes - updates, database cleanup, etc. Many plugins schedule their own tasks. Ideally, it’s recommended to set up a cron execution through your hosting provider (usually cPanel). This means the hosting server will run automated tasks at a specific interval (every 10 minutes, for example). This way, you don’t have to rely on visitors for cron to work.

If you’re getting some traffic, you usually don’t have to worry about it.

1 Like
12

I definitely had to split the files several times into ever smaller files to get it to work. Frankly that became a hassle and I was wondering just how small they would have to get.

I understood that UpdraftPlus would also be doing the restoration, but this was also at a time when plugins were beginning to get dodgy with CP, and I was concerned that should UpdraftPlus itself cease functioning (or functioning properly or without workarounds), I would have to solicit a third party to do the restoration, and I could (and still can) easily imagine someone saying something like, “Only the original plugin can restore these split files.”

I have come to prefer manual processes I can control without outside help if possible. I also often need punctiliar backups, i.e., after making perhaps only a few changes to the site but changes that I would prefer not to have to wait for the next scheduled automatic backup. Just grabbing the database manually (or public_html, for that matter) provides a bit of peace of mind.

Thank you for the refresher about the internal cron system; yes, that was exactly the issue. But the hosting provider cannot run a cron job for a plugin, can it, e.g., for UpdraftPlus?

That said, I will check out the new host’s automatic backup and restoration protocol as soon as the migration takes place.

Thanks again.

1 Like
13

This is set up for your entire CP instance. So it works for everything. The built-in visitor-based cron must be disabled, if hosting cron is set up. There’s more info here.

One issue where it does help on low-traffic websites is if you ever had a “Missed schedule” error. When scheduled posts are not automatically published—just FYI. Otherwise, I wouldn’t worry about it.

14

Thank you for the further explanation; certainly something of which I was not at all aware and which might well have solved the problem and might be of use in the future.

Never a dull moment.

1 Like