The Git layer for WordPress
Your WordPress sites, under version control.
Clone the theme, hooks, plugin versions and Composer deps to files. Review them in a PR, push them back. The content and the database stay where they are.
Wire Loopress into a WordPress project in under a minute.
Install the CLI, authorize in the browser, and pull your first resource to a file. No SSH, no manual plugin upload.
The live site and your repo have drifted apart.
A client site runs code and config that was never committed anywhere. Every change made in the admin is a change you cannot diff, review, or roll back. The safe move, test it locally first, is the slow one, so it does not happen.
- PRODYou edit theme and config straight in prod because local is too slow to set up
- LOGNo git log for what changed on the live site, or who changed it
- DRIFTPlugin versions drift between environments, no lockfile to pin them
- SSHComposer packages need SSH the host does not give you
- ✗FTP into prod, edit the theme in place
- ✗Snippets pasted into the admin
- ✗"which plugin version is on staging?"
- ✗DB export to move anything
- ✓git clone, edit, git push
- ✓Snippets and hooks as .php files
- ✓Versions pinned in loopress.json
- ✓Content stays put, only code moves
Declare the desired state. Loopress reconciles.
A versioned file describes how a resource should look: a hook, a plugin version, a Composer dependency, an API route, an app bundle. Loopress diffs that file against the live site and applies only what changed. The same loop for every resource, and never your content or your database.
One resource at a time, all in Git.
Each Loopress feature is one kind of resource: a file that describes a desired state, and a command that reconciles it with the site.
Hooks
In progressDeclare actions and filters as PHP 8 classes with attributes. Loopress loads and wires each file onto native add_action / add_filter: no admin paste box, no runtime of its own. The durable home for behavior you want to keep.
use Loopress\Hook\On;
class PriceFormatter
{
#[On('woocommerce_get_price_html')]
public function suffix(string $html): string
{
return $html . ' incl. VAT';
}
}Plugin Lockfile
Declare plugin versions in loopress.json, like a package.json for WordPress. lps plugin pull merges what's actually live into your manifest instead of overwriting it, so drift never turns into a fight.
"plugins": {
"woocommerce": "9.4.2",
"contact-form-7": "6.0.5",
"fluent-crm": "3.1.6"
}Composer without SSH
Search and install any Packagist package from the WordPress admin, no terminal, no SSH. Every install is checked: known CVEs flagged, PHP version mismatches caught before they break anything.
Download Loopress Full↓Search: tcpdf✓ tecnickcom/tcpdf found on Packagist> Install✓ Installing tecnickcom/tcpdf ^6.7✓ Autoloader updated in wp-content/loopress/
Apps
Version a Vue, React or Svelte front-end alongside the rest of the config. Your CI runs the build, lps app push ships the dist/ output over the REST API, and a shortcode mounts it into any page.
loopress.app.json
dist/ # your build output
index.html
assets/index-9a597e0d.jsAPI Routes
Ship a REST API for your headless front-end as version-controlled PHP files, one class, one method per HTTP verb, wired onto native register_rest_route(). A broken route is skipped and logged instead of taking down the rest of your API.
class WebhookHandler
{
public function post(): array
{
return ['received' => true];
}
}Snippets
Interop with Code Snippets and WPCode. Pull existing snippets to .php files for a one-off edit, or to move them into Git on the way to hooks. Same pull, edit, push loop, no database dump.
<?php
- // remove_action('wp_head', ...);
+ remove_action('wp_head', 'print_emoji_detection_script', 7);
+ remove_action('wp_print_styles', 'print_emoji_styles');
+ remove_filter('the_content_feed', 'wp_staticize_emoji');Official CI configs
Bootstrap a full, disposable WordPress instance in GitHub Actions or GitLab CI and run lps against it in one step: not a mock, ready for real Playwright e2e tests, with database snapshots between test groups.
steps: - uses: actions/checkout@v4 - uses: loopress/setup-ci@main - run: lps push
Secure by default, not by configuration.
Installing Composer packages without SSH, and wiring hooks and REST routes from Git, are exactly the kind of features a senior developer should be suspicious of. Here is what is actually enforced, and where the trust actually sits.
Official WordPress auth, nothing proprietary
Every command authenticates with a WordPress Application Password, the same mechanism WordPress core has shipped since 5.6. Revoke it from Users → Profile at any time and access stops immediately, no Loopress involvement required.
Snippets: trust stays with the plugin you already run
For snippets, Loopress touches neither storage nor execution. It pushes to Code Snippets or WPCode, established plugins with years of production use around running PHP from the admin. You inherit their hardening and their track record, not a new one.
Hooks and API Routes: native primitives, no runtime of our own
Loopress loads and wires each file with its own loader and Composer resolution, then execution runs through add_action, add_filter and register_rest_route. The code runs exactly as if you had written it by hand in a plugin. The shape is constrained too, one class, one method per hook or verb, so it audits better than an arbitrary blob of PHP.
API routes are admin-only by default
A route deployed via lps api requires the manage_options capability unless the file explicitly opts into something else with a permission() method. Nothing is public unless you say so.
Reviewed before it runs
Every hook, every route, every Composer dependency is a file in your Git repository before it is ever live on WordPress: no plugin you didn't read, no code that skipped a pull request.
Fits into the tools you already use.
Built for teams running many client sites.
If you maintain a dozen WordPress sites you did not all build, the problem is not any one of them. It is that none of them are reproducible, and every prod change is a bet.
Onboard a site in minutes
git clone, lps push, and a new machine matches the client's setup. No FTP archaeology, no manual DB export to hand around.
A git log that means something
History on the code and config that actually breaks sites, not buried under thousands of content revisions. You can see who changed what, and when.
The end of "I'll just fix it in prod"
Local stops being the slow path. Testing a change first becomes the fast option, so it actually happens.
Diffs and rollbacks you can trust
The scope is structured and stable, so a diff is readable and a rollback does what you expect. Content is never in the blast radius.
Built in the open. Shaped by the community.
The CLI and the plugin are open source. Leave your email to follow along and get notified when things move.
No spam. No marketing. Just product updates from the team.