Genesis Sample: the child theme that shows how StudioPress writes WordPress themes
This is the sample theme created for the Genesis Framework.
At a glance
- What is it?
- Genesis Sample is a sample child theme for the Genesis Framework, and its real purpose is pedagogical: it is the reference implementation StudioPress points developers at, with the coding standards, the PHP and JavaScript linting, the translation file generation and the packaging steps all wired up and documented. It is a demonstration of the conventions rather than a theme you would install on a site.
- Who is it for?
- Genesis Sample suits a developer learning how the Genesis Framework expects a child theme to be written, because the theme is small and every convention it teaches is visible in the source. It does not suit you as a production theme, since it is explicitly the sample, and it does not suit a site that does not already run the Genesis parent theme.
- Can I use it commercially?
- Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
- Is it still maintained?
- Yes. The repository last received commits 37 days ago.
- What is it written in?
- Mainly PHP, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 22, 2026, and from our analysis. They are not legal advice.
Editorial analysis
A sample theme is a teaching artifact
Genesis Sample is described as the sample theme created for the Genesis Framework, and the package manifest calls it the sample child theme for the Genesis Framework with a version of 3.4.3.
The word sample is doing the work here. This is not a theme you install to run a site, it is the reference implementation that StudioPress publishes so that developers can see how a Genesis child theme is supposed to be put together. The demo is at demo.studiopress.com/genesis-sample/, and the GitHub project link is in the README.
That framing explains the rest of the repository, which is mostly tooling rather than theme code. If it were a production theme, the PHP would be the point and the lint configuration would be incidental. Here, the tooling is the point.
The primary language is PHP, the default branch is develop rather than main, and the last push was on 2026-09-16. The recent release history is slow: Genesis Sample 3.4.3 from 2025-03-18, 3.4.2 from 2022-12-19 and 3.4.1 from 2021-03-25. The project is maintained, but on a release rhythm that tracks the parent framework rather than a busy development cycle, and the version in the package manifest is the 3.4.3 release from March 2025 rather than something newer than the last push.
Installation assumes you already have the parent theme
The installation instructions are short and they are aimed at someone evaluating the theme rather than someone building with it.
1. Upload the Genesis Sample theme folder via FTP to your wp-content/themes/ directory. The Genesis parent theme needs to be in the wp-content/themes/ directory as well. 2. Go to your WordPress dashboard and select Appearance. 3. Activate the Genesis Sample theme. 4. Inside your WordPress dashboard, go to Genesis > Theme Settings and configure them to your liking.
Two things are worth pulling out of that. First, the parent theme dependency is explicit: this is a child theme and it does not work without Genesis installed alongside it. Second, the FTP instruction tells you what this is for. The GitHub version is the development repository with Composer and npm tooling in it, and the instructions are for getting the built theme onto a WordPress install to look at it.
The step about Genesis > Theme Settings is the one that shows the framework's model. The settings live in the parent theme's admin screen, not in the child theme, so a site can switch child themes and keep its configuration. That inheritance is the central idea of the Genesis framework and the sample theme demonstrates it by not having its own settings screen.
Theme support is handled through StudioPress rather than the repository, with a pointer to my.studiopress.com/help/, and the repository carries a CONTRIBUTING.md and a CHANGELOG.md.
The licence is the thing to check first, and it is inconsistent across the sources. The licence field in the repository metadata is reported as unknown, while the package.json declares GPL-2.0-or-later, and the theme's own style.css header is what WordPress itself reads when it displays a theme's licence in the admin screen. Any redistribution decision should be based on the files in the repository rather than on the metadata field.
The developer tooling is the reason to read this repository
The For Developers section is the substantive part of the README, and it is where the pedagogical value sits.
The GitHub version of Genesis Sample includes tooling to check code against WordPress standards. The steps are: install Composer globally, change directory to the Genesis Sample folder, run composer install to install PHP development dependencies, and run composer phpcs to run coding standards checks.
The output highlights issues with PHP files that do not conform to Genesis Sample coding standards, and if you see the message about phpcbf being able to fix the x marked sniff violations automatically, you run composer phpcbf.
That is a complete WordPress coding standards setup in three commands, and it is the part a developer copying this pattern gets for free.
The npm scripts cover the front end and the translation workflow. The steps are to install Node.js, which also gives you the Node Package Manager, change directory to the Genesis Sample folder, and run npm install.
Then there are five scripts.
npm run autoprefixer
npm run makepot
npm run lint:css
npm run lint:js
npm run fix:jsThe autoprefixer script adds and removes vendor prefixes in style.css, the makepot script regenerates the languages/genesis-sample.pot file, lint:css generates a report of style violations for style.css, lint:js generates a report of style violations for JavaScript files, and fix:js fixes any JavaScript style violations that can be corrected automatically.
The dependency versions in package.json tell you the supported environment. Stylelint is at 13.8.0 with the WordPress stylelint config, eslint at 5.16.0 with eslint-config-wordpress, autoprefixer at 9.8.6 running over postcss 8.4.12, node-wp-i18n for the pot file generation, archiver for the zip step, and npm-run-all to chain the scripts.
Those are old versions, and that is a signal rather than an oversight. The browserslist array is the clearest hint about the era, with ie >= 11 as an explicit target alongside the last two versions of every current browser.
Packaging for distribution is a documented, repeatable set of steps
The packaging section is where the sample theme stops being a demo and becomes a template for your own release process.
1. Follow the install instructions for npm scripts above. 2. Switch to the git branch you plan to distribute. 3. Bump version numbers manually and commit those changes. 4. Run npm run zip to create genesis-sample.zip.
Two details matter. The version numbers are bumped manually, which means the branch you distribute from and the version you ship are two things you keep in step by hand. And the zip step is not a plain archive, because files in the excludes array in scripts/makezip.js are omitted from the zip, and filename.md files are renamed to filename.txt.
That renaming is a WordPress convention rather than an arbitrary choice. WordPress reads the readme.txt in a theme directory for its own metadata, and markdown files in a distributed archive get converted so the standard file is the one present.
The zip script itself is .scripts/makezip.js, and the scripts directory is hidden, with a leading dot, which keeps it out of the distributed theme. There is a prep:piservice script that runs .scripts/makePIServiceData.js, which appears to prepare data for the StudioPress service, and the makepot script runs .scripts/makepot.js.
So the .scripts directory holds the entire build and packaging layer, and the fact that it is dot-prefixed means the theme you upload is the theme minus its tooling.
The repository layout is consistent with that. There is functions.php at the root, lib/ for the theme's PHP, config/ for the Genesis configuration files, page-templates/ for the custom page templates, images/ and languages/ for the assets and translations, style.css for the stylesheet, and phpcs.xml.dist as the coding standards configuration. There is also .circleci/ for the older CI setup alongside .github/.
The PHP side of the tooling is Composer, with composer.json at the root, and the standards configuration in phpcs.xml.dist. The .dist suffix is the convention that tells Composer not to install the file directly, since it is a template that a project may override locally.
Where Genesis Sample is the wrong tool
The first wrong-tool case is a production site. This is the sample child theme. It exists so that a developer can see the conventions, and it is deliberately minimal. If you want a site, you use a different Genesis child theme, and if you want to build one, you start from this and replace the content.
The second case is a WordPress site that does not run the Genesis parent theme. The installation instructions say outright that the Genesis parent theme needs to be in the wp-content/themes/ directory as well, and the settings live under Genesis > Theme Settings in the parent theme's admin screen. There is no path to using this standalone, and no fallback theme in the repository.
The third case is a project that has moved on from the versions pinned here. The eslint at 5.16.0, stylelint at 13.8.0, autoprefixer at 9.8.6 and the browserslist entry for ie >= 11 all place this repository in a specific era. A team that has standardised on current tooling will take the structure and not the versions, because a lint setup pinning a six-year-old eslint is a security and maintenance question in a build pipeline.
The fourth case is anyone expecting a modern theme feature set. The theme tags listed in the manifest include accessibility-ready, custom-colors, custom-logo, custom-menu, featured-images, footer-widgets, full-width-template, rtl-language-support, sticky-post and theme-options. That is the feature set of a well made traditional theme, and there is no block theme support, no full site editing and no theme.json, which is what a WordPress project starting today would expect.
On the code itself, the interesting question is how much of the theme lives in the parent and how much here. The functions.php file at the root and the lib/ directory hold the child's own code, while the Genesis framework functions, the widget setup and the layout system live in the parent. That split is why the theme is a useful reference and a poor starting point for a designer, since the heavy lifting is in a dependency you did not write.
There is also a translation workflow that is easy to miss. The makepot script regenerates languages/genesis-sample.pot, and node-wp-i18n is in the dev dependencies to do it. A child theme with translatable strings needs that file regenerated whenever the strings change, and the sample shows where to put it and how to build it.
On licence, the answer depends on what you do. The package manifest says GPL-2.0-or-later, which permits commercial use and modification with copyleft on distribution of the theme itself, and the repository metadata's licence field is reported as unknown, so a redistribution should be checked against the files rather than the metadata.
Editorial conclusion
Genesis Sample suits a developer learning how the Genesis Framework expects a child theme to be written, because the theme is small and every convention it teaches is visible in the source. It does not suit you as a production theme, since it is explicitly the sample, and it does not suit a site that does not already run the Genesis parent theme. Before using it, read composer.json and package.json rather than the README alone, because the tooling versions pinned there tell you more about the supported environment than the prose does, and note that the README's own installation steps assume FTP access to the server.
Frequently asked questions
What is the Genesis Sample theme?
Genesis Sample is the sample child theme created for the Genesis Framework by StudioPress, published as a reference implementation with the coding standards checks, linting and packaging tooling included. Its package manifest describes it as the sample child theme for the Genesis Framework.
How do I install the Genesis Sample theme?
Upload the Genesis Sample theme folder via FTP to your wp-content/themes/ directory, with the Genesis parent theme also in that directory, then activate it from Appearance in the WordPress dashboard and configure it under Genesis > Theme Settings.
How do I run the coding standards checks on Genesis Sample?
Install Composer globally, change directory to the Genesis Sample folder, run composer install to install the PHP development dependencies, and run composer phpcs to run the coding standards checks. Run composer phpcbf to fix the sniff violations that can be fixed automatically.
What npm scripts does Genesis Sample provide?
There are five: npm run autoprefixer to add and remove vendor prefixes in style.css, npm run makepot to regenerate the languages/genesis-sample.pot file, npm run lint:css and npm run lint:js to report style violations, and npm run fix:js to fix the JavaScript violations that can be corrected automatically.
How do I package Genesis Sample for distribution?
Follow the npm install steps, switch to the git branch you plan to distribute, bump the version numbers manually and commit those changes, then run npm run zip to create genesis-sample.zip. Files in the excludes array in scripts/makezip.js are omitted from the zip and filename.md files are renamed to filename.txt.
What license is Genesis Sample released under?
The package.json declares GPL-2.0-or-later, while the licence field in the repository metadata is reported as unknown, so any redistribution should be checked against the files in the repository rather than the metadata field. The theme also requires the Genesis parent theme to be installed alongside it.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/studiopress-genesis-sample)Was this useful?