Support » Fixing WordPress » Too many interruptions editing HTML

  • Is there a way I can use “Edit as HTML” and not have Gutenberg interrupt me and prevent me from doing it? Here is today’s example of the frustration:

    1. I was working on a Paragraph block that contained an inline image – a YouTube logo to go next to a link to a video (as far as I can tell, direct editing of the HTML is the only way to include an inline image).
    2. I was in the middle of typing a style attribute and had not gotten to the closing quote yet. I wanted to reference something in my theme’s style.css file that was open in a text editor, so I switched focus to that window.
    3. When I switched back to the browser, my in-progress work had been interrupted by the dreaded “This block contains unexpected or invalid content”, with several undesirable choices of what to do about it.
    4. I selected “Resolve” and copied the current code to preserve it, closed the popup, clicked the standing ellipsis, and selected “Attempt Block Recovery”. I was presented with an empty block, because I guess WP considered ALL the code unworthy.
    5. I selected “Edit as HTML” again, pasted my saved code back in, and resumed my work.
    6. After finishing writing inline styling (which was style="width:80;margin:3px 10px 0 0" – that’s relevant), I did a Preview (not Update, just Preview), but then decided I would rather put the CSS in my style.css file. So I switched again to the text editor window and made the change.
    7. When I went back to WP, I started to remove the style attribute from the block, and was interrupted by a smaller popup trying to “help” me with the CSS I was trying to remove – I can’t recreate this behavior so I don’t remember for sure, but I think it said the Width was 8031000 (a lumping together of all the numbers in the style attribute) and offered an Edit button to change it. That popup partially blocked the part of the code I was trying to remove, so I couldn’t see what I was doing.
    8. I don’t remember exactly what steps I did after that, but at some point the block editing area was completely replaced by a message: “This block has encountered an error and cannot be previewed.” I’m not trying to preview anything – I’m trying to edit! Perhaps it coincided with an auto-save, since I still had a Preview tab open – I don’t know. Anyway, once that happened, I couldn’t get to the code – block controls are there, and I can switch between “Edit visually” and “Edit as HTML”, but nothing changes. I had to create a new block and start over with the code I had copied a long time before.

    Interestingly, in Preview, even the block that WP says can’t be previewed appears and looks fine. Inspecting it with browser dev tools, it appears that what was left after my attempt to remove things hidden under the width editing popup was st"="" – naturally that’s junk, but there is no opportunity to fix it.

    Why is WordPress messing with me when I’m in the “Edit as HTML” mode, and have not tried to preview, save, or even switch back to “Edit visually”? It should patiently wait and not try to analyze my half-written code and “help” me. Any tips for how to do this kind of thing without fighting WP are appreciated. Surely I don’t have to flee to a text editor.

Viewing 3 replies - 1 through 3 (of 3 total)
  • There actually is an icon in the toolbar for inline images. At first I couldn’t see it either. It does have a width option.
    The problem with the block editor is that it limits blocks to known attributes, and will balk at other HTML attributes that you may want to throw in there.
    One way to get around this is to use the Classic block for things that you need to tweak.

    Perhaps you can copy this into an issue in the Gutenberg repository, so it can be addressed?

    Thread Starter OsakaWebbie


    Thanks, Joy. I’ll check out the inline image icon the next time I need to do that. But that’s a side topic to my main question here. In this particular case I was fine-tuning code that I include in a block template, so the basic image inclusion had already been done.

    Does the Classic block act differently in terms of syntax checks? I don’t know what triggers the check (I originally thought it was switching focus, but now I’m thinking it’s more likely to be happening when the post is autosaved), but my issue is that WP should not prevent me from simply continuing to edit the raw HTML I’m working on. Or is the Custom HTML block more “hands off”?

    And what causes the second error I encountered? The first one (“This block contains unexpected or invalid conteny”) has happened to me many times, but the second one (“This block has encountered an error and cannot be previewed”) was a new experience.

    I hesitate to post on Github until I understand better what is happening and what I can or can’t do about it in my own workflow under the current code. If I’m going to sound like an ignorant doofus, I’d rather do that here. đŸ˜‰ But once I have more clarity about what WP is doing and a solid suggestion about what it should do, I’ll post there.

    The thing is, “WordPress” isn’t doing it. The block editor that replaced TinyMCE is doing it. So while it is part of WordPress, it can be run independently (as incorporated in Drupal, for instance), so this basic problem of checking too soon or the autosave affecting concurrent editing needs to be shouted out so it can be fixed. I have tried, and not gotten very far. They usually say that you shouldn’t be editing the HTML, but the option is there, so it should work! I think they don’t want invalid HTML in the database, even in autosave, but just saying that sounds nuts to me. There was supposed to be some more work done on the block parser, but I don’t think anyone is putting attention there.

    The way the Classic block works: it is used as a fallback for HTML that doesn’t parse as known blocks (I’m not sure if this is only at the initial load). Legacy posts have a single Classic block. But you can add one anywhere. It loads the TinyMCE editor for that block into an iframe, just like the old editor, with its filters and everything. That means themes and plugins can treat it the same as always. The Custom HTML block is not as nice because while it’s in an iframe, it doesn’t have any filters, so the theme can’t load styles for it, and you only see it correctly using Preview.

    what causes the second error I encountered?

    Sorry, I don’t know the code for the editor. I just know that the block parser is not very flexible, and any deviation from expected syntax makes it barf like that.
    The key take-away here is that you and I are not alone in wanting to use HTML mode to make small changes, and the editor should accommodate that. Currently, blocks are HTML, so they should work that way. Later, if they define their own components (like they are for the editor UI), like Wix does, I can understand that only certain markup would be valid.

Viewing 3 replies - 1 through 3 (of 3 total)
  • The topic ‘Too many interruptions editing HTML’ is closed to new replies.