Client project
How I built Raviana's subscription video platform
Raviana is a subscription yoga studio for Ana Brett and Ravi Singh. The brief was straightforward to state and involved to deliver: members pay monthly or annually, sign in, and stream a categorized on-demand library, with live Zoom classes and a shop alongside it. Everything hinges on one rule, so I designed the whole system around it: if you have not paid, you do not see the video.
The developer stack
I built the site on a Roots stack: Sage for the theme, Bedrock for the project layout, and Composer to manage every dependency. Bedrock moves WordPress into a real project structure with environment-based config and a version-controlled composer.json, so plugins and core are locked to known versions rather than clicked in through the admin.
Sage gave me a Blade-based theme with a build step, so the front end is component-driven instead of a pile of template files. That matters on a membership site, where the same "is this member allowed to see this" question repeats across dozens of views and I want it answered in one place.
The three-tier paywall
Billing runs on Paid Memberships Pro with three levels: Studio at $22/mo or $199/yr, Membership+ at $32/mo or $299/yr marked "Most Popular", and Mentorship+ at $160/mo. Each level maps to a set of capabilities, and monthly and annual are separate billing options under the same access tier.
PMPro is the gate for the whole library. Rather than lean only on per-post protection, I check membership level at the point of render, so a logged-out visitor gets the funnel and a paid member gets the player. The seven-day free trial funnel is wired into the same level logic, so a trial account behaves like a paid one until it expires and then drops back to the marketing view.
The gated video library
The library is organized into Full Practices, Quick Sets, Breathing and Meditation, Rotations, and Ravi Talks. I modeled those as taxonomy so a video can be filtered and browsed by type, and so new categories are content, not code.
Video is HTML5 playback served from a CDN, which keeps delivery fast and off the origin server. The access decision happens before the markup is built. If the current user does not hold a valid level, the CDN references are never printed to the page, so there is no player and no source URL to inspect. That is the difference between hiding a video and actually gating it.
Accounts, favorites, and the dashboard
Members get real accounts with a favorites feature, so a practice can be saved and found again without hunting through categories. The membership dashboard is the signed-in home: current plan, saved practices, and the paths into the library and live classes.
I kept the dashboard thin and predictable on purpose. On a recurring-revenue product, the account area is where retention lives, so it needs to load cleanly and never leave a paying member confused about what they have access to.
Live classes, shop, and newsletter
Live classes run through a Zoom integration, so scheduled sessions sit next to the on-demand catalog instead of in a separate tool. There is an integrated shop for products and a newsletter capture for people still deciding, which feeds the top of the same trial funnel.
Client results placeholder: retention and engagement numbers to be added with the client's permission. I do not publish metrics I have not been cleared to share.
Technical note
Notes on a Drupal 11 custom theme
Most of my delivery work is WordPress and Shopify, so I want to be clear about why I spend time on Drupal too. Building a custom Drupal 11 theme is the exercise that keeps me honest about how a CMS actually works, rather than how one particular CMS works. The theming layer is different enough from WordPress that it forces you to think in the platform's own terms.
What a Drupal 11 theme actually is
A Drupal theme is defined by a small set of declarative files before you write any markup. An info.yml file registers the theme, its regions, and its libraries. A libraries.yml file declares CSS and JS as named bundles you attach where they are needed, instead of dumping everything into one global include. That "attach only what this thing uses" model is stricter than the WordPress enqueue habit, and it keeps pages lean by default.
Regions are declared, not assumed. You name the areas of your layout in the theme, and the block system fills them. So the structure of the page is theme-owned config, which makes a site's layout legible without reading a stack of PHP templates.
Twig instead of PHP templates
Drupal templates are Twig, not raw PHP. That is the biggest day-to-day difference from WordPress. Twig is a sandboxed templating language, so template files hold presentation logic and nothing else, and by default output is auto-escaped. You get safer markup without remembering to escape every variable by hand.
The workflow is to find the right template suggestion, copy it into the theme, and override just that piece. Drupal exposes granular suggestions such as a template for a specific content type or a specific field, so you can retheme one node type without touching the rest of the site. Preprocess functions in the theme let you shape variables in PHP before they reach Twig, which keeps the Twig files clean while still giving you a place for real logic.
Why this widens my CMS range
Learning Drupal 11 theming is not about collecting another logo. It changes how I read any content system. Drupal's structured content model, with defined fields and view modes, is much closer to a database schema than WordPress's freer post model, and working in it made me a more disciplined WordPress developer too.
Practically, it means a client is not locked into one platform because that is the only one I know. If the right answer for a project is Drupal because of its permissions model, multilingual support, or structured editorial workflow, I can build the theme rather than talk them out of it. The same is true in the other direction with Shopify and Webflow, which I also ship on.
How I approach a new theme
- Start from the content model. Know the content types, fields, and view modes before writing markup.
- Declare regions and libraries first, so structure and assets are explicit.
- Override the narrowest template suggestion that solves the problem, never the broadest.
- Push logic into preprocess functions and keep Twig about presentation.
- Lean on auto-escaping and treat any raw-output filter as something to justify.
The takeaway is simple. A custom Drupal 11 theme is a good test of whether you understand a CMS or just its shortcuts, and doing that work is what lets me meet a project on the platform it actually needs rather than the one I am most comfortable with.
