This week marked the completion of one of the last major Footnotes Engine v2 migrations: the Artist Footnotes subsystem.
Historically, artist rendering consisted of two nearly identical renderers—Featured Artists and Other Artists—that each traversed chapter_songs, resolved artists from songs, grouped songs beneath artists, and rendered almost identical HTML. The only meaningful difference was whether songs were classified as Primary/Secondary or Supporting.
That duplication has now been removed. Both sections are powered by a single shared implementation that performs the traversal once, normalizes the data, and renders both sections through a common renderer. The public rendering API remains unchanged, preserving compatibility with the existing Footnotes Engine.
Collector Integration
The refactor also completed the migration of music references to the collector architecture.
Rather than relying solely on the Chapter’s own chapter_songs repeater, the system now merges inherited Song references collected from attached Elements via kp_build_reference_context(). Any Song referenced by an Element automatically becomes available to the Chapter’s footnotes without additional configuration.
This represents another successful migration from direct ACF field lookups to the centralized collector model that now powers the majority of Footnotes Engine v2.
Architectural Decisions
The implementation also clarified an important architectural distinction between narrative metadata and ordinary references.
- Primary and Secondary Songs remain editorial metadata owned by the Chapter.
- Elements never define Primary or Secondary music.
- Elements contribute only referenced Songs through the collector architecture.
- Artists are derived from Songs rather than authored independently for music footnotes.
This keeps authorial intent separate from inherited knowledge while allowing reusable Elements to contribute supporting music references automatically.
Simplifying the Music Model
One of the biggest architectural insights from this work was recognizing that Songs—not Artists—should be the canonical music object.
Every Song already contains its associated Artist, lyrics, video, artwork, and additional metadata. By inheriting Songs rather than Artists, the system avoids duplicate authoring while naturally producing the correct Artist listings within the footnotes.
Direct Artist relationships remain valuable elsewhere within the platform (Related CPTs, Artist pages, search, and the knowledge graph), but they are intentionally excluded from the music footnote pipeline. This prevents duplicate output while keeping the data model consistent.
Result
- Removed duplicated traversal logic between Featured and Other Artists.
- Introduced a shared artist collection and rendering pipeline.
- Integrated inherited Song references from attached Elements.
- Maintained full backwards compatibility with existing Chapters.
- Established Songs as the canonical music reference object.
- Completed the final major architectural exception within the Footnotes Engine v2 migration.
Current Status
With the Artist Footnotes migration complete, the Footnotes Engine now operates on a consistent collector-driven architecture across nearly every content type. Remaining work has shifted away from footnotes themselves and toward higher-level systems, including Taxonomy Context, Topic and Theme inheritance, and unified Search and Portal rendering.