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
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.
