Putting a Weightlifting Methodology Into a CMS
Steven Low's "Overcoming Gravity" is a reference work on periodic training. It works because it forces you to treat volume and intensity as variables you can adjust week to week based on recovery data. Translating that into a WordPress environment sounds straightforward until you actually try to build it. The problem is not the writing system itself. The problem is that WordPress was not designed for iterative training logs. I ran into this when a client asked me to set up a web portal for athletes who wanted to follow the Overcoming Gravity progression model without filling out a paper log. The idea was decent on paper. The reality involved wrestling with custom post types, meta boxes, and a date hierarchy that refused to cooperate with rolling weekly blocks. The core difficulty is that the Overcoming Gravity model uses phase-based progressions. You cycle through phases like Maximum Repetitions, Hypertrophy, and Strength. Each phase has exercise substitutions, set ranges, and rep targets. When you store this in WordPress, you have two choices. You can create one post per training day and link them manually. Or you can build a custom data structure where each week contains a phase assignment, and each phase assignment contains its exercise parameters. The second option scales better but requires custom code.
Here is what I ended up doing. I registered a custom post type called "Training Cycle." Each cycle holds a phase name, a week number, and a start date. Then I added a repeater field for exercises. Each exercise row contains the movement name, the prescribed set count, the rep range, and the intensity percentage. I used Advanced Custom Fields for the repeater because it handles nested loops cleanly. If you try to roll your own meta storage without a library, you will spend more time debugging SQL queries than building the actual training interface. The front end displays the current phase at the top of the page. Below that is a table showing each exercise with its set and rep prescription. I added a simple JavaScript toggle so users can mark exercises as completed. The completion data writes back to post meta. I avoided a full authentication system at first. I used password-protected posts for individual athletes. That kept the setup fast. It is not ideal for a production environment, but it worked for a small group. One thing nobody warns you about is the exercise substitution logic. Overcoming Gravity allows you to swap exercises within a movement category. If the athlete cannot do barbell squats, they switch to front squats or goblet squats depending on the phase. Storing substitutions in WordPress requires a flexible relationship structure. I ended up creating a second custom post type for "Exercise Bank" and using taxonomies to tag movements. This lets you query all available variations for a given category without hardcoding them into the training cycle post.
Another edge case involves the progression rules. Overcoming Gravity tells you when to increase load based on hitting the top of a rep range across all sets. The logic for that lives outside WordPress unless you build it. I wrote a small PHP function that compares the completed reps to the prescribed rep range and sets a flag called "ready to progress." The front end then highlights the next week's cycle with a visual indicator. Without this, athletes have to manually calculate whether they are ready to move up. That defeats the purpose of putting it online. Performance matters more than you might expect. Training logs generate a lot of reads and writes on workout days. If you use heavy page caching without excluding dynamic sections, users will see stale data. I resolved this by keeping the exercise tables un-cached and only caching the surrounding layout. The difference is noticeable on shared hosting. On managed WordPress hosting with object caching, the overhead is acceptable. There are limits to this approach. WordPress is not a real-time database. If you need live heart rate integration, biometric syncing, or multi-user collaborative editing, you are better off using a dedicated sports platform or building a custom application with a proper backend. WordPress handles static training prescriptions well. It struggles with concurrent edits and data consistency across multiple athletes viewing the same cycle at the same time.
Get the Full Details
For most people, the practical path is simpler. You create a custom post type for training cycles. You add ACF repeaters for exercises. You write a short template that pulls the current phase and displays the table. You handle exercise substitutions through a taxonomy. You add a basic progression checker in PHP. That covers the core functionality without overcomplicating the architecture. If you need more, you extend from there rather than starting with a monolithic solution.
