Future UWindsor: the recruitment platform I built.

My project · 2023–2025

I owned the experience from content model to production delivery.

Future was where prospective students met UWindsor's programs, people, requirements, events, application guidance, and first-year planning. I was responsible for making that experience useful—and for making the machinery behind it understandable enough to maintain.

My official title was Web Designer and Developer — Job #359, Classification VI. The work crossed product and interface design, content strategy, full-stack engineering, structured data, accessibility, analytics, integrations, infrastructure, deployment, recovery, production support, and contributor leadership. I did not hand those responsibilities from one specialist team to another; I carried continuity across them.

40% Website and online

Recruitment web content, copy, media, microsites, responsive compatibility, social channels, and an editorial calendar.

20% Collaboration

Coordinate with recruitment, communications, faculties, technical teams, and service providers; advise on web marketing and user experience.

15% SEO and analytics

Keyword work, search optimization, campaign measurement, Google Analytics, Eloqua, reporting, and trend analysis.

15% Marketing campaigns

Contribute to online advertising, maintain current marketing practice, and support recruitment planning.

10% Other duties

Related promotional and institutional work assigned as needs changed.

Those percentages describe the 2018 role baseline I inherited, not a ceiling on the work. I continued the creative, editorial, campaign, and stakeholder responsibilities while building and operating the platform that made them sustainable.

The transformation

From isolated recruitment pages to one institutional content system.

I inherited an Eloqua-era estate built from campaign pages, shared HTML fragments, copied program material, page-specific scripts, and several experiences that had become difficult to update safely. Plan Your Program alone carried its program plans and course descriptions inside a roughly 1.35 MB JavaScript file. Program information was repeated across hundreds of fragments. Recruiter and international content lived in separate page material. Seasonal changes meant editing implementation details instead of maintaining institutional records.

I preserved that estate first, then replaced its fragile boundaries with a WordPress application designed around the information UWindsor actually manages: programs belong to faculties and levels of study; programs connect to courses, requirements, specializations, staff, testimonials, and related programs; course records carry their own code, subject, and description; plans connect a program and intake term to required and recommended courses; staff connect to programs, faculties, locations, and territories.

That relational model gave the website a centre of gravity. The program archive, individual program pages, course-description directory, Plan Your Program, recruiter directory, international regions, and update workflows could present the same maintained records in forms appropriate to each student task. Editors changed content in WordPress. Components and focused Vue applications handled interaction. Release history, import/export tools, and recovery systems made change reviewable.

Earlier work remains credited. Bradd Bezaire's portfolio documents the Future Students experiences that predated my employment. I do not claim that implementation. My work began in 2023 by preserving the inherited estate, then building the active WordPress platform described below.

Still serving students · August 2026

The platform remains visible in the public experience.

The current site exposes 176 program routes, 12 structured application processes, 64 event routes, nine faculties, international territories, staff profiles, course information, planning guidance, and the supporting taxonomies that connect them. Programs and planning pages still load the later component architecture and its focused application chunks.

That continuity matters to me. The repositories were handed off in 2025 and the institution controls what happens next, but the public service still demonstrates the core product decision: structured institutional information rendered into focused student journeys, rather than independent campaign pages pretending not to share the same data.

Platform at a glance

The result was broad, shipped, and maintained.

13 institutional repositories

A connected application, publishing, integration, recovery, and delivery estate.

830 / 872 current-theme commits

Repository-attributed authorship in the principal WordPress platform theme.

176 / 199 pull requests opened

With 184 merged overall and reviewed contributor work integrated into the platform.

67 release tags

A sustained 1.x through 3.6 release history rather than a one-off redesign.

15 · 26 · 7 content types, field groups, taxonomies

Structured publishing foundations, with the content types and taxonomies available through WordPress REST.

77 · 11 PHP and Vue components

Server-rendered presentation plus focused interactive application surfaces.

4 versioned public export routes

Program and admission-requirement data in CSV and XLSX, sourced from the maintained WordPress records.

Apache · PHP-FPM production web stack

Redis, caching, PHP runtime configuration, TLS, security, backups, monitoring, and delivery operated directly on DigitalOcean.

36,536 reviewed tracked source lines

Across 256 PHP, Vue, JavaScript, and SCSS files in the handoff theme snapshot; excludes lockfiles, built CSS, minified, vendor, and archived code.

2,799 structured course records

Extracted into 130 JSON datasets with accessible web and print uses.

14 · 368 · 176 live sitemaps, URLs, and program routes

August 2026 public observation of the later WordPress estate; current scale, not a claim of post-handoff authorship.

Built with contributors, technically owned by me. Students or temporary contributors submitted work under my mentorship; I reviewed and integrated accepted changes. I remained the sole staff developer responsible for architecture, releases, production continuity, and the maintained whole.

The connected content model

Maintain the relationship once. Use it everywhere it helps a student.

The most important change was not visual. It was deciding that programs, courses, people, faculties, application paths, territories, and events were durable institutional records—not paragraphs trapped inside whichever page happened to need them first.

WordPress and ACF gave editors an understandable place to maintain those records. Fifteen content types, 26 field groups, and seven taxonomies expressed the relationships. A Program could connect to its faculty, level of study, admissions information, benefits, career paths, related programs, staff, testimonials, Plan Your Program terms, and Course records. A Course could carry its code, subject, title, and description once, then appear in a searchable course directory, a program page, course sequencing, or a planning guide.

The rendering layer turned that model into useful experiences. Seventy-seven reusable PHP components handled server-rendered structure; 11 focused Vue components added interaction where it materially helped—program filtering, planning, course discovery, staff directories, calendars, territories, and other bounded tools. PHP prepared explicit data payloads from WordPress; Vue did not become a second content store.

This architecture also gave operational work a proper place. Import and export tools could move structured records. Moderated update forms could route corrections to review. Tagged releases could describe a real product change. Backups and recovery could preserve a coherent system. The website stopped being a collection of pages and became a maintained publishing platform.

System 1 · Programs archive, search, and 176 program routes

Programs became the heart of the platform.

I replaced hundreds of shared campaign fragments and dozens of independently maintained landing files with structured Program records. Identity, faculty, level of study, admissions, highlights, outcomes, careers, benefits, requirements, testimonials, staff, related programs, specializations, and course sequencing could all be managed as parts of one program—not copied into a new page every time the institution needed a different view.

Forty-two maintained program source files—6,748 lines in the handoff snapshot—compose those records through focused PHP and Vue components. The 943-line listing application provides search, hierarchical faculty and level filters, removable filter feedback, URL state, sorting, page sizing, and pagination. CSV and XLSX exports gave colleagues another way to review the institutional inventory.

The same model supported rich individual pages for undergraduate and graduate programs, specializations, language requirements, statistics, careers, faculty relationships, admissions, and course sequencing. Computer Science and its Software Engineering specialization became the deepest implementation of the model; Nursing and Business programs demonstrate that the architecture could serve very different academic contexts.

The live Programs experience now exposes 176 program routes through the maintained WordPress application.

System 2 · Plan Your Program

From 21,997 lines of embedded data to a relational planning tool.

The inherited Plan Your Program put program plans, required courses, recommendations, and course descriptions inside a roughly 1.35 MB JavaScript file. Updating a term meant finding a program in source, changing shared semester and year values, editing application code, and preserving another timestamped copy. It worked by carrying the content inside the interface.

I reversed that relationship. Each Program record gained maintainable Plan Your Program entries with status, term, notes, required-course guidance, and relationships to the relevant required and recommended Course records. Faculty relationships came from the Program itself. Course titles, codes, subjects, and descriptions came from the Course records also used elsewhere on the site.

An 88-line PHP boundary now selects published undergraduate programs and active plans, resolves their faculty and course relationships, and prepares the data the browser needs. A focused 487-line Vue component handles search, faculty filtering, program selection, keyboard-operable expansion, and course disclosures. The content remains in WordPress; the application remains an application.

That made seasonal work governable. Import, export, cleanup, and migration tools could move and review plans without rewriting the interface. A course correction could flow into Plan Your Program and the program's own sequencing views through the same record. The live planning guide remains the clearest public demonstration of that shift.

System 3 · Course descriptions, audit, and print

Course information became shared infrastructure.

I digitized the course audit into 2,799 structured Course records with maintainable codes, subjects, titles, and descriptions. The surrounding pipeline covered 107 program-specific course files, academic-calendar extraction, 130 generated JSON datasets, and comparison reports for annual changes.

Those records were not built for one page. Program pages relate directly to Course records for course descriptions and sequencing. Plan Your Program relates active terms to required and recommended Course records. The public directory queries the same WordPress content and prepares it for search by subject, code, level, title, faculty, and description.

The 369-line Course List component replaced table-bound interaction with card-based, keyboard-operable disclosures. Roughly 190 linked disclosure controls and 234 course-offering markers made the audit navigable on the web, while dedicated print styles made it useful in meetings, review, and physical distribution.

The live Course Descriptions experience shows the public side of a much more important systems decision: courses became reusable content instead of duplicated text.

System 4 · International regions, recruiters, and staff profiles

Recruitment ownership became structured and discoverable.

I moved recruiters out of copied domestic, international, and archived HTML fragments and into Staff records with profiles, affiliations, locations, faculties, support areas, contact information, and bidirectional Program relationships. A 380-line Vue directory and focused PHP components turn those records into archives, profiles, support views, and program-level connections.

Territory records provide the content model behind the /international/ namespace. Supporting country and region data can connect ISO regions, recruitment officers, and WordPress content through a focused application rather than burying geographic responsibility inside a campaign form.

The result is visible in the International hub, its regional children, and the Student Recruiters experience: students can enter through geography, program, or person without the institution maintaining three unrelated versions of the answer.

System 5 · Program and staff update requests

A public page needed a governed path back to its owners.

A structured platform needs a structured correction path. I developed moderated Program and Staff Profile update workflows so faculty and domain experts could identify the affected record, describe a bounded change, and send it through review without receiving unrestricted production access.

This completed the publishing loop: a public program or profile had an identifiable content owner, a purpose-built request surface, a review boundary, and a maintained record on the other side. The live Staff Profile Update and Program Update pages continue to expose those structured workflows.

System 6 · Application paths and Next Steps

Admission guidance became a reusable application-process model.

Domestic, international, undergraduate, graduate, faculty, and campaign pages all needed dependable application guidance. Maintaining separate timelines and page-specific filtering code guaranteed drift.

I created an Application Process content type with structured steps, application types, cycles, audiences, and dedicated archive and single templates. The platform could now express a student's path once and reuse it across Future, central University, faculty, graduate, and international journeys without pretending those audiences were identical.

The current site exposes 12 application-process records and a maintained Next Steps experience built inside that later WordPress system.

System 7 · Open House, events, calendars, and activities

Open House became part of a reusable event-publishing system.

I built structured Event records, archive and detail templates, activity and Program relationships, sessions, repeating dates and locations, audience fields, calendar output, legal content, and keyboard-accessible interaction. Open House no longer needed to be an isolated campaign implementation; it could use the same maintained event language as the rest of recruitment.

The platform grew through releases: event archives and single-page components, then repeating events, corrected filters, program and activity relationships, calendar work, and accessibility refinements. The current sitemap exposes 64 event routes, including current Open House activity.

System 8 · REST APIs and governed data exports

The maintained content model could serve people, applications, and institutional workflows.

I made the structured platform available beyond its page templates. All 15 content types and seven taxonomies were exposed through WordPress REST where appropriate. I extended Program responses with faculty, level-of-study, and program-category records, and added query support for program descriptions. The international recruitment interface consumed Staff Member, Affiliation, and Location records from that same API instead of maintaining another disconnected directory.

I also created four read-only endpoints under a versioned uw/v1 namespace. Content teams and downstream workflows could export the published program catalogue or admission requirements as CSV or XLSX, with admission data filterable by applicant type. The exports came from the maintained Program records, so a correction belonged in the content model—not in another manually reconciled spreadsheet.

The distinction matters: these were not demonstration endpoints added to make a website sound technical. They were distribution boundaries around public institutional data. As of August 2026, the live WordPress service still exposes the four custom export routes and its structured Program API.

Design, content, and communications

Engineering never replaced the original craft.

I wrote and maintained recruitment copy, shaped information architecture, designed responsive page and component systems, created and prepared graphics with Adobe tools, produced print and event material, worked with photography and video, maintained captions, supported campaign pages, and helped colleagues translate institutional needs into usable public information.

I also worked across SEO, analytics, Eloqua-era campaign systems, social and paid-media needs, editorial calendars, and stakeholder review. That context mattered technically: the platform had to support the people maintaining it, the prospective students trying to understand it, and the many institutional relationships behind every apparently simple page.

Infrastructure and production delivery

I owned the path from local recovery to the public service.

Production and development were different systems, and I maintained both. On the DigitalOcean production environment, I operated Apache, PHP-FPM, Redis, WordPress and MySQL; tuned the PHP runtime, OPcache, object caching, and page delivery; maintained TLS and security configuration; and owned backups, monitoring, releases, and recovery because the project did not receive central infrastructure support. A fresh August 2026 check still identifies the public service as Apache on Ubuntu, although its post-handoff configuration belongs to UWindsor.

For local development and recovery, I built a custom Docker and Composer stack around WordPress, Apache, MySQL, WP-CLI, phpMyAdmin, Xdebug, and the project's theme and plugins. A purpose-built fresh command restored exported site and database backups, rebuilt theme assets, brought up the environment, preserved earlier working copies when requested, and rewrote environment URLs. A separate backup tool retrieved bounded production and staging exports for controlled local restoration.

I also tested different local web-server arrangements for convenience, debugging, and performance—including PHP-FPM behind Caddy and a Traefik integration. Caddy was local development tooling, not the production frontend. Deployment, restoration, export, caching, and service configuration were maintained product work: I could change the application confidently because I also understood how to recover it, observe it, and move a release into production without treating the server as folklore.

How the platform grew · 2023–2025

A fast trajectory, delivered in deliberate releases.

1. 2023 · taking ownership

   Understand the student journey and the system behind it

   I began with recruitment design, development, content, campaigns, accessibility, SEO, analytics, and stakeholder work, then mapped the fragmented Future estate and designed an information architecture that could carry the whole journey.

2. May 2023

   Preserve before replacing

   I brought the Eloqua landing pages, shared fragments, campaign material, program pages, and embedded-data applications into source control so the team could move forward without erasing what already existed.

3. 2023 · rearchitecture

   Turn pages into a connected institutional model

   Programs, courses, faculties, staff, events, requirements, territories, and supporting content became related records rather than disconnected destinations.

4. July 2023

   Begin the maintained platform release line

   The custom WordPress application gained component boundaries, structured fields, pull-request review, release branches, and version tags so change could be shipped and handed off deliberately.

5. 2023–2024

   Grow from a theme into a product platform

   The 1.x, 2.x, and 3.x releases added structured publishing, reusable PHP components, focused Vue applications, content relationships, update workflows, integrations, and accessibility improvements.

6. 2024–2025

   Make course information accessible and reusable

   I converted the course audit into accessible web and print experiences, maintained 107 program course files, extracted 2,799 course records into 130 datasets, and built change reports for annual review.

7. November 2024–August 2025

   Rebuild program discovery and first-year planning

   Plan Your Program moved from a roughly 22,000-line embedded-data script into related WordPress Program and Course records, server-side preparation, and a 487-line Vue interface. Program discovery became its own searchable, filterable application.

8. October 2024–August 2025

   Turn maintained records into a public data surface

   I extended WordPress REST for program discovery and recruiter data, then added four versioned CSV and XLSX export routes for published program and admission-requirement records.

9. 2023–2025

   Treat recovery and delivery as part of the product

   I operated production Apache, PHP-FPM, Redis, caching, security, backups, monitoring, and DigitalOcean delivery while maintaining a custom Docker/Composer environment for local development, database restoration, export, and recovery.

10. Through September 2025

    Ship through 3.6 and hand off a living system

    I remained the sole staff developer and technical owner while mentoring contributors, reviewing changes, preparing releases, and leaving a versioned platform that could continue serving students.

Technical leadership

I carried the whole while making room for contributors.

I was the sole staff developer and technical owner. I set architecture, maintained the principal implementation, reviewed pull requests, prepared releases, operated production delivery, documented work, and mentored student or temporary contributors. Their accepted work remains theirs; my responsibility was to make contribution possible, review it carefully, and carry the integrated system.

The practical role outgrew its 2018 classification, and my formal re-evaluation was denied. My stewardship of Future later ended through the union bumping process; my employment at UWindsor did not. I moved into Public Affairs and Communications as a Digital Media Specialist supporting the Faculty of Arts, Humanities and Social Sciences and the Faculty of Science. I am currently on parental leave. When I return, people are more likely to see me publishing social media than maintaining Future.

The original title never caught up with the work; the platform, releases, and public experiences are a much clearer description of what I actually did.

About this account

The public story is here. The implementation record is available carefully.

I wrote this from my direct experience, the handoff repositories, release history, and the public site. Counts are snapshots rather than timesheets, and UWindsor may have changed the platform since my stewardship ended. Earlier implementations remain credited to their contributors; this account begins with my 2023 work preserving the inherited estate and building its replacement platform.

I do not publish private source, correspondence, operational identifiers, or personnel records. If a hiring team or serious collaborator needs to examine implementation details behind a claim, I am open to arranging a more private and controlled review.

Résumé-ready summary

The concise version.

• Architected and released a component-based WordPress/ACF/Vue platform across 13 institutional repositories, with 67 tags and a principal-theme record of 830 out of 872 commits.
• Modelled 15 content types, 26 field groups, and seven taxonomies; built 77 PHP and 11 Vue components for recruitment and institutional publishing.
• Replaced a roughly 22,000-line embedded-data Plan Your Program script with structured program and course records, migration tooling, and accessible WordPress/Vue planning interfaces.
• Digitized academic course information into accessible web and print experiences, 130 JSON datasets, and 2,799 structured course records.
• Operated production Apache, PHP-FPM, Redis, caching, security, backups, monitoring, and DigitalOcean delivery; built a custom Docker/Composer development and recovery stack around WordPress, MySQL, WP-CLI, and multiple local web-server configurations.