The standard WordPress theme testing workflow goes like this: install the theme, create a post titled "Hello World," paste in some lorem ipsum paragraphs, check that the font renders and the layout holds, call it done. This approach was always a bit thin, but it worked reasonably well in the Classic Editor era when editors were constrained by a single textarea and could not easily produce complex block structures.
Gutenberg changed that. WordPress 5.0 shipped the block editor in 2018 and it has matured significantly since. Modern editors can now mix heading blocks, list blocks, image blocks with captions, table blocks, quote blocks, cover blocks, code blocks, and group blocks — all in a single post, without writing a line of HTML. The "hello world with lorem ipsum" test completely fails to exercise any of this.
What editors actually produce
If you watch a non-technical editor use Gutenberg for the first time, they will reach for a small set of blocks consistently: Heading, Paragraph, Image, List, and Quote. These are the five core blocks your theme absolutely must handle correctly. After that, the blocks that cause the most layout surprises are Table, Code, and Cover — not because they are commonly used, but because they are the ones most likely to overflow or break when the theme was not designed with them in mind.
The structural problems that appear with real Gutenberg content are predictable once you know to look for them:
- Adjacent headings — editors often stack an H2 immediately followed by an H3 as a sub-heading. The spacing between consecutive headings is almost never tested with lorem ipsum, and the result is usually either too tight or too loose.
- Images at full width — editors set images to "Full Width" or "Wide" alignment when they want drama. Without explicit handling in your theme stylesheet, wide-aligned images will breach the content container and overlap sidebars or other layout elements.
- Tables on mobile — a table with four or five columns looks acceptable at 1200px. At 375px it becomes a horizontal scrolling nightmare if you have not wrapped
wp-block-tablein anoverflow-x: autocontainer. Most default styles do not do this. - Lists without re-applied styles — CSS resets strip
list-styleandpaddingfromulandolelements globally. The block editor wraps list blocks in.wp-block-list, but your theme still needs to explicitly restore bullets and numbering for content inside.entry-contentor equivalent.
The the_content() filter and why it matters
When WordPress outputs post content via the_content(), it passes the stored block markup through a filter chain. Gutenberg blocks emit specific class names — wp-block-heading, wp-block-image, wp-block-table, and so on. Your theme has two options: target these classes directly in your stylesheet, or wrap .entry-content in a selector that applies sensible defaults to bare HTML elements regardless of what classes Gutenberg adds.
Both approaches work, but the second is more resilient — it means your content area handles HTML regardless of whether it came from Gutenberg, the Classic Editor, a REST API import, or a migration from another platform. The key is to test it with HTML that exercises all the elements you care about, before you assume your selector covers them.
Building a realistic test fixture
The most effective approach is to build a dedicated test post in WordPress that you keep permanently in draft, updated whenever your content requirements change. The post should contain every block type your editors use, in realistic combinations.
Generate a structured HTML block with all the elements you need — headings across multiple levels, ordered and unordered lists, a figure with an image and caption, a blockquote, a table with header rows — and paste it into a Classic Editor Custom HTML block or directly into the block editor via the HTML editor. This gives you a stable baseline for CSS development that you can return to after every significant stylesheet change.
The payoff
The time investment is about twenty minutes — generate the fixture, paste it in, check each breakpoint. That is significantly less time than a round of client revisions after the first real post breaks your layout. It is also less embarrassing than explaining to a client why their carefully written table does not display correctly on mobile, three days after the site launched.
WordPress is remarkably flexible and Gutenberg gives editors genuine creative control. The flip side of that flexibility is that your theme needs to be equally prepared. A single structured test fixture, checked into your project and used consistently, is the most straightforward way to get there.