How we moved a well-known engineering firm to Gutenberg with GeneratePress and GenerateBlocks 2.0, stayed on WP Engine, and used WPCode only where the query layer pushed back.
Our client wanted to leave the classic editor behind and work in the block editor for real—not a cosmetic refresh while shortcodes and old patterns lingered in the background. We proposed a stack we already trust: GeneratePress as the base theme, GenerateBlocks 2.0 for layout and dynamic sections, and ACF Pro where structured fields and relationships still made sense. The goal was to build and iterate without standing up custom application code or a separate repo for this site: theme, plugins, and the CMS doing the heavy lifting.
We host on WP Engine, where daily backups as well as staging and development servers are all part of the safety net. That did not replace good habits, but it did make it easier to experiment with templates and dynamic blocks without pretending nothing could go wrong.
What went well
Setting up GeneratePress to match our design teams Figma theme was a breeze. GenerateBlocks gave us a modern layout surface without dragging the old editor-era baggage forward. Staying inside WordPress—theme, blocks, hosting—kept handoffs simple compared with a full product-style repo and deploy pipeline for a site that did not need custom application logic. No more templates and hard to manage functions files. GenerateBlocks base block replacements for Type, Headings, Containers all surface every imaginable CSS property you might need to adjust, while making it easy to stick to basic spacing and color variables defined in the theme.
Where it hurt: GenerateBlocks Query, ACF, CPTs, and Elements
The pain showed up in the dynamic layer, not in the hero sections.
GenerateBlocks’ Query block is strong when the underlying query is straightforward. With ACF-backed taxonomies, custom post types, and layouts built as single-page Elements (GeneratePress-style templates), we started seeing the kind of issues that depend on context: behavior that was hard to reason about in the block UI alone, or that did not line up with how we needed to filter and relate content in the real templates editors use every day.
That is a familiar WordPress story: not that any one piece is “wrong,” but that the intersection of custom post types, taxonomy registration, template injection, and block-driven queries is where small gaps become visible bugs.
What we did about it: WPCode, with a clear paper trail
We did not want the child theme to turn into a pile of one-off fixes, but we were not willing to fight the editor forever. We used the very helpful WPCode Snippets plugin to add small, explicit PHP and CSS only where the block query layer was the wrong place to solve the problem.
In practice, the snippets fell into a few buckets:
- Query helpers — PHP that builds or adjusts listings so custom post types and taxonomy-driven relationships (including ACF-registered taxonomies) resolve reliably, especially inside single-page Elements where context is easy to get wrong in the block alone.
- Shortcodes where Elements needed field output — We used shortcodes sparingly so single-page Elements could surface ACF (and other) custom field values in places the block UI did not expose cleanly. CTAs and similar repeating UI stayed in the editor via GenerateBlocks patterns.
- Targeted presentation CSS — narrow rules for things like carousel chrome when there are only a few items, taxonomy or archive cards, and simple hover or lift treatments on cards, each with a short comment so the next person knows why it exists.
That kept GenerateBlocks focused on layout and structure.
Closing
Aside from that query-and-template detour, the migration did what we set out to do: a modern block workflow, happier editors, and a stack that stays maintainable without a dedicated application repository—with a small, honest layer of PHP and CSS where WordPress still expects one, and WP Engine covering the rest.
Read more about how we help websites stand out with our Website Design Services.