Great-West Life Tim Hortons Care: Bilingual EN/FR WordPress Theme
Bilingual EN/FR enterprise WordPress theme for a regulated Great-West Life employee assistance platform. Two...
This theme was built to pass a formal enterprise security audit, serve content in multiple languages without developer intervention, and meet WCAG compliance requirements specified by legal - not suggested by a checklist. The architecture decisions behind it are the technical substance of this case.

Formal enterprise security audit compliance
Multi-language support without developer intervention
WCAG compliance requirements implementation
Custom architecture and decision documentation
This theme was built to pass a formal enterprise security audit, serve content in multiple languages without developer intervention, and meet WCAG compliance requirements specified by legal - not suggested by a checklist. The architecture decisions behind it are the technical substance of this case.
The Munich Re platform runs on a custom theme with no parent theme dependency and no page builder. Every template was written from scratch in PHP with a clear separation between data retrieval, business logic, and presentation.
Why no framework? Theme frameworks like Genesis, Divi, or Avada inject functionality you don't control - REST API routes, JavaScript bundles, database queries - all of which expand the attack surface and complicate a security audit. For an enterprise client running a formal vendor review, every line of code needs to be accountable. A custom theme gives you that.
File structure follows WordPress template hierarchy strictly: single.php, archive.php, page.php, taxonomy.php - each with specific template parts loaded via get_template_part(). No monolithic templates, no duplicated markup.
Security at this level isn't a plugin you install. It's a set of architectural commitments.
Every database interaction uses $wpdb->prepare() with typed placeholders. No string concatenation in SQL, no dynamic table names, no raw $_GET/$_POST values passed to queries.
REST API endpoints not required for this deployment were disabled via remove_action( 'init', 'rest_api_init' ) with selective re-enabling. User enumeration via ?author= was blocked at the routing layer. XML-RPC was disabled.
Output escaping is applied at every echo point: esc_html(), esc_url(), esc_attr(), wp_kses_post() - appropriate to context. No raw output anywhere.
Plugin selection was audited. Every included plugin was reviewed for update history, maintainer reputation, and code quality. Plugins with abandoned maintenance windows were excluded.
WPML handles the translation layer, but the theme had to be built to work with it cleanly. That means no hardcoded strings in PHP templates. Every user-facing string is wrapped in __() or _e() with a unique text domain. String registration is centralized, not scattered across template files.
Layout tested at every language. German and French copy runs 20-40% longer than English equivalents. Every layout component was tested under realistic translated copy to verify no overflow, truncation, or broken grid behavior.
Language switcher integrated into navigation without JavaScript dependency. The switcher degrades gracefully and works on screen readers.
wpml-config.xml configured to sync custom field translations across post types. Editors working in secondary languages see the same field structure as the English source.
WCAG compliance was a legal requirement on this engagement, not a best-practice suggestion. The implementation reflects that distinction.
Color contrast ratios verified against WCAG AA thresholds for every text/background combination, including hover states and focus states. No reliance on color alone to convey information.
Keyboard navigation fully functional across all interactive components. Focus styles visible and WCAG-compliant, not suppressed with outline: none. Tab order follows DOM order; no CSS-only reordering that breaks keyboard flow.
ARIA roles and attributes applied where native HTML semantics don't fully describe component behavior. No ARIA overuse on elements where native HTML already carries the correct role.
All images carry meaningful alt text. Decorative images use alt="". SVG icons used in interactive contexts include aria-label.
Custom theme = zero unused CSS. No 500kb stylesheet from a framework that includes every layout permutation you'll never use.
Assets enqueued via wp_enqueue_scripts with cache-busting version strings tied to file modification time: filemtime( get_template_directory() . '/assets/css/main.css' ). No manual version bumps required.
Images served via WordPress's native responsive image pipeline: srcset and sizes attributes generated automatically. Hero images use loading="eager" with explicit width and height to prevent layout shift. Below-fold images use loading="lazy".
No layout-blocking JavaScript. All non-critical JS loaded with defer. Critical CSS inlined for above-fold content.
The architecture patterns - custom from scratch, no framework dependencies, security-first, WPML-ready - are transferable. The specific implementation is tied to this project's requirements. I'd build a new theme using the same principles, not copy this one.
Core functionality required fewer than 8 plugins. Each was audited before inclusion. No plugin is included for convenience if its functionality could be implemented cleanly in theme code.
Via WPML's wpml-config.xml registration. Custom fields used in templates are declared as translatable. WPML handles sync between source and translated posts. Editors in secondary languages see the same field structure as the English editor.
Yes. ACF Pro was used for structured content fields. Field groups were registered in PHP (not the database) to keep them version-controlled and reproducible across environments.
I'll build a custom WordPress theme designed specifically for your brand and goals.

Bilingual EN/FR enterprise WordPress theme for a regulated Great-West Life employee assistance platform. Two...