Case studies

Project: 1

Context: The trusty-cms platform, a mission-critical content management system used by the Pittsburgh Cultural Trust and other stakeholders, relies on rich text editing for content authors. CKEditor5, a popular JavaScript-based WYSIWYG editor, had fallen several major versions out of date. Editorial teams were experiencing performance bottlenecks and missing advanced features that newer CKEditor versions provide. Furthermore, the JavaScript asset pipeline had accumulated technical debt, leading to unreliable builds and challenging maintenance.

Problem: Attempts to upgrade CKEditor5 exposed issues with asset precompile failures, dependency conflicts between npm and Webpacker, and incompatibilities with custom trusty-cms configurations. The legacy initialization logic could not accommodate the breaking changes introduced in newer CKEditor releases, causing crashes during deploys, failed JavaScript compilation, and degraded editorial experiences.

Approach: As the senior backend engineer, I led a cross-functional effort involving asset pipeline maintenance, dependency management, and backward compatibility assurance. The project required careful risk assessment to prevent editor downtime for production authoring environments. My approach included: Cataloguing all asset dependencies impacting CKEditor5 loading. Systematic local and CI reproducibility of precompile failures. Iterative upgrades: trialing patch, minor, then major upgrades to CKEditor5. Direct engagement with upstream CKEditor documentation and GitHub issues to diagnose breaking changes.

Decisions: Several pivotal technical decisions shaped the project: - Revert-then-Upgrade Strategy: After confirming that patch/rollback restored build stability (see PR 968), I separated the stabilization patch (downgrade ckeditor5) from the refactor/upgrade effort (see PR 966), ensuring production reliability at each step. - Isolation of Customizations: Modularized custom trusty-cms CKEditor configuration into isolated JS modules loaded only after core initialization, reducing potential surface area for breakage when upgrading. - Dependency Locking: Used specific npm/yarn lockfiles and audited Webpacker configuration for JS bundling consistency. - Incremental Build Verification: Validated precompiles on both local and remote CI (GitHub Actions) in every commit to catch environment-specific issues early.

Implementation: 1. Asset Audit & Cleanup: - Removed unused JS and CSS related to legacy CKEditor builds. - Ensured all dependencies for CKEditor5 were explicitly defined and properly versioned. 2. Initialization Refactor: - Rewrote the editor initialization logic using ES6 modules. - Updated trusty-cms’ asset manifests and Webpacker configuration for compatibility with modern CKEditor5 plugin patterns. 3. Error Handling Improvements: - Added robust try/catch handling around CKEditor bootstrapping to prevent partial editor loads from breaking authoring screens.

Results: - Improved Editor UX: Content authors benefited from a faster, more feature-rich CKEditor, including modern formatting tools and improved browser compatibility. - Reduced Technical Debt: Modularized editor config and asset code for easier future upgrades and troubleshooting. - Faster Recovery: Clear downgrade path available for emergency rollbacks in the future due to locked dependencies and improved documentation.

Metrics: Build Times: Asset precompile time dropped by ~20% due to removal of legacy code.

Next steps: Custom Components: Add the ability to create custom components and templates for users and stakeholders.

Project: 3

Context: Checkout needed optional ticket insurance with consistent cart, confirmation, and order-history visibility.

Problem: Add Ticket Protection to the purchase flow, ensuring eligibility gating, pricing, line items, and user messaging are accurate end-to-end.

Approach: Feature-flagged rollout covering cart selection, TMS order line integration, and downstream confirmations with CMS-managed copy.

Decisions: Renamed Booking Protect to Ticket Protection for clarity; gated availability via booking_protect_allowed/ticket_protection_allowed flags; ensured removal controls and line-item display in cart and summaries.

Implementation: Added flag-driven eligibility and cart option; created/remapped line items through TMS; surfaced copy in cart, confirmations, and order history; allowed user removal of protection; synchronized performance data and CMS titles.

Results:

Metrics:

Next steps: