Harvard Law Review

The Harvard Law Review is a student-run journal whose entire masthead turns over every twelve months, and I was the WordPress engineer behind harvardlawreview.org across eight volumes, one full redesign by another agency, and every plugin, platform and Cloudflare change in between.

Key Takeaways

  • Provided eight years of engineering continuity for an organization that has none by design: editors serve one volume and leave, and I was the part of the stack that remembered why things are the way they are.
  • Ran every update against a copy of the live database before it shipped, including multi-major-version plugin jumps on components the public site depends on.
  • Balanced security with editorial reality: brute-force protection and rate limiting on admin paths, tuned so student editors on personal laptops at odd hours were never locked out of their own publication.
  • Wrote every fix up in terms a non-engineer could act on and forward to next year's chairs, turning institutional turnover into a documentation practice.
  • Supported the publication's distinctive editorial features, from interactive Supreme Court statistics visualizations to the crossword, through platform changes that would otherwise have broken them.

Organization

The Harvard Law Review is among the most cited law journals in the world, publishing eight issues a volume alongside its online Forum and annual empirical projects such as the Supreme Court statistics. It is entirely student-run: the masthead, including the Online Chairs who own the website, turns over completely every year, with continuity resting on a very small permanent staff and on the systems themselves.

Challenge

The Review's technical challenge is institutional, not architectural: the people who know how the website works keep graduating. Documentation written for one volume describes workflows the next volume cannot find, and every operational question, from publishing mechanics to security posture, needs an answer that survives the handover.

Solution

  • Continuous stewardship across eight volumes: plugin, core and platform updates tested against production data, security patches applied on schedule, and the theme carried through a full external redesign.
  • Cloudflare configured for the publication's real usage: managed challenges rather than interactive CAPTCHAs, rate limiting on sensitive paths, aggressive static caching, and AI crawler policy.
  • Editorial systems kept working through platform change, with fixes placed in the Review's own code so third-party updates cannot remove them.
  • Annual support for the statistics visualizations and other recurring editorial projects, with the process documented for each incoming masthead.
  • Written explanations attached to every significant change, addressed to the next volume as much as the current one.

Results

  • Eight volumes supported through complete editorial turnover, through Volume 140.
  • Lighthouse accessibility from under 70% to 99% on the home page.
  • Zero successful brute-force compromises on an install carrying the Harvard name and dozens of student accounts.
  • 20 to 40 hours of rediscovery avoided per volume transition.
  • Nine plugins moved in a single tested cycle, including a nine-major-version jump on the crossword component.