Nine-site WordPress Multisite platform with Impexium SSO

I rebuilt the system as a reusable WordPress Multisite platform supporting nine institute sites from a shared theme and codebase. Each site used the same theme and core components. Editors could change institute-specific details such as the logo, primary brand color, images, and page content using WordPress blocks, while the underlying templates and functionality remained shared. The visual system was intentionally constrained so a bug fix or feature improvement could generally be made once and become available to the entire network. The shared architecture also allowed child sites to use content from the parent site — for example, a custom ACF block that queries the latest podcast published on the parent site and displays it across the institute network automatically.

The most complex part was extending the agency’s existing Impexium OAuth plugin. Impexium already returned the membership information required for the project, but the plugin did not yet support the institute- and class-level attributes we needed. I extended its field-mapping system so additional OAuth attributes could be configured and consumed dynamically, making the integration reusable rather than hard-coding a single new Impexium field. When a visitor reaches protected content, they are redirected to Impexium to authenticate. On successful login, WordPress evaluates the returned attributes to determine access. If the user does not yet exist in the Multisite network, their account is created during first login, then provisioned onto the appropriate child site using institute and class information from Impexium. Each class year has its own WordPress role, used with the site’s content-protection tools so participants can access resources intended for their class without exposing another class’s materials. Full organizational members follow a separate branch of the authorization logic and receive broader access. Impexium remains the source of truth throughout.

Protecting the WordPress page itself was only part of the problem. Course materials frequently included PDFs and other files, so restricting a page while leaving its underlying file URL publicly accessible would not have been sufficient. The implementation uses role-based page restrictions alongside file-level protection: the WordPress Members plugin controls access to protected site content, while Prevent Direct Access protects the underlying course documents. Class-specific roles created during SSO provisioning govern both the interface users see and the resources they are permitted to download.

Legacy course-material pages had been constructed manually — editors created rows one at a time, added links by hand, and maintained heading levels, formatting, and visual consistency themselves. I replaced that with a structured ACF-based content system. Editors now populate fields for session title, presenters, date, and materials; repeater fields allow multiple sessions and materials while the theme handles presentation automatically. For institutes that already had legacy course materials, I also built a migration process: scraped the existing pages, normalized inconsistent HTML structure, and wrote a script that transformed that material into the new structured field format.

The platform also uses Impexium for institute-specific data outside authentication. Institute leadership is pulled from Impexium on a nightly schedule and rendered dynamically on the appropriate site — a scheduled synchronization rather than a real-time request, because that data does not change frequently enough to justify a live API dependency on every page request. I also built a separate Gravity Forms integration that automated part of the organization’s institute application workflow: an existing member can submit a nomination form, which creates a draft application and carries selected nomination data into it; when the completed application is submitted, the integration creates the appropriate user record in Impexium. Field mapping is configurable through settings rather than tightly coupled to one specific form, allowing future form changes without rewriting the integration. This was the organization’s first automated workflow for creating these Impexium user records.