Once the Knowledge Collector was capable of producing a normalized Knowledge Object, a second architectural problem became obvious:
How should that knowledge actually be rendered?
Historically, every page type answered this question independently. Search pages rendered one way. Taxonomy archives rendered another. Portal pages contained their own loops, while directory pages often implemented entirely separate presentation logic.
Although these pages displayed nearly identical information, each maintained its own rendering pipeline.
The Presentation Engine was introduced to eliminate this duplication.
The Problem
Traditional WordPress templates often combine three responsibilities:
- Collect data
- Organize data
- Render HTML
This works well for small projects, but becomes increasingly difficult to maintain as additional content types and presentation layers are introduced.
Before the migration, every major page contained its own variations of code like:
WP_Query
↓
Loop Posts
↓
Switch on Post Type
↓
Load Template
↓
Render HTML
Although the implementations differed slightly, they all repeated the same overall workflow.
The New Pipeline
Instead of allowing every page to build its own rendering process, the project introduced a dedicated Presentation Engine.
User Request
│
▼
Knowledge Collector
│
▼
Knowledge Builder
│
▼
Presentation Engine
│
▼
Presentation Templates
│
▼
HTML
Each stage performs exactly one responsibility.
Single Responsibility
Knowledge Collector
- Discovers content.
- Queries WordPress.
- Groups related objects.
Knowledge Builder
- Normalizes the collected information.
- Creates sections.
- Calculates metadata.
- Builds the final Knowledge Object.
Presentation Engine
- Iterates sections.
- Selects templates.
- Delegates rendering.
Templates
- Display HTML only.
- Contain minimal business logic.
- Remain reusable.
The Knowledge Object
Rather than accepting arbitrary variables, the Presentation Engine accepts a single normalized object.
$knowledge = kp_collect_knowledge([
'post_id' => get_the_ID(),
]);
kp_render_knowledge($knowledge);
This becomes the entire interface between data collection and presentation.
Templates no longer care where the information originated.
Rendering Flow
Knowledge Object
sections
│
├── books
├── songs
├── quotes
├── excerpts
├── movies
└── artists
↓
foreach section
↓
Resolve Template
↓
Render Section
↓
Next Section
Notice that rendering now becomes completely data-driven.
The Section Renderer
Rather than writing presentation logic inside every page template, a dedicated renderer loops through the available sections.
Conceptually, the renderer performs something similar to:
foreach ($knowledge['sections'] as $type => $section) {
resolve_template($type);
render($section);
}
No page-specific knowledge is required.
Template Resolution
Each content type owns its own presentation template.
books
↓
template-parts/grids/book.php
songs
↓
template-parts/grids/song.php
quotes
↓
template-parts/lists/quote.php
The Presentation Engine simply resolves the correct template and passes the normalized section.
The template itself is unaware of where the data originated.
A Layered Architecture
Presentation Layer
Portal
Search
Taxonomy
Directory
Future Views
──────────────
Presentation Engine
──────────────
Knowledge Builder
──────────────
Knowledge Collector
──────────────
WordPress
Each layer depends only on the layer immediately below it.
This dramatically reduces coupling throughout the project.
Why This Matters
Suppose a new presentation type is added in the future:
- REST API
- JSON export
- Interactive visualization
- Knowledge graph
- Mobile application
None of these systems need to understand WordPress queries.
They simply consume the Knowledge Object already produced by the collector.
Benefits
- Presentation becomes data-driven.
- Templates remain simple.
- Rendering logic exists in one place.
- Page templates become dramatically smaller.
- Collectors and renderers evolve independently.
- Adding new presentation layers requires minimal engineering effort.
The Conceptual Shift
Perhaps the most important outcome of this migration was a change in perspective.
Instead of thinking in terms of pages, the project began thinking in terms of knowledge flowing through layers.
A Portal is no longer responsible for collecting and displaying information.
It simply requests knowledge, then asks the Presentation Engine to render it.
Search, taxonomy archives, and future systems follow the exact same pattern.
Request
↓
Collect Knowledge
↓
Normalize Knowledge
↓
Present Knowledge
This architecture transforms presentation from a collection of page-specific implementations into a reusable rendering pipeline capable of supporting the entire platform.
Looking Ahead
The Presentation Engine solved one half of the migration by centralizing rendering. However, it exposed another challenge: templates themselves still expected different kinds of input depending on how they had evolved over time.
The next stage of the architecture addressed this compatibility problem through the introduction of bilingual presentation templates capable of supporting both legacy WP_Query objects and normalized card collections simultaneously.