Some pages wiped in database backup

What I’m going to do next (which I don’t think I have time/wherewithal to do today) is try rolling back Disable Gutenberg to the previous version to see if that affects the behavior I’m experiencing. If not, I will consider doing that — I really appreciate the offer!

Remember, though, that if you restore a backup, then this will also restore the copy of Disable Gutenberg that’s in that backup, so if the problem was in the version that’s in the backup, then changing the version prior to restoring won’t actually change anything post-restore.

My intention is to roll the plugin back, take a backup after that point, and try restoring from there to see if it still triggers the same data loss. If not, that increases the likelihood that the most recent Disable Gutenberg update is somehow responsible. If the same thing occurs, the problem probably lies elsewhere.

I tried the rollback of Disable Gutenberg, ran another backup, did a restore (which I tried twice, once restoring just the database and once restoring the plugin files), and got the same result. This tends to suggest the recent DG update is NOT the culprit, so it’s back to the drawing board.

I’ve reached out to my web host to ask if they have access to any detailed log data and if there have been any recent server environment changes that might affect this issue.

You could try temporarily de-activating *all* plugins. Then it would tell you if it’s due to any active plugin.

Yeah, I’ll need to try that, I think.

It’s a troublesome problem to troubleshoot because each time the issue recurs, it’s a headache to fix each affected page once again. (The problem seems to consistently affect the same set of pages on each site, but I’ll be hanged if I can see why, as there are no commonalities I can think of in age, length, or content.) So, while it might make sense to try it with all plugins disabled and then reactivate them one at a time until the culprit is found, that would be an all-day project.

After some back and forth with my web host’s technical support, we did a test using an UpdraftPlus database backup to restore to a fresh temporary database on the same server, which went off without any issues. So, there’s no MySQL server configuration issues.

I tried running a restore again myself through UpdraftPlus, first disabling all plugins EXCEPT UpdraftPlus. This seemed to have the same result: those seven pages showed as having no content after the restore. The editor window is completely blank for each page and it reports 0 characters content. However, when I went into phpMyAdmin to review the posts table, the content IS there in the post_content field, and the pages load as normal.

I’m mystified.

I tried to see if the affected pages are editable through the Gutenberg block editor, which it turns out they are. If I then activate the Classic Editor (either with the Classic Editor plugin or Disable Gutenberg), the affected pages again appear to be empty in the editing window (although their post_content is still there in the database).

Something about restoring the database is causing certain post content to ONLY be editable through the block editor. That is really strange and is beyond my technical ability to decipher.

What would you like me to do to help you?

I’m not sure, to be honest! The problem is that I don’t know exactly what’s going on — I have no idea what settings or conflicts would cause a given page to be editable in one editor and not in another — so I don’t know how UpdraftPlus may be factoring into that.

(I do really appreciate your help, but this has me flummoxed.)

> the affected pages again appear to be empty in the editing window (although their post_content is still there in the database).

Do you have any JavaScript errors in your JavaScript console when you attempt this editing?

I didn’t see any error messages, although I would have to try again with Inspect Element engaged to be sure.

I mention it because earlier today I was on a site using Classic Editor, and no content appeared in the post editor – because of a JavaScript error in Classic Editor’s JavaScript. But the content was all there in the database. (No backups taken or restored!).

That does sound very much like what I’m seeing, although for me, it’s triggered by restoring. After a restoration, the Classic Editor really does seem to think the affected pages are empty; if I replace their content manually (by pasting the HTML back into the editing window), it overwrites the existing content completely.

• This reply was modified 4 years ago by Ate Up With Motor.

(Also, if I replace the content of an affected page, or open an unaffected post, I can edit it normally in the Classic Editor; the issue doesn’t persist in that case. The problem for me seems to be specific to the editor’s ability to access certain page content following a restore.)