WP Manifestindependent plugin directory
manifest / editor / tulip-blocks

Tulip Blocks

Blocks for the Tulip WordPress theme

★ 0stars

Install

Download source zip No release zip yet

This is the repository archive. It installs, but the folder name will carry the branch suffix and updates will not flow.

Install straight from GitHub with WP-CLI:

wp plugin install https://github.com/bertuuk/tulip-blocks/archive/refs/heads/main.zip
Updates itself. It ships its own updater, so new versions appear under Dashboard → Updates.

Blocks for the Tulip theme. Tulip itself registers no blocks (see docs/decisions.md, 2026-10-08): anything that core blocks, patterns and section styles can't do lives here.

The blocks take colours, type and radii from Tulip's roles (base, contrast, primary, accent…) and section styles, so they look right in any Tulip child theme and have no colour settings of their own.

Develop

Keep this repo next to Tulip's, so the folders are siblings:

Tuk DS/
├── tulip/          # github.com/bertuuk/tulip
└── tulip-blocks/   # this repo
cd tulip-blocks
npm install
npm start        # rebuilds build/ on every change

Tulip's .wp-env.json mounts ../tulip-blocks, so npm start in the Tulip folder gives a local site with the theme and this plugin active. The plugin only loads what is in build/: run npm run build (or keep npm start running) before testing.

Add a block

One folder per block in src/, named after the block (src/step-carousel/ → tulip/step-carousel), with its block.json. tulip-blocks.php registers every build/*/block.json, so there's nothing to add there.

Versions

Semantic versioning, like Tulip:

  • x.y.Z — fixes. Installed automatically on every site.
  • x.Y.0 — new blocks or options. Installed automatically.
  • X.0.0 — changes that can break content already saved with a block (renamed attributes, different markup without a deprecation). Offered in Dashboard → Updates, never installed on its own.

While the first block is being built, versions stay at 0.x. A block change that alters its saved markup needs a deprecated entry, so existing content keeps validating.

Release

build/ is not committed: the release workflow builds it.

  1. Bump the version in four places: the Version: header and TULIP_BLOCKS_VERSION in tulip-blocks.php, Stable tag: in readme.txt, and package.json. Add a = X.Y.Z = changelog entry to readme.txt.
  2. Commit and push to main.
  3. Tag it from your machine: git tag -a vX.Y.Z -m "Tulip Blocks X.Y.Z" && git push origin vX.Y.Z

The Action (.github/workflows/release.yml) checks the four versions and the changelog, runs npm ci && npm run build, makes tulip-blocks.zip with wp-scripts plugin-zip (only the files listed in package.json → files) and publishes it as the latest Release.

Updates on the sites

The Update URI header plus inc/class-tulip-blocks-updater.php make new Releases appear in Dashboard → Updates, and automatic updates install them (same major version only). On a Tulip site repo, add it to deploy/site.conf:

GITHUB_PLUGINS="tulip-blocks/tulip-blocks"