Possible plugin conflict with UpdraftPlus restoration?

  • Resolved Ate Up With Motor

    (@ate-up-with-motor)


    4 years ago

    I had a weird problem yesterday and I’m wondering if it might have been related to a conflict between the latest version of Disable Gutenberg and the UpdraftPlus backup utility.

    Here’s what happened: As summarized here, around lunchtime yesterday I did a database restore on two different sites, both using the latest versions of UpdraftPlus and Disable Gutenberg. The restoration completed without error, but I discovered immediately afterward that a bunch of pages on both had lost their content: The pages were still there, with their titles and slugs, but their content (post_content) was completely empty. It appears to have been only pages, not posts, and it was not all of the pages, although in one case it was about half of them. The pages were definitely not blank at the time I created the backup from which I restored (I had backed up right after updating them earlier that day).

    I don’t know if this is related to Disable Gutenberg or not — as the thread I linked above indicates, I’m kind of grasping at straws, and Disable Gutenberg is the only plugin I can think of that might some kind of issue with actual post content. I never had this problem before; I last ran an UpdraftPlus database backup earlier this week with no issues, although that was a day or two prior to the most recent Disable Gutenberg update.

    Were there any changes in the update that you could envision causing an issue like this? Again, I’m not saying the two are necessarily connected, I’m just trying to explore possibilities because I really don’t want this to happen again! If you have any ideas, could you let me know?

    (Fortunately, because I’m using Disable Gutenberg to restore the Classic Editor, I was able to quickly correct this problem by pasting the HTML for each affected page from offline backups. If I used Gutenberg, this would have been a catastrophe rather than a half-hour annoyance, since I lost my privacy policies and related pages in the restoration and would have had to manually recreate them in the stupid block editor!)

Viewing 14 replies - 1 through 14 (of 14 total)
  • Plugin Author Jeff Starr

    (@specialk)

    Thanks for reporting, but it’s probably not related to DG plugin tbh. DG really only does one thing: it enables the scripts that are required to display the Classic Editor. It has nothing to do with any post content ever. Never touches it. That’s sort of the whole point: whereas Gutenberg makes significant changes to post content, Classic Editor does not.

    But I am open to any possibility. If you can provide steps to replicate your described issue on default WordPress, I will be glad to investigate further asap. Definitely want to resolve any bugs and keep DG 100%.

    Thread Starter Ate Up With Motor

    (@ate-up-with-motor)

    Yeah, the whole reason I DON’T use Gutenberg is that I don’t trust it and I don’t like the extra steps it creates for my workflow. (I’m glad you created this plugin because I’m frustrated that the core team is so oblivious to the damage they’re doing.)

    I’m still investigating and will keep you posted. Like I said, I’m kind of grasping at straws in an unprecedented if rather alarming scenario.

    Plugin Author Jeff Starr

    (@specialk)

    Understood. Let me know how it goes and/or if any further infos, questions, etc. Glad to help answer any questions about DG. Good luck.

    Thread Starter Ate Up With Motor

    (@ate-up-with-motor)

    I’ve been continuing to investigate, and while the posts table is getting backed up correctly, restoring it causes certain pages’ post_content to be erased. The developers of the UpdraftPlus plugin still think it’s some other site component that’s interfering with the restoration of the posts table.

    I keep coming back to Disable Gutenberg because (a) it’s a common component across the affected sites, (b) it’s the only common plugin that interacts with post data at all other than Yoast SEO, and (c) it’s the only one that had been updated shortly before the issue appeared. (The problem materialized on Wednesday; the last time I ran a successful restore was before the 2.3 update, but I think after any of the other potential culprits’ last update.)

    Is there any possibility that the 2.3 changes created some kind of odd issue with WordPress expecting post_content to be handled a certain way (presuming the Gutenberg block editor) and balking weirdly at INSERT INTO queries whose values include Classic Editor-style HTML?

    I apologize for what may be a dumb question that I’m sure betrays my ignorance of the backend of the post editors, but I’m struggling to find any explanation, and the issue means I can’t trust being able to restore a database backup without having some arbitrary percentage of my content being erased.

    Do you have any thoughts or suggestions?

    Plugin Author Jeff Starr

    (@specialk)

    It may be a possibility (although unlikely for previously stated reasons). If you can provide steps to replicate the issue on default WordPress, I will be glad to take a look. If the issue can be consistently replicated, it can be resolved.

    Thread Starter Ate Up With Motor

    (@ate-up-with-motor)

    Question: I am thinking about temporarily rolling Disable Gutenberg back to 2.2 to test whether that has any effect on the behavior I’m experiencing. Does the plugin store anything in the database that would require any additional rollback steps beyond disabling the plugin and replacing the files with the earlier version?

    Thanks!

    Plugin Author Jeff Starr

    (@specialk)

    The plugin options are stored in the database, nothing else. There should be no major issue rolling back, although there may be some differences in the options array. Best advice if you need to roll back for any reason:

    1. Make a backup of your database just in case
    2. Take a screenshot of all your DG plugin settings
    3. Remove DG from the Plugins screen in Admin Area
    4. (Re)install DG fresh from scratch
    5. Reconfigure your options, save changes

    That will ensure no issues with different plugin options, etc.

    Thread Starter Ate Up With Motor

    (@ate-up-with-motor)

    Thanks! Which table are the options stored in? In options? (I ask because the reason I need to experiment with this is that I can’t currently restore database backups without significant data loss. It’s not at all inconceivable that I might have to pull data manually from an offline copy of the database.)

    Plugin Author Jeff Starr

    (@specialk)

    Yeah options table.

    Thread Starter Ate Up With Motor

    (@ate-up-with-motor)

    Okay, I tried rolling back to see if I experience the same issue with version 2.2, and I did, so whatever’s happening does NOT appear to be related to the DG update. Back to the drawing board! Thank you for your input.

    Plugin Author Jeff Starr

    (@specialk)

    You’re very welcome. Best of luck to you.

    Thread Starter Ate Up With Motor

    (@ate-up-with-motor)

    I’ve done some additional testing after going back and forth with the UpdraftPlus developer and my web host. What now appears to be happening is this: After restoring from database backup, the affected pages appear to be blank within WordPress — the editing window for each affected page is blank in both the Visual and Text tabs, showing word count 0 in both. However, looking at the posts table via phpMyAdmin, the post_content fields for those pages is NOT empty, and appears to be present as normal. If I view those pages from the front end, they load normally.

    So, the post_content isn’t actually gone, but something is happening to make it invisible to the editor. Does THAT sound like anything that might be DG-related?

    (I’m sorry to bug you with this again, but I’ve never seen anything like this before, and I’m flummoxed!)

    Plugin Author Jeff Starr

    (@specialk)

    Not really. As mentioned, DG basically is just a script chooser. It never touches any content whatsoever.

    Thread Starter Ate Up With Motor

    (@ate-up-with-motor)

    Upon yet more testing, this is looking like some kind of editor conflict.

    If I run a database restore and then open one of the affected pages with Disable Gutenberg activated, the pages appear to be blank in the editor window, reporting no word count (although their content IS present in the database).

    If I deactivate Disable Gutenberg and enable the Classic Editor plugin (which I reinstalled for testing purposes), I get precisely the same result.

    However, if I deactivate both plugins and open an affected page for editing in Gutenberg, the page content IS visible and can be edited, albeit in the misbegotten block editor rather than the Classic Editor.

    If I then reactivate Disable Gutenberg, the affected page content once again becomes inaccessible through the editing window.

    I’m baffled. It’s like having restored the database causes the Classic Editor (however invoked) to treat certain existing posts as if their content weren’t there, even though it is.

Viewing 14 replies - 1 through 14 (of 14 total)
  • The topic ‘Possible plugin conflict with UpdraftPlus restoration?’ is closed to new replies.