Demo project

WordPress edits: the Volokno workshop demo

A working site in Docker that can be edited, broken and rebuilt with one command.

demo setup, content, screenshots · WordPress · Docker · MariaDB · PHP · WP-CLI

in progressThe demo works and the screenshots are taken, but the REA...

5 scenariosfrom one content build
1 commandbrings the site up from files
7 pagesplus a blog with four posts
29 shotsfinished, across ten series
3 tiersreplacing a nine-row price table
Demo first screen: WordPress edits: the Volokno workshop demo

The task

“I will edit your WordPress site” is sold with screenshots: buyers want to see what an edit looks like, not read a description of it. Someone else’s live site cannot go into a screenshot, stock images prove nothing, and a bare “test page 1” on a white background looks worse than having no examples at all.

So the work needs its own WordPress install - one where anything can be filmed: editing pages, measuring load speed, switching a shop on, taking the site down and repairing it, sending form submissions to a CRM. And it has to look like an ordinary small-business site, with real copy, prices and a blog, not like a scaffold.

This card covers the demo itself: the site of a fictional joinery workshop called Volokno, and the typical edit performed on it. The company is invented, the brief is real.

The solution

  • Two containers: WordPress 7.1 on PHP 8.3 and MariaDB 12.3. The site only starts once the database passes its healthcheck, and a one-shot setup service waits for the site to answer over HTTP, builds all content through wp-cli and then exits.
  • Content lives in files under setup/content rather than being typed into the admin: 7 pages, a blog with four posts across three categories, the header menu, a three-column footer and a custom blog template. That makes the build repeatable - down -v then up -d recreates the same site, while a plain up -d leaves content alone because the script checks wp core is-installed and exits.
  • The niche was picked so it does not overlap with the other demos in this portfolio: made-to-order solid wood furniture. Russian locale for core, the stock Twenty Twenty-Five theme with no build step or page builder, permalinks like /uslugi/, the Europe/Moscow time zone and Russian date formatting.
  • The typical edit is prepared in both directions: an outdated nine-row price table, and a block of three tiers - survey and drawings, a finished piece, a whole kitchen. Both states are separate files, so a before/after shot can be taken at any time and rolled back with a single wp post update.
  • Four more scenarios then live on the same demo. A WooCommerce shop, a white-screen outage with its repair and the form-to-CRM chain all run on the same instance. Speed measurement runs on a separate copy of the demo on port 8182, built from the same content files: the edits made for the measurement touch every page at once, and the main demo is needed for other screenshot series at that moment.

Details that are easy to miss

  • The admin area is prepared for filming in advance. The account is named editor and displays as “Editor” - posts carry the same byline, so nothing personal reaches the frame, and the admin bar corner is hidden by selector during shooting. The block editor’s welcome dialogs and fullscreen mode are pre-dismissed through wp_persisted_preferences, otherwise the first admin screenshot is a “Welcome” modal.
  • Akismet and Hello Dolly are removed during the build, or an “enter your API key” banner walks into the frame. The “Hello world!” post and the sample page go too: a screenshot must not show traces of a fresh install.
  • There is no phone number, email or street address on any page. Nothing needs retouching in the frame, and invented contact details cannot land on a real person.
  • The prices and lead times in the three tiers are not made up: every figure comes from the same price table the block replaces. The numbers add up across the before/after pair.
  • The README contradicts the code in two places, and both gaps are left as they are. First: the README promises the site listens on localhost only, while compose publishes port 8181 on every interface. Second: the README promises that both scripts pick the right menu file, while in practice only the shop scripts do - the lead-form script rewrites the menu whole, so a shop switched on before the form loses its item from the header. A separate audit of this setup caught the first gap and wrote it up as a finding; the menu is not mentioned in that report at all. All ten audit findings are still sitting in the work plan, none of them closed. Leaving the gaps visible is more honest than quietly rewriting the docs and pretending they never existed.

More projects