Come on a journey with me as I – a software developer with 25 years experience and more than 10 years of specific WordPress experience – dive into old WordPress theme code, find myself in an enormous tangle, and question my own competence.
As I’m writing in WordPress again I decided to fix the annoying issue I have where a blockquote (a “quote block”?) has no styling in the block editor making it indistinguishable from other regular writing, and often ending up with me having multiple blocks nested inside the quote
Step 1: Inspect CSS to see what’s wrong
I started, as you might, by looking at the styles in the browser’s dev tools. Basically, that’s all confusing as hell.
So I opened up a clean new site with nothing else installed to see what was going on. THIS has nice blockquote blocks:
So why can’t I have them too?
Step 2: Research
So what was happening? I didn’t know. It was time to get Googling.
Now, I don’t remember what order I visited all these in, but here is some of what I found.
add_editor_style not working after upgrade to WP v 6.2 – Stack Overflow
This page pointed me at add_theme_support( 'wp-block-styles' ) and add_theme_support( 'editor-styles' ) but wasn’t sure if they were needed or not needed and so I tried toggling them on and off but to no real effect, I don’t think.
There was also something about “removing container queries from my stylesheets”, but I don’t use those, so that’s not helpful.
WordPress 6.0 (add_editor_style) doesn’t load the style.css within the Gutenberg Editor – Stack Overflow
This thread had some of the first thread’s information, but also had add_editor_style( 'style.css' );
Probably not quite what I wanted, but it caused me to search my code for editor styles, and I couldn’t find anything.
classic theme using theme.json dont show styles in the block editor – WordPress Support Forums
This didn’t help directly, but pointed me at theme.json – did I need one of those in a classic theme to trigger some styles to be added?
Let’s go check the docs for theme building.
Your First Theme – Theme Handbook
https://developer.wordpress.org/themes/classic-themes/your-first-theme/
I want to screengrab this so that you don’t think I’m stupid. This page is in the “Classic Themes” section and has a URL with /classic-themes in it…
OK, so yes, yes, it says at the top: “This section is for a block theme”. But seriously, who reads above the fold when you’re looking for the real meat of a documentation page?
This page seemed to suggest that I needed a theme.json file. So, well, it can’t hurt. I made one to see what happened.
And… well… something happened, but it wasn’t quite what I expected…
It’s all serif and small now. But I can see the blockquote block! It was a tiny bit better. And if I toggled some of the add_theme_support stuff I could even get some extra styling!! Woo!!!
So, we found out some things. But not much.
This research was fruitless. It was time to go all-in!
Step 3: Disable all the plugins… of course!
Time to do the WordPress equivalent of turn-it-off-and-on-again! I fired up my local copy of the site I was working on and turned off loads of plugins a few at a time to see what happened.
Nothing happened.
Well… part way through I noticed something.
I was still inspecting the CSS for changes, and a wild iFrame had appeared in the block editor’s markup!
Where did that come from?
More research led me to the very helpfully-titled GitHub issue “When does the Block Editor get iFramed?” where swissspidy aka Pascal Birchler (I MC’d him onto his first WordCamp talk you know!) explains:
From what I’ve heard, the editor is iframed if there are no classic meta boxes added by plugins and if all registered blocks need to use the latest apiVersion 3
Oh gah, now I’m trapped inside a quote block again!!!
Phew, I escaped.
So how was I to know if all my registered blocks are apiVersion 3? Or even what all my registered blocks are and what registers them?
Sounds like ideal plugin territory.
But a bunch of searches turned up nothing (seriously?). So I was grepping code. But by this point I couldn’t be bothered. So it was back to turning plugins on.
And, apparently, and surprisingly, GravityForms seems to use old block technology and reverts the block editor to using not-iFrames.
So that’s weird and interesting. But you know what? The presence or absence of an iFrame seemed to make no difference whatsoever.
Step 4: Back to the start
So we’ve got incorrect docs. A way to make an improvement but that also makes some other things worse. And some leads to something that might be something.
All vague, unhelpfull, woolly stuff. How hard can it be? And why are the defaults so terrible?
I THINK the next move is just to make my own editor styles. Or make a hybrid theme. Or… oh why is this so hard?
Fränk Klein seems to have me covered.
Perhaps I’ll report back.
In the meantime, I’m gonna stick to plugins, APIs, and complicated back-end algorithms. They make much more sense.