Viewing changes in Gutenberg content

And if seeing these changes inline isn’t a feature of the plugin (definitely should be on the roadmap though) – is there simply an easy way to see what’s changed?

It’s a bit hard to know whether or not to approve something if you can’t see what’s different.

I ended up just doing it myself. Added a metabox that shows all content changes in Gutenberg, but now I’m noticing that approving changes on a revision draft clears ALL revision history for that post??

I guess I have to give up on this plugin. Poor support response for a paid plugin (I messaged over a month ago) and nothing seems to work for a real approval-and-audit-trail case. What a bummer.

Here’s my solution for displaying content changes (if they exist) in a metabox under the Gutenberg editor. Hopefully it helps someone else.

// ADD META BOX FOR CONTENT DIFFERENCES
function content_diff_meta_box() {
  global $pagenow;
  global $post;

  $old_post_id = get_post_meta($post->ID, 'linked_post_id', true);

  if ($pagenow === 'post.php' && $old_post_id) {
    // We're reviewing a revision
    $old_post_content = get_the_content(null, false, $old_post_id);
    $new_post_content = $post->post_content;
    $text_diff = wp_text_diff($old_post_content, $new_post_content);

    if ($text_diff) {
      // Differences exist
      add_meta_box(
        'content-diff',
        'Content Updates',
        'content_diff_meta_box_content',
        null,
        'normal',
        'high',
        array(
          'text_diff' => $text_diff
        )
      );
    }
  }
}
add_action('add_meta_boxes', 'content_diff_meta_box');

// POPULATE METABOX WITH CONTENT DIFFERENCES
function content_diff_meta_box_content($post, $vars) {
  $text_diff = $vars['args']['text_diff'] ?: null;

  if (!$text_diff) {
    // no content changes
    echo "<style type='text/css'>
            #content-diff {
              display: none;
            }
          </style>";
  }
  else {
    // content changes - show diff table
    echo $text_diff;
    echo "<style type='text/css'>
            table.diff tbody tr td {
              width: 50% !important;
            }
          </style>";
  }
}

• This reply was modified 3 years, 6 months ago by martinparets.
• This reply was modified 3 years, 6 months ago by martinparets.
• This reply was modified 3 years, 6 months ago by martinparets.

Added a metabox that shows all content changes in Gutenberg, but now I’m noticing that approving changes on a revision draft clears ALL revision history for that post??

I guess if someone in support DOES see this, if you could just let me know if this is proper behavior or a bug of some kind, I would super appreciate it. I’m not sure why someone would want to clear revisions on a post when approving a change, and if I can get this behavior working properly maybe it can save the plugin and keep me from having to move to PublishPress.

Thank you!

Hello!
Sorry for late response.

Unfortunatelly we are still waiting for Gutenberg team to allow more flexible modifications of content data display.

We understand your frustration. It is indeed on our roadmap, aswell other changes.

“Here’s my solution for displaying content changes”:

– Thank you for an idea. We will take a look at it and try to implement something simillar.

Sorry again. Gutenberg is such a mess, and we are having some troubles working with it.

but now I’m noticing that approving changes on a revision draft clears ALL revision history for that post??

That’s something new. Maybe new updates of WordPress changed way of connecting revisions meta-keys with their parent.

Thanks for notifying us.
We will take a look at it.

New version adds metabox diff display.
Thank you for the idea.

It’s not an actual solution, because it’s ugly, but we are sure it will work for now ??

@themastercut That’s great, happy I was able to help. Do you have any idea why approving a revision is wiping out all revision history? Have y’all seen this before?

@themastercut Ping ??

@themastercut Scratch that – think I got it working properly now. I believe it had to do with what our role permissions were set to.