Loopress

Build, review and ship WordPress, in one loop.

Loopress turns the parts of WordPress that are not content, configuration and code, into files in your repo. You edit them, review them in a PR, push them to any environment, and roll them back. Posts, orders and users never move.

npm i -g @loopress/cli
lps project config   # connect a site, installs the plugin
lps pull             # the site, as files

loopress.dev · Documentation · Demo project · Security policy

The loop

   ┌────────────── build ───────────────┐
   │  acf/  menus/  cpt/  hooks/        │
   │  api/  apps/  loopress.json        │
   └──────────────────┬─────────────────┘
                      │  git commit
   ┌────────────── review ──────────────┐
   │  lps diff --env staging            │
   │  a short diff, in a real PR        │
   └──────────────────┬─────────────────┘
                      │  merge
   ┌─────────────── ship ───────────────┐
   │  lps push --env staging            │
   │  lps promote staging production    │
   │  each push is snapshotted,         │
   │  undo with lps <resource> rollback │
   └──────────────────┬─────────────────┘
                      │  meanwhile, someone edits wp-admin
                      │  lps diff spots it, lps pull brings it back
                      └──────────────── ↺ build

Why

If you look after several WordPress sites, most of what can break them lives in the database: field groups, plugin settings, menus, a snippet someone pasted in the admin. None of it has a history, a review, or an undo. Loopress gives it all three, without asking you to restructure the site or move hosts.

Light or Full

Same plugin, two builds. Light syncs configuration and is on WordPress.org. Full adds code, which WordPress.org does not allow a plugin to deploy, so it ships from loopress.dev. Both are free.

	Light	Full
ACF field groups, post types, taxonomies	✓	✓
Forms, menus, options, block theme styles	✓	✓
Custom post types, taxonomies, post meta keys and roles (JSON files, like CPT UI in Git)	✓	✓
Hooks, filters, cron (PHP classes)		✓
REST API routes		✓
Apps (React, Vue, Svelte bundles)		✓
Pages, block templates and patterns, snippets		✓
Plugin and theme lockfile, Composer		✓
Get it	WordPress.org	loopress.dev

Code, with conventions

Not a framework. Just a few rules that make WordPress code readable: one class per file, attributes instead of add_action calls scattered across functions.php, and a hook that throws is logged instead of taking the site down.

// hooks/vat-notice.php
class VatNotice
{
    #[Filter('woocommerce_get_price_html')]
    public function notice(string $html): string
    {
        return $html . ' <small>incl. VAT</small>';
    }
}

Status

Alpha, moving fast. Issues and pull requests welcome.

---

What's in this repo

This is the loopress/loopress pnpm workspace: the CLI, the companion WordPress plugin, the marketing site, and the docs all live and version together here.

Package	What it is
cli/	@loopress/cli, the lps command. Talks to the WordPress plugin's REST API to pull/push everything.
mcp/	@loopress/mcp, the lps-mcp MCP server. Exposes CLI operations as tool calls for AI agents.
wordpress-plugin/	The WordPress plugin (loopress) the CLI talks to. Ships as two editions, Light (wordpress.org) and Full (loopress.dev only), from one codebase.
website/	The loopress.dev marketing site (Astro + React).
documentation/	The docs site (Astro + Starlight) at docs.loopress.dev.
e2e/	Playwright tests running the real built CLI against a real, disposable WordPress instance.
assets/	Shared brand assets (@loopress/assets: logo, icons) consumed by the plugin and the website.
eslint-config/	Shared ESLint config (@loopress/eslint-config) for the JS/TS packages.

Each package has its own README with the details, this one is just the map.

Requirements

• Node 24.x
• pnpm (version pinned in package.json's packageManager, run via corepack enable or install it directly)
• PHP + Composer for wordpress-plugin/ (see its own README)

Getting started

pnpm install   # installs the whole workspace from the repo root

Then jump into whichever package you're working on:

cd cli && pnpm dev                # CLI, watch mode
cd wordpress-plugin && composer install && pnpm dev:full   # plugin admin UI, watch mode
cd website && pnpm dev            # marketing site
cd documentation && pnpm dev      # docs site

Testing

• Unit tests: run inside each package (pnpm test in cli/, composer test in wordpress-plugin/). No network, no WordPress instance needed.
• E2E tests (e2e/): the real CLI against a real, disposable WordPress instance. See e2e/README.md for how to point them at one, locally or via the same Docker stack CI uses.

Links

• CLI mutation report (Stryker)
• WordPress plugin mutation report (Infection)

Both are rebuilt on every push to main (see .github/workflows/mutation-report.yml) and published to GitHub Pages. Report-only for now, not a merge gate, the plugin job runs with continue-on-error: true (see wordpress-plugin/infection.json5).

Releasing

Versioning and changelogs are managed with Changesets. Run pnpm changeset when a PR changes published package behavior, and describe it as a patch, minor, or major bump for whichever package(s) it touches.

License

MPL-2.0, except the WordPress plugin, which is GPL like WordPress itself.