If you have spent years building WordPress sites with Advanced Custom Fields, you already have a mental model of how custom data behaves. You register a field, attach it to a post type, then write the_field() somewhere inside a template file to make it appear. That model is so familiar it stops feeling like a choice — it feels like how WordPress works.
Bring that model into ECM Pro, and it will actively work against you. This is the single biggest reason developers new to Kodezen’s plugin ecosystem abandon ECM Pro within the first hour, convinced it is buggy or incomplete, when in fact it is functioning exactly as designed. This tutorial explains why the ACF assumption breaks down, what ECM Pro is actually doing underneath, and how it blends with WordPress core in a way that changes who can build with it.
The Assumption You’re Bringing With You
With ACF, a custom post type and its fields are two separate layers. WordPress core handles the post type; ACF bolts a field layer on top of it. To display anything, a developer opens a template file and writes PHP to pull each field out and echo it in the right place. Nothing appears on the front end until someone writes that code.
So when an ACF-background developer sets up a post type and taxonomy in ECM Pro, they instinctively go looking for the same thing: a template file to edit, a function to call, somewhere to write the display logic. When they don’t find it — and nothing appears to have “hooked up” automatically — the natural conclusion is that something is broken.
Why That Assumption Breaks Down
It breaks down because ECM Pro isn’t a fields plugin sitting on top of WordPress. It’s a structural builder that registers real post types and real taxonomies directly through WordPress’s own registration system — the same system that powers built-in posts and categories. There is no separate meta layer to bridge. Once a post type exists, WordPress core already knows how to route it: archive pages, permalinks, taxonomy term pages, and the query loop all work immediately, without a single line of custom code.
That’s the mind shift. With ACF, WordPress needs help understanding your data. With ECM Pro, WordPress already understands it — because as far as WordPress core is concerned, it isn’t custom data at all. It’s a proper post type.
Where ECM Pro Data Actually Shows Up
This is the part that trips people up most. ECM Pro doesn’t expect you to write a template. It expects you to build the display inside the Gutenberg block editor itself, using the Query Loop block and native block attributes, which pull post type and taxonomy data in dynamically as you assemble the page visually.
Practically, that means one Single template built in the Site Editor can serve every post published under a given post type, with taxonomy terms displaying automatically wherever you place them — no single-{posttype}.php required, no custom taxonomy template needed. WordPress generates the archive at /{post-type-slug}/ and each taxonomy term archive at /{taxonomy}/{term}/ automatically, because the post type is genuinely public and genuinely registered, not simulated.
One quirk worth knowing early: build and edit this content in the native Gutenberg editor, not ECM Pro’s own Modern UI editor. The Modern UI is convenient for setup, but its taxonomy display has known bugs. The native editor, working directly against the WordPress objects ECM Pro created, does not.
A Real Example From Dynamic ChatBizSol
This is exactly the architecture running on our own tutorial site. We built a Tutorial post type with a Plugin Category taxonomy in ECM Pro, then built a single Site Editor template once. Every tutorial we publish — regardless of which plugin it covers — uses that same template, with the correct category tag pulled in automatically through the block editor.
The plugin category archives, at /plugin-category/{term}/, needed no PHP and no custom archive file. WordPress produced them the moment the taxonomy was attached to a public post type. The only manual work was assembling the layout visually, once.
Why Kodezen Built It This Way
Kodezen’s target user for ECM Pro is not primarily a developer. It’s a site owner or small agency who wants the power of custom post types and taxonomies without hiring someone to write template code every time a new content type is needed. By registering directly into WordPress core rather than layering fields on top of it, Kodezen makes the entire structure visible and editable inside Gutenberg — the interface a non-coder already understands.
The trade-off is real: you lose the fine-grained, code-level control ACF gives an experienced developer. What you gain is a plugin that lets someone with no PHP knowledge stand up a fully structured, dynamic content system using nothing but the block editor. For ECM Pro’s actual market, that trade is the entire point.
More ECM Pro Tutorials
Subsequent tutorials in this series will walk through building a full archive-and-single system in ECM Pro from scratch, including how the Query Loop block reads taxonomy data dynamically. If you’re setting this up on your own site now, ChatBizSol offers hands-on setup support for exactly this kind of Kodezen configuration work.