Systems case · Built beneath two school websites
KayJays and Kiakademie used opposite publishing setups and reached the same failure: course information was typed into pages instead of held as data. I designed the WordPress system underneath both cases so one source can serve people, crawlers and answer engines.
The problem
Both schools had a timetable people could read. Neither had a dependable source of course data that the website, search engines and future publishing surfaces could share.
The entire timetable lives in a self-hosted PHP application, Kursorganizer, embedded through Advanced iFrame. Its schedule content is absent from the page HTML and from structured data: present for people, invisible to crawlers and answer engines.
The mirror-image problem: 26 schedule entries maintained by hand, with class codes that disagreed with the underlying records. Course information lived in page copy instead of in a reusable data model.
STUDIO CLASSES & SCHEDULE · THE FAILURE MODE
At Kiakademie, the timetable sits inside an embedded application. At KayJays, course information was written into pages by hand. The plugin replaces both patterns with connected records and first-party markup.
<div> <iframe src="kursorganizer…"> </iframe> </div> <!-- no class names --> <!-- no times --> <!-- no teachers --> <!-- no structured data -->
<section aria-label="Schedule">
<div>Monday</div>
<span>17:00</span>
<a>Hip-Hop for Kids</a>
<a>Jessy</a>
</section>
<script type="application/ld+json">
{ "@type": "Course" }
</script>The thesis
“Teacher, courses, schedule info should only be entered in the plugin. It should never be manually written on the website.”
Four connected record types—courses, classes, teachers and locations—feed the schedule, course pages, teacher pages and schema from the same source. That shared source is what prevents the surfaces from drifting.
The publishing layer supports both WordPress blocks and shortcodes. Avada Builder pages cannot host blocks, so compatibility with the schools’ existing page system was part of the architecture—not a later concession.
STUDIO CLASSES & SCHEDULE · THE MECHANISM
Four record types are entered once. Every public and internal surface is rendered from them at request time—which is why the schedule, course page and structured data cannot disagree.
STUDIO CLASSES & SCHEDULE · CONNECTED PUBLISHING
The same rule applies to courses, classes, teachers and locations. Each record is a source for several outputs—not merely an entry in the admin. Which outputs are active depends on what each school needs.
course cards · course page · filters · Course JSON-LD
weekly schedule · availability · registration · CourseInstance
team grid · profile · linked names · Person/instructor
schedule · course facts · location references · Place/PostalAddress
The principle underneath is the same for all four record types.
Portrait, role and profile copy come from Putri’s teacher record. The course list beneath them comes from her current assignment—there is no second list for someone to keep in sync.
Public publishing modes
A school can publish the same class records as a detailed list or a compact weekly grid. The visitor experience changes; the source of the course, teacher, time and availability information does not.
Availability, the relevant dates and the sign-up action sit beside the class a visitor has chosen.
The same records become a compact whole-week view for visitors who want to scan and compare first.
Machine-readable outcome
A schedule that previously lived in an iframe or hand-written page copy becomes first-party HTML plus structured data on the school’s own domain. No performance result is implied; the outcome here is a technically legible publishing system.
STUDIO CLASSES & SCHEDULE · THE OUTPUT
Every structured fact is generated from the records at request time, so it cannot drift from the visible schedule. Descriptive prose remains deliberately authored.
{
"@context": "https://schema.org",
"@type": "Course",
"name": "Hip-Hop",
"provider": { "@type": "Organization" },
"hasCourseInstance": [{
"@type": "CourseInstance",
"courseMode": "Onsite",
"courseSchedule": {
"@type": "Schedule",
"startTime": "17:00",
"repeatFrequency": "P1W",
"scheduleTimezone": "Europe/Berlin",
"byDay": "https://schema.org/Monday"
},
"instructor": {
"@type": "Person",
"name": "Jessy"
}
}]
}One node per weekly class, built directly from its related records.
The schedule row and schema read the same weekday field.
A named city timezone rather than an error-prone UTC offset.
A Person node carrying the teacher’s profile; co-teaching remains representable.
Interface studies
These are design studies from the implementation process—not screenshots of live client systems. Together they show how the same records support focused owner, teacher and public experiences.
Availability, staffing, closures and direct edits stay in the context where an owner makes the decision.
Fields are grouped around the owner’s questions, with each field showing where its value will appear.
Entered information and values derived from teaching assignments remain visibly distinct.
A task-specific view for the moments between classes, instead of a desktop table squeezed onto a phone.
The public page derives names, profiles and teaching styles from the same relationships used by the schedule.
Process and governance
Roughly a dozen written specifications defined the records, relationships, publishing behaviour and boundaries before code.
Every specification gets one adversarial plan-review pass, on the version about to be built—not on an amended version that has already moved on.
A second-model review of the specification bundle raised eight findings. Six were real defects, and all six were patched before implementation continued.
The site’s own Plugins page is the source of truth. That rule caught a deploy-log entry describing an upload that had never landed.
Scope discipline
Shelved deliberately. Distribution is not the next problem to solve.
Deferred until a class actually fills and creates the need.
Display parity only. Booking remains in the system the school already uses.
Evidence boundary
In development, running on staging, two committed schools. Nothing is live, so there is no traffic, ranking, booking or conversion claim on this page.
The evidence is the diagnosis, the shared data architecture, the machine-readable output, the review discipline and the decisions that kept the build inside its real scope.