Method Generator

Method Generator renders the Method Child starter with a project’s own identity — theme header, text domain, function prefix, local development URL — so a new child theme starts life without a method_child_ to find and replace. It is a small Gulp project: Nunjucks templates for the files that carry names, the Method Child repository as a submodule for everything else, and one task that copies, renders, cleans and (optionally) pushes the result.

The source is pixelwatt/method-generator, currently v2-1.0.0-beta5, which templates Method Child 1.0.0-beta5. It needs Node.js with npm, the Gulp CLI (the project uses gulp 4) and, for the push step, git. The walkthrough — from download to activating the generated theme — is in Getting Started with Method v2; this page is the reference for how the tool works and what each setting changes.

How a build works

Two inputs sit side by side in the repository. method-child/ is the Method Child repository as a git submodule, pinned to the release the generator targets; it is the un-templated reference theme. njk/ holds the templated copies of the files that contain project-specific names, under njk/assets/ in the same tree layout as the theme, plus the Nunjucks templates in njk/templates/. Running gulp build-custom runs this series:

1. copy-build — copies method-child/** (dotfiles included) into custom/, skipping the submodule’s .git, node_modules and package-lock.json.
2. render-custom — renders every file under njk/assets/ through Nunjucks (gulp-nunjucks-render, template path njk/templates, inheritExtension: true so style.css stays style.css) into custom/, overwriting the copies from step 1. The environment has autoescaping off, so PHP and HTML pass through untouched, block trimming off, and the template cache disabled.
3. clean-custom — deletes custom/.git, custom/node_modules and custom/package-lock.json if any survived the copy.
4. push-custom — initialises a repository in custom/ and pushes it, when configured (see below).
5. build-notify — prints the Method banner and a pointer to this wiki.

custom/ and _globals.html are both gitignored: the generator never commits a project. The output is meant to leave, either through the push step or by copying custom/ into wp-content/themes/.

There is one other task, rebuild-method, which renders the same templates into method-child/ itself. It is how the reference theme is kept in step with the templates when Method Child is released — run with the default globals — and with a project _globals.html in place it would rewrite the submodule with that project’s names, so it is not part of a project build.

Templated files

Every file under njk/assets/ begins {% import '_globals.html' as globals %}{% extends "_barebones.html" %}{% block content %} … {% endblock %}. _barebones.html is a single empty block — the “layout” exists only so that globals.* is in scope — and the file body is otherwise the theme file verbatim, with {{globals.…}} where a name goes. Files that carry no names are not templated at all; they come straight from the submodule.

// njk/assets/lib/admin-customization.php
function {{globals.code_prefix}}admin_scripts() {
    wp_enqueue_style( '{{globals.code_textdomain}}-admin', get_stylesheet_directory_uri() . '/assets/css/admin.css', '', THEME_VERSION );
}

// custom/lib/admin-customization.php, with the _globals.html above
function astor_admin_scripts() {
    wp_enqueue_style( 'astor-admin', get_stylesheet_directory_uri() . '/assets/css/admin.css', '', THEME_VERSION );
}

Configuration: _globals.html

Copy _globals-defaults.html to _globals.html in the same folder and edit the values. The file is a list of Nunjucks {% set name = "value" %} assignments; keep that shape, with double quotes, because the push step reads three of them with regular expressions rather than through Nunjucks. Upgrading from v2-1.0.0-beta4: the GIT Push section is new, so copy it from the defaults file into an existing _globals.html.

{% set theme_name = "Astor" %}
{% set theme_uri = "https://example.com" %}
{% set theme_description = "Astor, a Method v2 child theme." %}
{% set theme_version = "1.0.0" %}
{% set theme_license = "GNU General Public License v2 or later" %}
{% set theme_author = "Rob Clark" %}
{% set theme_author_uri = "https://robclark.io/" %}
{% set theme_tags = "Block Editor, CMB2, Method v2" %}

{% set code_textdomain = "astor" %}
{% set code_prefix = "astor_" %}
{% set css_prefix = "astor" %}

{% set localdev_url = "astor.test" %}

{% set push_custom_build = true %}
{% set git_remote_url = "git@github.com:pixelwatt/astor.git" %}
{% set git_branch = "main" %}

Pushing the build to a repository

With push_custom_build set to true and git_remote_url set, push-custom runs five git commands inside custom/: git init --initial-branch=<git_branch> (git 2.28 or later), git remote add origin <git_remote_url>, git add ., git commit -m "Initial commit" and git push --set-upstream origin <git_branch>. Because clean-custom ran first there is no inherited .git to collide with. The remote has to exist already and accept the branch — an empty repository is the expected case — and authentication is whatever your git already has for that host. If either setting is missing the task prints a one-line note and the build simply stays in custom/. From there the guide’s route is to clone the new repository into wp-content/themes/.

Running it

git clone --recurse-submodules https://github.com/pixelwatt/method-generator.git
cd method-generator
npm install
cp njk/templates/_globals-defaults.html njk/templates/_globals.html
# edit njk/templates/_globals.html, then:
gulp build-custom
# the theme is in ./custom (pushed to your remote if push_custom_build is true)

Without git, download method-generator.zip from the release — the asset attached to it, not GitHub’s generated Source code archive, which leaves the method-child/ submodule folder empty and gives copy-build nothing to copy. After the build, check custom/ for anything that should not ship (the submodule’s node_modules if it had been installed, for instance), then install the theme alongside Method and activate the child, never the parent. The Getting Started with Method v2 guide covers the rest.

Versions

The v2 line is versioned after the Method Child release it templates: v2-1.0.0-betaN renders Method Child 1.0.0-betaN, with the submodule pinned to that tag. The tags before it (v1.0.8 through v1.4.4-prerelase, 2020–2024) are the Method 1.x generator, which built per-project copies of Method itself from a Method submodule — v1.0.9 is where the project was renamed from Sunrise to Method. 6e77893 removed Method as the submodule and added Method Child, and 48a6c07 is the first v2 release.

Changelog

Commit links point at pixelwatt/method-generator.