0

Which HTML is better, pre-Gutenberg or post-Gutenberg?

I imported post content from an old and large WP site into a fresh install and new database. Almost 1200 posts along with their meta and related media. The xml file is 15mb. I used the standard wordpress import/export along with a media export [plugin][1] for featured images. The origin site uses tinymce advanced to maintain the classic editor look for the client.

Most everything carried over, but in the new setup, the html of the imported content changed.

Here's how it looked on the front-end. left is origin, right is import.

left=exported front-end, right=imported front-end

Here is how the html changed. Left is the origin. Right is after import.

enter image description here

At what point in the process did the entire content block get wrapped in <p>’s, with <br>’s and &nbsp’s added and original line breaks missing?

Apparently, something about Gutenberg is changing the basic html of post content.

https://wordpress.org/support/topic/gutenberg-does-not-play-nicely-with-code-editor/

https://github.com/WordPress/gutenberg/issues/11211

https://core.trac.wordpress.org/ticket/45636?cversion=0&cnum_hist=1

I was able to fix the front-end paragraph spacing issue with this css courtesy of Themeisle

    br
{   content: "A" !important;
    display: block !important;
    margin-bottom: 1em !important;
}

Even so, I want to know how to best move forward in terms of the html. Is this some kind of bug with Gutenberg or should I just go ahead with the CSS fix? What is the proper html here? if it's wrong, is there some kind of regex magic that would fix it?

update

In response to @tomjnowell, I ran the export with no active plugins and imported it into a fresh installation with no active plugins. Here are the results:

enter image description here

The xml was imported into the blank site. The post content then appears in a Gutenberg "Classic" block in "edit as html" mode with the space between parargraphs removed and br's and nbsp's added. BR's do not appear in the database, but nbsp's do.

Here is another comparison showing from left to right, the XML, the origin db and the destination db. Also, I noticed the following differences between the databases. Not sure if it matters.

Origin db post_content has as type: MyISAM with collation set as: latin1_swedish_ci

Destination db post_content has as type: InnoDB with collation set as: utf8mb4_unicode_520_ci

enter image description here

  • Can you compare DB to DB rather than post content to DB or some other combination? The act of displaying post content in an editor changes it – Tom J Nowell Nov 10 at 23:23
  • Also &nbsp; is necessary as HTML won't display 2 spaces in a row, they collapse into eachother, otherwise your page would be full of the whitespace indenting of tags. Otherwise your final comparison looks correct – Tom J Nowell Nov 10 at 23:24
  • @TomJNowell - I added an image showing the differences between the origin and destination db's. Also noted differences between type and collation settings between the two. – Ted Nov 11 at 19:17
  • If this happens on a fresh unmodified latest WP, with the standard importer exporter, then I'd suggest you raise this as a bug on the main WP bug tracker/Trac. Unless you're opening these posts and saving them to change their HTML, this won't have much of anything to do with the block editor, as the only thing touching it will be the importer/exporter plugin – Tom J Nowell Nov 11 at 21:01
0

Gutenberg is an editor, it's not an active process that runs in the background.

Think of it this way, a PDF is a PDF, it's content, data. If I create it with one application, then copy it to a machine that has a different PDF reader, the PDF is still the same. To modify it I would have to open the PDF in an editor and resave it.

The same is true of Gutenberg. Unless you open a post in gutenberg and press save/publish, there are zero opportunities for Gutenberg to make modifications.

Try to imagine what would be involved for Gutenberg to actually do this. It would need to update every single post in the database, track what it had and hadn't modified, and it couldn't do this in a single request, it would have to continuously poll itself until the job was done, creating major server load.

So what can you do?

First, do a standard WP export, without any additional plugins interfering or meddling.

Second, check the markup in the wxr and see if it has the same content or if it's been modified.

Third, import the data, and check the markup in the database, not the editor/frontend.

Fourth, do all of the above with the standard default themes and no plugins.

Put simply, there is no evidence Gutenberg is at fault ( there's no evidence of what is at fault, the cause is currently unknown ), and Gutenberg doesn't work that way.


As a final note, what you're referring to is not normal content, and those aren't paragraphs. Those are TinyMCE Advanced "classic paragraph" blocks, and they may not work the same way. For example, it might be that how the content looks and what the actual HTML is are not the same.

I'd suggest making sure TinyMCE Advanced is also installed on the target site. Otherwise you should ask for TinyMCE Advanced support at the TinyMCE Advanced support forum

  • Thank you for that feedback and explanation. I'm going to consider what you said and look closer into the role of tinymceAdvanced. – Ted Nov 9 at 1:23
  • I took your suggestions and updated the post at the bottom with screenshot and description. @tomjnowell – Ted Nov 10 at 20:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.