SRAS

A rebuild of SRAS's study-abroad website with a custom WordPress content model, registration-system sync, and destination browsing, alongside a migration of the entire SRAS family of sites to simpler cPanel hosting that cut monthly hosting costs by roughly 80%.

SRAS homepage featuring hero section with heading 'Study the Eurasian Corridor', descriptive text about study abroad programs, two call-to-action buttons, and student photo in snowy mountain landscape
Client

SRAS

Status

Live

Introduction

A ground-up rebuild of sras.org for SRAS, which runs study-abroad, study-tour, online-course and youth programs across the Baltics, the Caucasus, Central Asia and Eastern Europe. Under the new design sits a custom content model: programs, term dates and prices come in from SRAS's registration system through a reviewed sync, destinations form one browsable region → country → city hierarchy, and the site works out for itself which programs are still open for applications. I led the engineering, with my design partner Laurel handling much of the content and template work. I also identified and delivered a hosting migration for the entire SRAS family of sites, cutting monthly hosting costs by roughly 80% while improving the infrastructure.

SRAS Study Abroad Programs page featuring a historic tower building in the Eurasian Corridor, with navigation menu and headline overlaying the architectural photograph

The Challenge

SRAS runs study-abroad, online and youth programs across the Baltics, the Caucasus, Central Asia and Eastern Europe, but its program catalogue lived on its registration provider's site rather than its own. The rebuild brought programs onto sras.org as native pages, which called for a content model that stays in step with the registration data (dates, deadlines and prices), lets visitors browse programs by destination even where a country belongs to more than one region, and stays safe to maintain with AI agents doing much of the day-to-day editing. The wider SRAS family of sites also relied on an expensive legacy VPS that demanded substantial maintenance, creating an opportunity to simplify hosting while upgrading the infrastructure.

The Outcome

Launched Aug 2026

The rebuilt site went live with the new content model, destination hierarchy and program explorer.

Tech Stack

Frontend

  • Gutenberg

Framework

  • OAuth
  • Model Context Protocol

Language

  • PHP
  • JSON
  • Python
  • Markdown

Backend

  • WordPress
  • JSON-LD
  • WP-Cron
  • WordPress Capabilities API

CMS

  • Bricks Builder
  • Advanced Custom Fields
  • Rank Math
  • Relevanssi

DevOps

  • cPanel

Tooling

  • SHA-256
  • WordPress, with every piece of data-model behaviour in a first-party content-model plugin (about 22,000 lines of PHP) organised by domain — locations, programs, events, blog, testimonials and shared services — instead of being scattered through the theme
  • Bricks Builder for templates and page composition, extended with custom query rules, dynamic tags and registered components; Gutenberg for post and program body copy, so long-form content stays portable and editable without the builder
  • ACF for editor fields, with the field groups generated from the content-model manifest rather than assembled by hand in the admin
  • A canonical JSON manifest defining 6 post types, 7 taxonomies, 23 field groups, 24 relationships and 29 integrity rules — the single contract that the docs, the ACF exports and the tests are all checked against
  • Rank Math for SEO, with JSON-LD for programs, locations and events slotted into its existing schema graph instead of replacing it
  • Relevanssi for site search, with a custom indexer for Bricks components: the stock integration only read a field layout that predates components, and captured about 4% of the site's page prose — the replacement captures all of it
  • An OAuth client for the registration provider's admin API, and WP-Cron jobs that keep derived program and event state current
  • Python for the plugin's test suite (800+ tests, including a contract suite against the manifest) and for build tooling: ACF generation, plugin packaging and the legacy-URL redirect workbook
  • The WordPress Abilities API and the official MCP adapter, through a second first-party plugin that gives AI agents a deliberately small, audited set of operations on the live site
  • cPanel hosting for the entire SRAS family of sites, replacing an expensive, high-maintenance legacy VPS
SRAS Study Abroad in Georgia destination page featuring a panoramic landscape of green mountains and ancient cliff-carved monastery with stone staircases, headline text, and navigation menu

Key Implementation Details

Manifest-first content model — The schema is code, and the code is tested against it.

  • One JSON manifest defines every post type, taxonomy, field, relationship and integrity rule; the human-readable schema reference and the ACF import files are generated from it
  • A contract test suite checks the plugin and the generated ACF artifacts against the manifest, so a field renamed in one place and not the other fails the build instead of quietly breaking a template
  • Markdown decision records explain the reasoning behind each modelling choice; the manifest stays the source of truth

One hierarchical Location model — Regions, countries and cities are a single hierarchical post type.

  • WordPress builds /destinations/<region>/<country>/<city>/ URLs natively from the hierarchy, with no custom rewrite rules to maintain
  • Some countries belong to more than one region, which a single parent can't express, so the plugin keeps two mirror taxonomies in sync with the location posts
  • Those mirrors let Bricks' native Query Filters filter programs by region, country and city without a third-party faceting plugin
  • Hierarchy and membership rules are enforced at publish time, and filter-only destinations 301 to their parent and stay out of listings and the sitemap

Programs, intakes and derived eligibility — The lasting offering and each term's logistics are modelled separately.

  • A public program post type holds the offering; private program_intake records hold each term's dates, deadlines and prices
  • Whether a program is publicly open is derived from its intakes, recomputed on every relevant save and daily by cron so nothing goes stale as deadlines pass; program geography is likewise derived from linked locations, ancestors included
  • Bricks query loops are extended with rules the builder UI can't express — "no deadline, or a deadline still in the future", soonest-first ordering, pinned featured programs
  • A visibility change triggers a targeted page-cache purge of exactly the listing pages that program appears on, rather than flushing the whole site

Reviewed sync from the registration system — Program data comes in through a preview-first workflow, never a blind import.

  • An operator builds a change set from the provider's OAuth admin API and reviews every create and update before anything is written
  • The confirmation must echo a SHA-256 hash of the exact preview shown, so a drifted re-fetch or a stale tab can't apply changes nobody reviewed
  • When a program is first created, the provider's descriptive HTML is cleaned and converted into native Gutenberg accordions and registered Bricks components; later syncs touch only source-owned fields, so editors' copy is never overwritten

Events from a provider with no events API — Event listings are read from the provider's server-rendered public booking page.

  • The page returns an empty stub unless the request carries a timezone cookie, so the client sends one up front, and stable event IDs are taken from the booking buttons
  • Events go through the same preview-and-confirm flow as programs, and are only archived — never deleted — when they drop out of a complete snapshot, so one bad scrape can't wipe the listing

Agent-safe editing on production — The site is maintained day to day with AI agents, so the guardrails are part of the build.

  • A second first-party plugin registers 14 scoped abilities through the Abilities API, exposed to agents over MCP: bounded reads, an audited redirect workflow, and a stage-then-finalize queue for Gutenberg edits
  • Finalizing a staged edit re-checks content drift, the post lock and a recovery revision, and verifies the block markup round-trips cleanly before anything goes live — so an agent can't silently overwrite an editor's concurrent change
  • The project repository doubles as the agents' control workspace, with decision records, a task board, site maps and project-specific skills

Hosting migration across the SRAS family of sites

  • Identified an opportunity to reduce hosting costs while upgrading the infrastructure, then migrated the entire family of sites from the legacy VPS to a simpler cPanel plan
  • Reduced monthly hosting costs by roughly 80% while improving security, maintainability, and performance

What I Contributed

  • Designed and built the first-party content-model plugin: about 22,000 lines of PHP covering locations, programs, intakes, events, structured data, search and targeted cache purging.
  • Defined the whole content model as one JSON manifest that generates the ACF field groups and schema docs, backed by 800+ Python tests including a contract suite.
  • Built the preview-first registration sync, with hash-bound confirmation and create-only conversion of imported copy into Gutenberg accordions and Bricks components, plus an event scraper for a provider with no events API.
  • Built the agent-abilities plugin and the guardrails that let AI agents edit the live site without overwriting an editor's concurrent changes.
  • Identified an opportunity to reduce costs and upgrade infrastructure, then migrated the entire SRAS family of sites from a high-maintenance legacy VPS to a simpler cPanel hosting plan.

Outcome

  • ~80% lower monthly hosting costs

    Reduced monthly hosting costs across the SRAS family of sites by migrating from the legacy VPS to a simpler cPanel plan, while improving security, maintainability, and performance.

  • ~350 redirects

    Audited every active legacy redirect at launch and collapsed all redirect chains to a single hop.

  • 4% → 100%

    A custom search indexer for Bricks components took site search from indexing about 4% of page prose to all of it.

  • Programs now live as native pages on sras.org, with dates, prices and availability kept current from the registration system through a reviewed sync.

The rebuilt site launched in August 2026, with the legacy URL set audited on the way: roughly 350 active redirects checked and every redirect chain collapsed to a single hop. Programs that used to live only in the registration provider's catalogue are now native pages on sras.org, kept current through a reviewed sync, and because the whole model is defined in one tested manifest, it can keep growing without the templates drifting out of step with the data.

Across the wider SRAS family of sites, the move from an expensive, high-maintenance legacy VPS to a simpler cPanel hosting plan reduced monthly hosting costs by roughly 80%, while improving security, maintainability, and performance.