DEV Community: jean-smaug

I Deleted 5,000 Lines of a Feature That Worked

jean-smaug — Tue, 27 Oct 2026 00:00:00 +0000

Loopress has one rule: it versions configuration, never content. Field groups, menus, post types, options, code. Not posts, not pages, not the things editors type into wp-admin every day.

For months, one module broke that rule, and I didn’t notice, because it worked. I found out while writing the docs for a different feature, when the example I picked was a setting the old module was supposed to own.

The SEO module

lps seo pull read everything Rank Math or Yoast stored and wrote it as JSON: the site-wide title templates, every post’s SEO meta, every redirect. lps seo push sent it back. It had a diff, a rollback, unit tests, an end-to-end suite running against both plugins, and a guard refusing to run when both plugins were active at once. It was in the first sentence of the Loopress Light listing on WordPress.org and on the homepage.

Building it took a few days. The project’s structure was already set, and Claude Code did most of the typing. By every metric I usually look at, it was a finished feature.

I just never really used it in production. And Loopress is young: as far as I know, nobody else did either.

The module that made me look

The more time I spent in the WordPress ecosystem, the more I saw how much of WordPress core already fits Loopress’s rule, with no third-party plugin involved. Options came first: lps option add <name> tracks a single wp_options row as a file in Git.

Its docs needed a realistic example, and the first one that came to mind was wpseo_titles, Yoast’s settings row. That’s when it clicked. One of the SEO module’s jobs had just become a one-liner of another command. So I went to check what the rest of it was doing.

What it actually put in Git

I opened the seo/ folder of the site Loopress was born on, my sister’s French tutoring site, and read it file by file instead of trusting the green checkmarks.

80 files of per-post meta. In all 80, a rank_math_internal_links_processed flag: an internal marker Rank Math sets for itself. In 72, a rank_math_seo_score: a number Rank Math computes. In 71, a rank_math_analytic_object_id: a row id in one database, which means nothing on another environment, and pushing it there quietly breaks the link. Robots directives stored as serialized PHP strings.

What a human had actually written: 4 descriptions, 1 title, 9 focus keywords. And all of it belonged to a post, which makes it content, edited by whoever edits that post.

27 redirect files, each carrying a hit counter and two timestamps, so every pull produced a diff nobody had caused, and every push could overwrite live counters on production. Targets were absolute production URLs. Every 410 became a file named after its database row id, N-redirect.json.

And one settings.json: the title templates and schema defaults. Real configuration, finally. It was one row in wp_options, exactly what the option module now tracks. So the only part of the SEO module that respected the rule was a duplicate of the newer command:


lps option add rank-math-options-titles # Rank Math

lps option add wpseo_titles # Yoast SEO

Everything else was content dressed up as configuration, plus the code needed to make that look safe: an adapter per SEO plugin, raw SQL against Rank Math’s redirect table, a check that redirect targets stay on the site, active-content stripping on every string. Each of those existed because the module was doing something Loopress shouldn’t do in the first place.

What removing it cost

It wasn’t free, and pretending otherwise would be dishonest.

A headline feature. The WordPress.org listing, the homepage and the comparison pages all said “SEO”. Now they don’t.
Redirect versioning. Some people will want it. It’s still content: redirects are created by editors in wp-admin, and they belong to the site, not the repository.
Anyone who did use it. lps seo is gone since 0.30.0. Migrating is one command: track the option above, then delete seo/.

The removal itself was easy: one pull request, 110 files touched, close to 5,000 lines deleted for 248 added. Not one folder, though. A headline feature spreads into the plugin, the CLI, the MCP server, the docs, the homepage and the end-to-end tests. Easy to remove is not the same as contained.

What it gave back: a plugin that no longer reads or writes another plugin’s database tables, one less thing to explain on the homepage, and a rule that is true again, with no “except SEO” footnote.

The part I want to remember

Nothing was broken. No bug report, no failing test, no angry user, and no daily use of my own that could have shown me. A feature that is clearly wrong gets removed eventually. A feature that works, is tested, and doesn’t fit the product’s rule can stay forever, because it never gives you a reason to look at it.

With an AI agent, building a feature like this takes days, not weeks. That makes the build the cheap part. The expensive part is deciding whether a feature belongs, and a working, tested module makes that question easy to skip.

What finally got me to look was a newer feature overlapping it, and then opening the real files on a real site. Not the fixtures, not the tests: the folder a user would actually commit. If most of what’s in there wasn’t written by a person, it isn’t configuration, and it doesn’t belong in Git.

The modules built around the removal all come from WordPress core: post types, taxonomies, post meta, user roles, block patterns. I can’t say what Loopress will need next. I do have a much sharper idea of what it is, and what it isn’t.

Tracking SEO plugin settings is covered in the Options reference.

When a WordPress REST Route Shouldn't Return JSON

jean-smaug — Mon, 26 Oct 2026 00:00:00 +0000

It started with a student on my sister’s tutoring site asking for the blog posts as PDFs. A route that renders a post to PDF is a few lines with Dompdf. Then I started imagining the next ones: an Excel export of orders, a QR code for an event ticket, a calendar feed, a Markdown version of a post for an AI crawler. None of them wanted to answer in JSON.

The WordPress REST API is built around JSON. Return an array from a callback, WordPress serializes it, sets Content-Type: application/json, done. It’s such a good default that it becomes the only answer, and then you find yourself base64-encoding a PDF into a JSON field so a browser can… decode it back into a PDF.

The question that decides the response shape isn’t “what does the route produce”. It’s who calls it, and what do they do with the answer. Across the cookbook recipes I’ve built with custom API routes, four shapes cover everything.

Shape 1: JSON, for code that reads fields

A frontend fetch(), a mobile app, a CI script: the caller parses the response and picks fields out of it. That’s what JSON is for, and what a route gives you by returning an array or a WP_REST_Response:


public function get(WP_REST_Request $request): array

{

    return ['id' => 482, 'status' => 'valid'];

}

Nothing to decide here. It’s the default because it’s the right answer most of the time.

Shape 2: a file inside JSON, as a data URI

Sometimes the caller is still code, but what it wants is a small image to drop into the page: a resized thumbnail, a ticket’s QR code. The route can put the image in a JSON field as a data: URI:


return new WP_REST_Response([

    'data_uri' => 'data:image/png;base64,' . base64_encode($result->getString()),

]);

The frontend sets it straight as <img src>, no second request, and the JSON envelope can carry other fields next to it (dimensions, an expiry). I use this for ticket QR codes and on-the-fly image resizing.

The limits are real, so keep it for small files. Base64 makes the payload a third bigger than the raw bytes. The browser can’t cache the image on its own, only the whole JSON response. And a human can’t open the URL and see the image, they see a wall of base64. My QR code is a 519-byte PNG, 737 bytes as JSON: fine. A 2 MB photo as JSON is not.

Shape 3: raw bytes, with your own headers

When the caller isn’t your code at all, JSON is simply wrong:

A browser navigating to the URL , from a “Download as PDF” link: it needs Content-Type: application/pdf and a Content-Disposition header, or it shows gibberish.
A calendar app subscribed to a feed : it expects text/calendar, and never sends anything WordPress could negotiate on.
curl -o report.xlsx in someone’s cron job: it writes whatever bytes arrive to disk.
An AI crawler or an llms.txt consumer : it wants text/markdown, not HTML in a JSON string.

A route verb method doesn’t have to return anything. It can send its own headers, echo the body, and stop:


public function get(): void

{

    // ... build $xlsxBytes

    header('Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet');

    header('Content-Disposition: attachment; filename="orders.xlsx"');

    echo $xlsxBytes;

    exit;

}

That’s the whole trick, documented as streaming a file instead of JSON. The post to PDF recipe, the one the student asked for, works this way, and so does WooCommerce orders to Excel.

Shape 4: a redirect, when the file already exists

That 2 MB photo, or a PDF already sitting in the media library, doesn’t need to travel through PHP at all. The route decides which file the caller gets, checks they’re allowed to have it, and points them at it:


public function get(WP_REST_Request $request): WP_REST_Response|WP_Error

{

    $url = wp_get_attachment_url((int) $request->get_param('attachment_id'));

    if (!$url) {

        return new WP_Error('not_found', 'No such file.', ['status' => 404]);

    }

    return new WP_REST_Response(null, 302, ['Location' => $url]);

}

The web server sends the bytes, with its own caching and range requests, and the route stays a normal REST response: no exit, nothing skipped. Keep the WP_Error: without it, an unknown id answers a 302 with an empty Location, which I only caught by calling the route on a real site.

What to know before shipping one

Checked on a real site, and in how Loopress loads route files:

Errors can still be JSON. Return a WP_Error before the headers go out and WordPress answers it like any other REST error, {"code":"not_found",...,"data":{"status":404}}. Only the success path is raw. A caller that gets a 404 shouldn’t have to parse a PDF to find out.
A throw is a JSON 500, not a fatal. An uncaught exception in a verb method, raised before your headers go out, comes back as {"error":"Internal error"} with a 500 status, and the rest of the site keeps working.
Permissions work the same. permission() and #[Permission] are checked before the verb method ever runs, raw output or not. My Excel export is admin-only, the curl in its video authenticates with an Application Password like any other REST call.
WordPress’s own REST headers are already there. A raw response still carries Access-Control-Expose-Headers and the API Link header, WordPress sends those before your method runs. What exit skips is everything after it: the JSON serialization, and the rest_post_dispatch filters other plugins might hook.
A route-wide headers() method doesn’t run on a raw response. Loopress applies headers() when WordPress serves the response, which is after your verb method returns. A method that calls exit never returns, so a CORS header declared there won’t be on the download. Send it with header() inside the verb method itself, next to Content-Type.
A raw route doesn’t belong in the discovery index. /wp-json/{namespace} lists every route as a REST resource with its methods and args, which says nothing useful about an endpoint that answers with a PDF or a calendar feed. #[Hidden] on the class keeps the route out of that index, and it keeps dispatching exactly as before.

Choosing, in one line each

The caller	The shape
Your code, reading fields	JSON
Your code, showing a small image	data URI in JSON
A browser link, a download, `curl -o`	raw bytes + `Content-Disposition`
A calendar app, a feed reader, a crawler	raw bytes + the format’s own `Content-Type`
Anyone, for a file that already exists	a 302 to the file

The mistake isn’t picking the wrong one of these. It’s never asking the question, and shipping JSON to a calendar app because that’s what the REST API does by default.

Try it on your own site: one PHP file in api/, one lps api push.


npm install -g @loopress/cli

Custom API routes and Composer dependency management are Loopress Full features, free. Writing Route Files covers the rest: dynamic segments, verbs, permissions, CORS.

Astra vs Twenty Twenty-Five: 34% Fewer Queries on a Real Site

jean-smaug — Wed, 30 Sep 2026 00:00:00 +0000

Native French Teacher is my sister’s online French tutoring business, and the site Loopress started from. It launched last year on Astra with the Spectra blocks plugin. I recently rebuilt it on Twenty Twenty-Five , the default block theme, with a new design along the way, using Loopress to manage the pages, templates and snippets from a Git repo.

I didn’t do it for speed. I did it so the site would live in a repository. But I had Query Monitor open before and after, so here is what it measured.

Astra was the right call, at first

Let’s be fair to Astra. When you launch a site for a non-technical person, it’s hard to beat:

A header and footer builder where you drag a logo, a menu and a button into place.
Global colors and typography in the Customizer, with a live preview.
Per-page layout options : hide the title, go full width, remove the sidebar, from a panel in the editor.
Starter templates and Spectra’s blocks, so a decent-looking page takes minutes.

Twenty Twenty-Five on its own has none of that polish. It’s a clean block theme with a Site Editor, and the Site Editor saves everything in the database, just like Astra’s Customizer does. Swap one for the other and you’ve traded features for speed, but you still can’t answer “who changed the header, and what did it look like before?”

That’s the gap Loopress fills.

How I measured

Same Hostinger server, same PHP, same plugin stack apart from the theme and Spectra.
Not the same pages: the rebuild came with a redesign. That matters most for what the browser downloads (images, fonts, layout), much less for the server work, which is mostly WordPress, the theme and the plugins.
Homepage only, logged in as admin (Query Monitor needs that, so the admin bar is included in both runs).
Several page loads per state, keeping the median : cold loads (first request after a while, OPcache and internal caches not warm) and warm loads (right after). The screenshots below are the loads closest to that median.
No page cache and no persistent object cache in either case. The site runs LiteSpeed Cache, but it doesn’t serve logged-in users, so these are the numbers a logged-in visitor actually gets. The query count barely moves between cold and warm, so the difference between the two is PHP warm-up, not a cache skipping work.

It’s a live site, not a lab, so small differences are noise. The large ones (queries, scripts, autoload) are not.

The homepage, side by side

Metric	Astra	Twenty Twenty-Five	Change
Generation time, cold	2.61 s	1.92 s	-26%
Generation time, warm	0.69 s	0.50 s	-28%
Peak memory, cold	78.5 MB	65.7 MB	-16%
Peak memory, warm	59.5 MB	47.9 MB	-19%
Database queries, cold	274	182	-34%
Time in database, cold	55 ms	38 ms	-31%
Enqueued scripts	65	25	-62%
Enqueued styles	52	49	-6%
Object cache hits	6,489	4,137	-36%

Astra, cold load: 2.61 s, 274 queries, 65 scripts.

Twenty Twenty-Five, cold load: 1.92 s, 182 queries, 25 scripts.

Astra, warm load: 0.69 s. The query count barely moves, so no cache is skipping work.

Twenty Twenty-Five, warm load: 0.50 s, same 182 queries.

The biggest single number is scripts: 65 down to 25. That’s mostly Astra and Spectra’s own scripts no longer being enqueued. Styles barely moved, because most of them come from plugins (forms, booking, quiz), not from the theme.

Where the time went

Query Monitor’s timeline shows how long each WordPress hook took on a warm load.

Hook	Astra	Twenty Twenty-Five
`plugins_loaded`	141 ms	138 ms
`after_setup_theme`	28 ms	26 ms
`init`	91 ms	78 ms
`wp`	32 ms	6 ms
`template_redirect`	16 ms	51 ms
`wp_head`	81 ms	31 ms

Astra: wp_head takes 81 ms.

Twenty Twenty-Five: wp_head down to 31 ms, template_redirect up to 51 ms, plugins_loaded unchanged.

Three things stand out:

wp_head dropped from 81 ms to 31 ms. Most likely Astra’s dynamic CSS and inline configuration, built at runtime on every request. A block theme ships its styles from theme.json, and WordPress only outputs the CSS for blocks actually on the page.
template_redirect went up, from 16 ms to 51 ms. Not everything got faster. Something hooked there now does more work, and it’s on my list to look at with the per-component view.
plugins_loaded didn’t move. At 140 ms it’s the largest single chunk of the request, and changing the theme can’t touch it. The remaining plugin stack is now the thing to optimize, not the theme.

The database got lighter too

Every WordPress request loads all autoloaded options into memory, whether the page needs them or not. Astra and Spectra stored a lot of their settings that way.

	Astra	Twenty Twenty-Five
Autoloaded options size	1,013 KB (946 options)	519 KB
Big autoloaded options	3	0
Database size	176 MB	160 MB
Site Health	Should be improved, 1 critical issue	Good

Astra: 1,013 KB of options loaded on every request, 3 of them flagged as big.

Twenty Twenty-Five: autoload down to 519 KB, no big options left.

Removing the theme and its companion plugin, then cleaning up what they left behind, halved the autoloaded data. That was also the only critical issue in Site Health (“Autoloaded options could affect performance”), and it’s gone.

Astra: the autoloaded options are the one critical issue in Site Health.

Twenty Twenty-Five: Site Health is back to Good.

What about visitors?

I also ran PageSpeed Insights before and after, and it showed no major change. That’s not surprising: the site sits behind LiteSpeed Cache, and for visitors that’s the real game changer. Most pages are served straight from the cache, so the PHP work measured above rarely runs for them.

So why care about server time at all? Because not every request can be cached:

Logged-in users. A page cache only works for anonymous visitors. Once someone is logged in, every page they open is rendered by PHP, theme included, which is exactly what the numbers above measure. The site is going to have more logged-in users, so a theme that does less work per page is worth more every month.
Cache purges. Every purge, including the one after each deploy, means the next visitor gets an uncached page. PHP is usually still warm at that point, so that’s the warm render: 0.69 s on Astra, 0.50 s now.
Custom API routes. With Loopress you can add API routes to WordPress, and the ones that return personal or changing data can’t be cached. They don’t render a template, but they still boot WordPress, autoloaded options and all.

The cache hides the difference for anonymous visitors today. The lighter stack pays off for everything the cache can’t cover.

Twenty Twenty-Five alone is fast. With Loopress, it’s also manageable

The page is about 30% faster on the server, uses a fifth less memory, runs a third fewer queries and ships 40 fewer scripts. None of it came from a caching plugin or a server upgrade: it came from removing layers.

But a lean theme is only half the story. What made me comfortable dropping Astra is that everything it gave me through panels, Loopress gives me through files:

What Astra gave me	Twenty Twenty-Five + Loopress
Header and footer builder	Template parts as block markup in `parts/`, pushed into a child theme with `lps template push`. The parent theme stays untouched and keeps its updates.
Per-page layout options	Custom page templates in `templates/`, picked per page with a `template:` header. A bare landing page is one file.
Starter templates and Spectra blocks	Pages written as plain HTML files in the repo, rendered by the theme, locked in wp-admin so Git stays the source of truth.
Custom code in `functions.php` or a snippet plugin	Hooks and snippets as PHP files in Git.

That split doesn’t take the editor away from my sister. She still writes her blog posts in the WordPress admin, and they live in the database like any other content. What moved to Git is the structure around them: templates, landing pages and code. She now also edits the site from Claude Desktop.

Astra’s features are good, but they live in the database, next to the content, invisible to Git. On Twenty Twenty-Five with Loopress, the same decisions are files: I review them, diff them, push them to staging first, and roll them back when something goes wrong. The server does less work and the design got a history.

That’s the combo I’d pick for the next site: the default block theme for the performance, Loopress for everything Astra used to do in a panel.

Still to do: install a persistent object cache (Redis is on the server, just not wired up) and look at that template_redirect regression.

→ Get started with the plugin or the CLI

Your WordPress Hooks Belong in Git, Not functions.php

jean-smaug — Thu, 10 Sep 2026 00:00:00 +0000

You want every blog post to end with a newsletter box. The code is four lines:


add_filter('the_content', function (string $content): string {

    if (!is_singular('post')) {

        return $content;

    }

    return $content . do_shortcode('[newsletter_form]');

});

Writing it took a minute. The question that eats the rest of the hour: where does it go, and how does it get to staging and production without someone pasting it into an admin textarea?

Where hook code lives today

functions.php. Fastest to write, tied to your theme. Switch themes, lose the hook. A year later it’s 900 lines of unrelated callbacks nobody wants to touch.

A site-specific plugin. The clean answer, and now your four lines come wrapped in a plugin header, and you still need a way to get that plugin onto each environment and know which version runs where.

A snippets plugin. Live in seconds, versioned never. The callback sits in the database, edited through a textarea, invisible to git log, invisible to code review. Someone tweaks the priority, something downstream breaks, and there is no diff to point at.

The hook logic is never the hard part. The delivery is.

One file, one class

With Loopress Full installed, a hook is a plain PHP file in your repo’s hooks/ directory:


<?php

declare(strict_types=1);

use Loopress\Hooks\Attribute\Filter;

class ContentHooks

{

    #[Filter('the_content', priority: 20)]

    public function appendNewsletter(string $content): string

    {

        if (!is_singular('post')) {

            return $content;

        }

        return $content . do_shortcode('[newsletter_form]');

    }

}

Save it as hooks/content-hooks.php and deploy:


lps hook push

That is the whole thing. No plugin header, no add_filter call, no registration array. One class per file, named however you like (the name is read from the file’s own tokens, not its filename), and any public method carrying an #[Action], #[Filter], or #[Cron] attribute gets wired up. priority and acceptedArgs map straight onto the arguments you already know from add_filter().

A #[Filter] method returns the value it receives, modified or not. An #[Action] returns nothing:


use Loopress\Hooks\Attribute\Action;

class CacheHooks

{

    #[Action('save_post')]

    public function purgeOnSave(int $postId): void

    {

        wp_remote_post('https://cdn.example.com/purge', [

            'body' => ['path' => get_permalink($postId)],

        ]);

    }

}

A single class can carry as many of these as it wants, actions and filters mixed freely. Group them by what they touch, not by hook type.

Cron, without wp-config surgery

The same file format runs scheduled work. #[Cron] takes a WordPress recurrence name:


<?php

declare(strict_types=1);

use Loopress\Hooks\Attribute\Cron;

class InvoiceCleanup

{

    #[Cron('daily')]

    public function purgeExpired(): void

    {

        // delete invoice drafts older than 30 days

    }

}

recurrence is any schedule WordPress knows: the built-in hourly, twicedaily, daily, or a custom one registered through the cron_schedules filter. The event is scheduled the first time the method is seen and left alone after that, so pushing the same file twice does not stack duplicate jobs.

One sharp edge worth knowing up front: changing #[Cron('daily')] to #[Cron('hourly')] later does not reschedule the running event. Clear it yourself with wp_clear_scheduled_hook() if you need the new interval to take effect now. If another part of your code needs to trigger the same job on demand, name the action yourself and do_action() it:


#[Cron('daily', hook: 'acme_invoice_cleanup')]

public function purgeExpired(): void { /* ... */ }

Built to not break your site

A hook has no URL and no permission check of its own. Once pushed it runs automatically every time WordPress fires the hook it is bound to, from init on every page load to save_post on every save, with nothing gating it. A mistake here affects everything that hits that hook, not one endpoint. Loopress keeps that contained:

lps hook push syntax-checks every file server-side and rejects broken PHP with the actual parse error, before anything is written. It also enforces one declare(strict_types=1);, exactly one class, and no class-name collision with another plugin.
If a hook method throws at runtime, it is caught and logged rather than left to white-screen the site. An #[Action] simply does not run that time. A #[Filter] falls back to the original, unfiltered value.
Files are protected from direct HTTP access. Pull them back and you get exactly the source you pushed.

Because these files call WordPress functions from a repo where WordPress is not installed, set up editor stubs once for autocomplete and static analysis. The same page covers the loopress/php-attributes Composer package, which resolves the #[Action], #[Filter], and #[Cron] classes your IDE is about to ask about.

Hooks your repository declares

Because hooks are plain files, the workflow is the one you already have:


lps hook pull # mirror what's on the site locally

git checkout -b add-newsletter-box # branch, edit, open a PR

lps hook push --dry-run # see exactly what would change

lps hook push # deploy

lps hook list prints what is live on a site. lps hook diff shows what differs between your local files and an environment, or between two environments, and it rolls up into the aggregate lps diff --only hook.

Across environments it is the same command with --env:


lps hook push --env staging

# looks right in staging

lps hook push --env production --yes

--yes is required outside a terminal because pushing to an environment named production asks for confirmation first. A local .php file whose hook no longer exists on the site is removed on the next pull, so the directory stays an honest mirror.

Hooks stop being something you wire up on a site and become something your repository declares.

Hooks ship with Loopress Full, the free full edition of the plugin. Loopress Light does not include them.


npm install -g @loopress/cli

The documentation covers the full attribute reference, the cron scheduling model, and the push validation rules.

How Loopress Light Got Into the WordPress.org Directory

jean-smaug — Sun, 06 Sep 2026 00:00:00 +0000

Loopress Light is now on the wordpress.org plugin directory. You install it from Plugins, Add New in any WordPress admin, and it updates itself from there.

Getting it accepted took an initial rejection, a failed appeal, and removing the feature the plugin was first built around. The Composer side of that story is here. This is the snippet sync half, mostly in the review team’s own words.

The first no

We submitted Loopress Light on 16 July 2026. That version carried code snippet sync: the CLI could push and pull Code Snippets and WPCode entries over a REST API, so snippets could live in Git alongside the rest of a project.

The rejection came back within a day, and it was categorical:

Your plugin has been rejected because we are not accepting plugins of this nature in most cases.

Script insertion plugins are amazing and powerful. They’re also incredibly dangerous and require a high level understanding of sanitization, security, and usage.

The directory rejects this whole category by default. Not this implementation, the category.

The appeal, and why it lost

We wrote back the next day, arguing the mechanism was narrower than “an API that inserts scripts”:

Loopress Light never executes snippet code. It moves a snippet’s fields (name, code, type, location) into Code Snippets or WPCode through that plugin’s own API. Storage, sanitization, and execution all stay inside the plugin the site owner already installed for exactly that.
It is inert on its own. If neither Code Snippets nor WPCode is active, every endpoint returns a 400 and the plugin does nothing.
Access uses WordPress core’s own Application Passwords flow. The site owner approves the CLI on WordPress’s own authorization screen and can revoke it from their dashboard at any time. We do not ship an auth scheme.
Every write is gated by current_user_can('manage_options'), the same capability already required to edit a snippet by hand.

The answer did not move:

The plugin provides REST endpoints through which arbitrary PHP, JavaScript, CSS, and other code can be remotely submitted and stored in Code Snippets or WPCode, where that code can then be executed. It therefore facilitates remote deployment of arbitrary executable code, even though the final execution occurs in another plugin.

And on the authentication argument specifically:

Application Passwords and manage_options checks establish who is authorized to make the request. They do not validate that the submitted code is safe, nor do they remove the inherent risks of providing an arbitrary-code deployment mechanism.

We had also pointed at the snippet plugins already in the directory. That got a direct response too:

Those plugins were approved years ago, before real-world experience demonstrated the risks of this model. Removing established plugins now could cause greater harm to their existing users, but their continued presence is not a basis for accepting new plugins that provide or facilitate the same capability.

The takeaway: on this pattern, the directory does not weigh how good your authentication and capability checks are. The ability to deploy arbitrary code remotely is the thing they reject, wherever the execution finally lands.

Asking instead of guessing

The rejection ended with a specific instruction: do not resubmit as is, and

A materially different approach, such as providing only predefined, non-modifiable, thoroughly vetted operations rather than accepting arbitrary code, would need to be considered instead.

We had recently built ACF and SCF configuration sync into the CLI: push and pull custom field groups, post types, taxonomies, and options pages as JSON. That is configuration data, not executable code. Rather than strip the plugin and resubmit blind, we described the new flow to the team, an external caller hitting a REST endpoint that maps JSON to ACF’s own API and nothing else, and asked whether it would clear the same bar.

Synchronizing ACF/SCF configuration represented as JSON would not, by itself, raise the same arbitrary executable-code concern as the rejected snippet synchronization feature. However, we cannot pre-approve a plugin from a description or workflow diagram.

They listed what a full review would still check: that all snippet and arbitrary-code functionality was gone, that the synced data could not carry PHP, JS, CSS, or HTML, and that every REST endpoint had authentication, capability checks, validation, and sanitization. Not a green light, but enough to build against.

The rebuild

Snippet sync came out of the edition that ships to wordpress.org. Not disabled behind a flag: the code is physically absent from the zip, and a CI step unzips the built artifact and greps it for residue. The Composer post covers the one-codebase, two-artifact build in detail.

Snippet sync, WPForms sync, custom REST API routes, and Composer dependency management all live in Loopress Full now, distributed from loopress.dev, never the directory. Loopress Light is what was left: ACF and SEO configuration sync, plain JSON, over a loopress/v1 REST API restricted to administrators.

Then the ordinary review

The resubmission cleared the policy question and hit a normal technical-issues pass. Two items:

Two inline <style> blocks echoed straight into the admin page. Moved to wp_enqueue_style and wp_add_inline_style.
The top-level admin menu registered at position 6, sitting up among Posts and Media. Dropped to 100, below Settings.

Both were fixed in one commit, and after that Loopress Light was approved.

Worth knowing if you are in this queue now: the review emails are partly automated (the team says so in the footer, and that no personal data is shared with the AI), and they ask for short replies that do not enumerate your changes, because they re-review the whole plugin regardless.

Which edition you want

If you sync ACF field groups and SEO settings, install Loopress Light from the directory and let it update itself.

If you also need snippet sync, WPForms sync, version-controlled REST API routes, or Composer packages managed from the admin, that is Loopress Full, a separate download, for the reasons above.

Thanks

The review team was direct at every step, including the ones where the answer was no, and the citations were specific enough to act on each time. Answering the ACF question before a full resubmission is the part we are most grateful for. It turned a blind rebuild-and-hope into a scoped piece of work.

Composer Packages in a WordPress REST API Route

jean-smaug — Thu, 06 Aug 2026 07:00:00 +0000

Two Loopress Full features, each useful on their own: Composer dependency management installs any Packagist package straight from the WordPress admin, and Custom API Routes turn a version-controlled PHP file into a live REST endpoint, deployed with the Loopress CLI once it’s set up for the project. They were built separately, but not independently: a route file can use any package Composer installed, no extra step in between.

Why reach for a package at all

WP_Query (or get_posts()) already covers anything the site itself holds: posts, pages, meta, taxonomies. A Composer package earns its place in a route the moment a request needs something WordPress doesn’t have on its own: a currency rate from another service, a PDF built for a download link, a CSV parsed from an upload, a payload checked against a validation library before it touches the database. Once a route file can use a package, all of that is ordinary PHP, not a special case.

This matters most when WordPress is used as a headless CMS: a separate frontend (Next.js, Astro) consuming wp-json and rendering nothing of its own. There’s no theme, no template, nowhere else for that logic to live, every capability a request needs has to be in the route itself. That’s exactly where a route being limited to what WP_Query already knows would start to hurt.

The line you don’t have to write

Using a Composer package anywhere else in WordPress, a snippet, functions.php, means loading the autoloader yourself first:


require_once WP_CONTENT_DIR . '/loopress/vendor/autoload.php';

use GuzzleHttp\Client;

That line has to be there, in every file that touches a package, every time. Miss it and you get a fatal “Class not found” the moment the file runs.

In a route file, it’s not there

A Custom API Route already goes through Loopress’s own loader before your code executes. That loader resolves the same wp-content/loopress/vendor/ autoloader lps composer push fills, once, before your route class is even loaded, so a route file just uses a package like normal PHP:


<?php

declare(strict_types=1);

use GuzzleHttp\Client;

class Webhook

{

    public function post(): array

    {

        $client = new Client();

        // ...

        return ['ok' => true];

    }

}

No require_once, no path to get wrong, no difference between this and any Composer project you’ve worked on. The full reference is in Writing Route Files.

If the package isn’t there

A corrupted or missing wp-content/loopress/vendor/autoload.php is caught and logged once, before any route file loads, every other route still registers normally. A single package missing from an intact vendor/, Guzzle never installed, say, isn’t something Loopress catches on your behalf: it surfaces as an ordinary PHP error on that request, the same as calling any undefined class anywhere else in PHP. WordPress serves each request in its own process, so the error stays contained to the one endpoint that hit it, everything else on the site keeps working, but push the package before you push the route that depends on it.

What this opens up

Once the autoloader is a non-issue, the interesting question stops being “can I use a package here” and becomes “what’s worth building with one.” A route enriching WordPress content with a live external rate. One generating a file on demand instead of storing it. One validating a webhook payload before it’s trusted. Each of those deserves its own walkthrough with real code and a real deploy, not a paragraph here, so that’s what the rest of this series is for.

Both features ship with Loopress Full, free:


npm install -g @loopress/cli

Composer dependency management covers installing and auditing packages from the admin. Writing Route Files covers everything a route can do beyond this: authentication, CORS, the security model.

Version Control Your WordPress Code Snippets

jean-smaug — Wed, 29 Jul 2026 00:00:00 +0000

If you use Code Snippets or WPCode, you’re probably editing your PHP functions directly in the admin panel. Click the snippet, make the change, save. Done.

It works. Until it doesn’t.

Someone edits a snippet and breaks something. You don’t know what changed. There’s no history. You either remember what it looked like before, or you don’t. There’s no git log, no diff, no blame.

How people try to solve this today

The current options aren’t great.

Option 1: WPCodeBox or Code Snippets Cloud These tools offer built-in versioning: you can see a history of changes and revert. It works, but it’s locked inside their platform. Your code history lives in their database, not in your repo, and it doesn’t integrate with your existing Git workflow.

Option 2: Keeping snippets in your theme’s functions.php This at least puts the code in a file you can version. But it ties snippets to your theme, means they disappear on theme switch, and turns functions.php into an unorganized dumping ground.

Option 3: A custom plugin Some agencies build a site-specific plugin to hold all their custom code. This is better: it’s version-controlled and theme-independent. But it requires setup for every project and doesn’t give you a clean way to sync between environments.

None of these feel like a real developer workflow.

The Loopress approach

Loopress treats your snippets as plain files in a Git repository. Pull them down from WordPress, edit them locally, push them back. Every change is a commit.

Setup

Install the Loopress CLI:


npm install -g @loopress/cli

Configure your project:


lps project config

It asks for a project name, an environment (production, staging, local, or a custom name), and your WordPress URL. By default it then opens your browser to authorize and creates an Application Password for you automatically, no copy-pasting a generated password. If that flow can’t complete, it falls back to asking for a WordPress username and an Application Password you generate yourself.

Pull your snippets


lps snippet pull

This creates a snippets/ directory with one .php file and one .json sidecar per snippet:

snippets/

  1-my-custom-function.php

  1-my-custom-function.json

  2-woocommerce-checkout-tweak.php

  2-woocommerce-checkout-tweak.json

  3-disable-gutenberg.php

  3-disable-gutenberg.json

Each .php file contains the raw snippet code. The .json sidecar stores the metadata (id, name, type, active status, tags) that Loopress uses to identify and update the snippet on WordPress.

Edit locally

Open any file in your editor. Make changes. The feedback loop is your local environment, not the WordPress admin panel.


git add snippets/2-woocommerce-checkout-tweak.php

git commit -m "fix: apply discount code before tax calculation"

Now you have a commit. A diff. A message explaining why. This is reviewable, reversible, and shareable.

Push back to WordPress


lps snippet push

Loopress syncs your local files back to WordPress via the REST API. No FTP, no copy-paste.

If you want to see what would change without actually changing anything:


lps snippet push --dry-run

Working across environments

The real value shows up when you’re working with local, staging, and production environments. Register each one once with lps project config, then target any of them with --env on a single command:

# Pull from production

lps snippet pull --env production

# Test locally, commit changes

# Push to staging first

lps snippet push --env staging

# When ready, push to production

lps snippet push --env production --yes

That trailing --yes isn’t optional flair: pushing to an environment literally named production asks for confirmation in a terminal, and requires --yes to skip that prompt outside one (CI, scripts). --env also takes priority over whatever lps project switch last left active globally, which matters the moment more than one person runs commands against the same project.

Your snippets flow between environments the same way your code does. No database exports, no manual copy-paste.

One thing to keep in mind

Loopress syncs snippets by ID (stored in the .json sidecar). If you pull first, the ID is saved and subsequent pushes update the correct snippet regardless of name changes. Without a sidecar ID, Loopress creates a new snippet. Treat the files as the source of truth once you’re in this workflow.

If this resonates, the next step is lps project config and adding snippets/ to your project’s Git repository. From there, every snippet change is a commit.

Ship a Custom WordPress Endpoint Without Writing a Plugin

jean-smaug — Mon, 27 Jul 2026 07:02:40 +0000

Your JavaScript frontend needs a list of featured products from WordPress. Not the whole REST API surface, not raw post objects with forty fields, just the ten items the homepage carousel shows, shaped the way the frontend wants them.

The endpoint is ten minutes of work: query, map, return. The question that eats the rest of the afternoon: where does that code go?

Where custom endpoints live today

functions.php. Fastest to write, tied to your theme. Switch themes, lose the endpoint. Two years later it's line 1400 of a file nobody wants to scroll.

A site-specific plugin. The clean classic answer. But now your ten minutes of logic come wrapped in a plugin header, a hook, and a registration array:

add_action('rest_api_init', function () {
    register_rest_route('acme/v1', '/featured-products', [
        'methods'             => 'GET',
        'callback'            => 'acme_featured_products',
        'permission_callback' => '__return_true',
    ]);
});

And you still need a way to get that plugin onto the site. And onto staging. And to know which version runs where.

A snippets plugin. Deployed in seconds, versioned never. The code lives in the database, edited through an admin textarea, invisible to Git and code review.

The endpoint logic is never the problem. The delivery vehicle is.

One file, one route

With Loopress Full installed, a custom endpoint is a single PHP file in your repo:

<?php

declare(strict_types=1);

class FeaturedProducts
{
    public function get(): array
    {
        $query = new WP_Query([
            'post_type'      => 'product',
            'meta_key'       => 'featured',
            'meta_value'     => '1',
            'posts_per_page' => 10,
        ]);

        return array_map(fn(WP_Post $post): array => [
            'id'    => $post->ID,
            'title' => $post->post_title,
            'url'   => get_permalink($post),
        ], $query->posts);
    }
}

Save it as api/featured-products.php and deploy:

lps api push

The conventions do all the wiring you saw above. The filename is the route. The class name is the filename in PascalCase. Each public method named after an HTTP verb (get, post, put, patch, delete) becomes that verb's handler. No registration code, no plugin header, no hook.

Now call it

curl https://your-site.com/wp-json/loopress-api/v1/featured-products

{"code":"rest_forbidden","message":"Sorry, you are not allowed to do that.","data":{"status":401}}

That 401 is the feature. A fresh route requires an administrator, the same authentication the Loopress CLI itself uses. Nothing you push is publicly reachable by accident.

For an endpoint another system calls on your behalf, a reporting script, an internal dashboard, a cron job, that default is already the right answer: the caller authenticates with an application password over Basic auth, and you have a protected endpoint without writing a single line of security code.

This feed, though, is meant for the browser. Making it public is a decision, so it's expressed where decisions belong, in the file, in the diff, in code review:

public function permission(): callable
{
    return fn(): bool => true;
}

curl https://your-site.com/wp-json/loopress-api/v1/featured-products

[{"id":231,"title":"Weekender Backpack","url":"https://your-site.com/product/weekender-backpack"}]

One greppable line. A reviewer seeing this diff knows exactly what's being opened to the world, which is not something you can say about a checkbox in an admin screen. The same permission() method takes any callable, so routes that need their own rules, logged-in users only, a capability check, a signed webhook, express them the same way (the docs cover those patterns).

The frontend lives on another domain? Declare CORS headers in the file too, they apply to every request, preflight included:

public function headers(): array
{
    return ['Access-Control-Allow-Origin' => 'https://app.example.com'];
}

Need an HTTP client or an SDK in a route? If the site uses Loopress's Composer integration, your packages are directly available to use in route files. No manual autoloader loading.

Built to not break your site

Deployed code that runs inside WordPress has one non-negotiable requirement: a mistake must stay contained.

lps api push syntax-checks every file server-side and rejects broken PHP with the actual parse error, before anything is written.
A file that still fails at runtime (a class collision with another plugin, a throwing dependency) is skipped and logged. Every other route, and the rest of the site's REST API, keeps working.
Files are protected from direct HTTP access and written atomically. Pull them back and you get exactly the source you wrote.

Endpoints your repository declares

Because routes are plain files, everything you already do with code applies:

lps api pull                  # mirror what's on the site locally
git checkout -b add-feed      # branch, edit, review
lps api push                  # deploy

Different environments? Push the same files to staging first, then production, like the rest of your Loopress-managed configuration. Endpoints stop being something you set up on a site and become something your repository declares.

Custom API Routes ship with Loopress Full, the free full edition of the plugin:

npm install -g @loopress/cli

The documentation covers the complete file reference: request handling, response types, authentication, CORS, namespaces, and the security model.

Installing Composer Packages in WordPress Without SSH

jean-smaug — Fri, 24 Jul 2026 10:59:17 +0000

Cross-posted from the Loopress docs
Loopress is a toolset to make WordPress reproducible and reviewable via Git. Versioned snippets, Composer without SSH, and more coming...

Check Loopress

You need to add a PHP dependency to a WordPress site. Maybe a PDF generation library, a CSV parser, an image manipulation package. Something available on Packagist.

Here's what the standard workflow looks like.

The current workflow

If you're on managed hosting (most clients are):

Check if SSH is available (often it isn't, or it requires upgrading the hosting plan)
If SSH is available: connect, check if Composer is installed, install it if not
Navigate to the WordPress root
Initialize composer.json if it doesn't exist
Run composer require vendor/package
Hope the server's PHP version matches your local environment
Hope the vendor/ directory ends up in the right place
Repeat for every site, every environment

This is assuming nothing goes wrong. In practice, you'll hit permission issues, PHP version mismatches, or a host that simply blocks Composer from running.

The workaround people actually use:

Run Composer locally, then upload the vendor/ directory to the server via FTP or rsync. This works but means you're manually syncing binary files, and the next developer who needs to add a dependency starts from scratch figuring out where everything lives.

Neither option is good.

What Loopress does differently

Loopress Full adds a Dependency Management panel to your WordPress admin. It talks to Packagist, runs Composer server-side through a sandboxed process, and handles the install without you needing a terminal or SSH access.

This is Loopress Full specifically, not Loopress Light (the free edition on wordpress.org). wordpress.org's plugin guidelines don't allow a plugin to install executable code from a third-party registry like Packagist, so this feature ships separately, from loopress.dev, rather than the official directory. Here's why, if you're curious.

Download Loopress Full

Installing a package

Here's what that looks like from the admin, in under a minute:

Your browser doesn't support HTML5 video. Download the video instead.

Navigate to WordPress Admin → Loopress → Dependencies.
Search for a package by name (guzzlehttp/guzzle, or whatever you need). Loopress queries Packagist directly and shows you available versions.
Select the version, click Install. Loopress runs composer require on the server and installs the package into a managed vendor/ directory inside the plugin's scope.

Using it in a snippet

Require the autoloader once, then use the package like any other Composer dependency. Here it is fetching and displaying data from an API in a code snippet:

Your browser doesn't support HTML5 video. Download the video instead.

require_once WP_CONTENT_DIR . '/loopress/vendor/autoload.php';

use GuzzleHttp\Client;

add_filter('the_content', function ($content) {
    if (!in_the_loop() || !is_main_query()) {
        return $content;
    }

    $client = new Client();
    $response = $client->get('https://jsonplaceholder.typicode.com/posts', ['query' => ['_limit' => 5]]);
    $posts = json_decode($response->getBody()->getContents(), true);

    $list = '<ul>';
    foreach ($posts as $post) {
        $list .= '<li style="color: red">' . esc_html($post['title']) . '</li>';
    }
    $list .= '</ul>';

    return $content . $list;
});

Why this matters for agencies

If you manage multiple client sites, the usual Composer workflow means either:

Maintaining SSH access to every server
Teaching clients how to run terminal commands (not happening)
Keeping a pile of FTP credentials and manually uploading vendor/ directories

With Loopress, the dependency management surface moves into the WordPress admin. You can install, update, and remove packages from the same interface you use to manage everything else. No server access required.

Seeing what's installed

The Dependencies panel shows:

All installed packages with their current versions
Available updates from Packagist
A one-click update path

This is the equivalent of composer show and composer outdated, surfaced in the UI.

What Loopress doesn't replace

Loopress's dependency management is designed for adding libraries to a running WordPress site, pulling in packages that your snippets or custom code need. It's not a replacement for a full Bedrock/Composer setup where WordPress itself is a Composer dependency.

If you're building on Roots/Bedrock, you already have a proper Composer workflow and probably don't need this. Loopress fills the gap for the other 90% of WordPress sites that aren't running a full stack framework: sites on shared hosting, client sites where the server environment is opaque, or projects where "set up Bedrock" isn't a conversation you can have.

Loopress Full is a free download, installed like any other plugin zip (Plugins → Add New → Upload Plugin), no server configuration required. If you only need snippet sync, Loopress Light is the free edition submitted to the wordpress.org directory instead.

Why wordpress.org Won't Let You Install Composer Packages From a Plugin

jean-smaug — Mon, 20 Jul 2026 06:55:14 +0000

Cross-posted from the Loopress docs
Loopress is a toolset to make WordPress reproducible and reviewable via Git. Versioned snippets, Composer without SSH, and more coming...

Check Loopress

WordPress doesn't have a package manager. If you want a PHP library in your project, be it Guzzle for HTTP calls or a PDF generation library in a snippet, you're either vendoring the code by hand or running Composer somewhere the WordPress admin can't see.

We built a feature to fix that: a Composer UI inside the WordPress admin. Search Packagist, install a package, audit it for known vulnerabilities, all without SSH access (full walkthrough here). Before shipping it, we asked the wordpress.org plugin review team whether it would be acceptable in the official directory.

The answer was no.

The rule

Here's the relevant line from Guideline 8 of the wordpress.org plugin directory:

"Plugins may not send executable code via third-party systems."

Installing a PHP package from Packagist is, by definition, downloading executable code from a third party and writing it to disk. It doesn't matter that our plugin never calls the installed code's autoloader itself, that the user has to load it deliberately from their own snippet. The review team was clear: the indirection changes nothing. The mere presence of that capability is enough to trigger the rule, whether or not it's ever used. There's no folder you can hide it in that makes it acceptable, they weren't shy about saying that outright.

If you want PHP dependencies in a plugin distributed on wordpress.org, the only accepted path is to vendor them at submission time: ship the code, with a compatible license and readable source, not fetch it dynamically.

For us, that meant Composer package management could never live in the same plugin that ships on wordpress.org. Full stop, no clever workaround changes that.

What we tried first, and undid

Our first move was the obvious one: split into two plugins. A "Core" plugin with snippet sync, distributed on wordpress.org, and a "Plus" plugin with Composer management, distributed separately, with the two detecting each other at runtime.

We built it. Two npm packages, two composer.json files, two QA configs, two release pipelines, a filter contract between them so Plus could register itself with Core. Tests passed on both. Then we looked at what we'd actually built and reverted the whole thing the same day.

The duplication cost more than the split saved us. Every config file, every CI job, every README existed twice for no product reason. Worse, one version of the idea we considered, Core dynamically loading Plus's code, would have reintroduced the exact pattern the review team had just told us was the problem. That one wasn't even a contender once we thought it through.

What we shipped instead

One codebase. Two build artifacts.

wordpress-plugin/
├── src/
│   ├── Module/, Service/, RestApi/    snippet sync, shared by both editions
│   └── Dependencies/                  all Composer code, this directory
│                                      is physically absent from the
│                                      wordpress.org build, not just inactive
├── frontend/
│   ├── full/    → App.tsx             Composer UI lives here
│   └── light/   → LightApp.tsx        never imports anything from Dependencies/
└── scripts/build-flavor.cjs           assembles each edition and zips it

pnpm pack:light produces Loopress Light: snippet sync only, no Composer code anywhere in the zip, not dead code, not a disabled feature flag, physically not present. composer.json in that build ships with an empty require. A CI step unzips the artifact after the build and greps it for Composer residue, because trusting the build script to get this right isn't good enough when the whole point is a compliance boundary.

pnpm pack:full produces Loopress Full: everything, including the package installer, the security audit, and CLI sync for your composer.json/composer.lock. It's distributed from our own site, never wordpress.org, and its plugin header sets an Update URI that stops wordpress.org from ever pushing an update over it by mistake. If Loopress Light is already active on a site, activating Loopress Full deactivates it. The two editions don't coexist. Full replaces Light, it doesn't sit next to it.

This is the same model ACF and Elementor use for their free/pro split: one codebase, one build script, two artifacts with a real feature boundary between them, not a paywall drawn in the UI.

The honest tradeoff

If you only need snippet sync, Loopress Light is a free wordpress.org install, same as any other plugin in the directory. If you want Composer packages managed from WordPress without SSH, that's Loopress Full (see how it works), a separate download from our site, precisely because wordpress.org's own rules don't allow that capability to live there. We'd rather tell you that upfront than have you discover it after installing the wrong one.

Thanks

Credit where it's due: the wordpress.org plugins review team answered our question directly and quickly, before we'd submitted anything. That single clear answer, citing the exact guideline, saved us from finding out the hard way through a full submission and rejection cycle. Loopress Light is in review now, built around that answer from the start.

WordPress Has a DX Problem, and Developers Are Paying for It

jean-smaug — Wed, 15 Jul 2026 17:34:49 +0000

Cross-posted from the Loopress docs
Loopress is a toolset to make WordPress reproducible and reviewable via Git. Versioned snippets, Composer without SSH, and more coming...

Check Loopress

WordPress is remarkable. It powers well over 40% of all websites, according to W3Techs. Your clients love it. Their non-technical staff can update content without calling you. The plugin ecosystem is enormous.

But if you're a developer, the moment you sit down to build with WordPress, something feels off.

You're editing files directly on the server. You're copy-pasting snippets from the admin panel. You're hoping you remember what you changed last week. You're sending a colleague a zip file with the "latest version" of some PHP function.

None of this is how modern software is built. And yet, it's the default WordPress workflow. This is the gap Loopress exists to close, and it's worth understanding exactly where the friction comes from before looking at how to fix it.

What is developer experience?

Developer experience (DX) refers to how smooth (or painful) it is to work with a tool as a developer. Good DX means: fast feedback loops, predictable environments, version-controlled code, and reproducible deployments.

Think of how you work with a modern JavaScript project:

Code lives in Git
Dependencies are declared in package.json and locked in package-lock.json
You run npm install and the project works
Staging and production match because the environment is defined in code

Now think about a typical WordPress project:

Snippets are stored in a database, edited through a UI
PHP packages require SSH access to install
"Deploying" means FTP or a database export
Staging and production drift apart over time because changes happen manually in both

This isn't a criticism of WordPress as a product; it was built for a different audience. But developers using it to build things deserve better.

What can go wrong

Here's a real scenario: you add a PHP snippet to your WordPress site using the Code Snippets plugin. It works. Three months later, a junior dev edits it and introduces a bug that takes checkout down for an hour. You have no idea what changed, when, or why. There's no diff, no history, no rollback button. You dig through admin logs hoping to find something, then end up rewriting the snippet from memory.

Or: a client wants a PDF export feature. You need to pull in a Packagist package. You SSH into the server, install Composer, run composer require, and pray nothing breaks in production. It worked, but it was thirty minutes of friction that shouldn't exist.

These aren't edge cases. They're the everyday reality of WordPress development.

What a better workflow looks like

Imagine instead:

# Pull your snippets down as files
lps snippet pull

# Edit them locally, in your editor, with Git tracking changes
git add snippets/my-function.php
git commit -m "fix: correct tax calculation logic"

# Push back to WordPress
lps snippet push

Your snippet is now version-controlled. You have a diff. You can roll back. You can review the change in a PR. This is how software is supposed to work, and it's exactly what Loopress brings to WordPress: a CLI that treats your snippets and Composer dependencies as files, plus a plugin that lets you manage PHP dependencies from the admin panel without server access.

WordPress stays WordPress. Your clients can still use it the way they love. You just work with it like a developer.

What's next

The rest of this blog will cover specific workflows in detail: version-controlling Code Snippets with Git, installing Composer packages without SSH, syncing menus and styles between environments, and managing multiple client sites as code. Those posts are coming soon; this one lays the groundwork for why they matter.

Why I Built Loopress

jean-smaug — Sat, 04 Jul 2026 14:11:46 +0000

Cross-posted from the Loopress docs
Loopress is a toolset to make WordPress reproducible and reviewable via Git. Versioned snippets, Composer without SSH, and more coming...

Check Loopress

I'm a frontend developer who's spent the last few years working in environments where everything is versioned, deployments are automated, and "it works on my machine" isn't an acceptable answer.

One of the jobs that shaped how I think about this was Bedrock Streaming, a streaming platform where every developer owned their infrastructure, frontend included, and the tool we used was Terraform. I remember something clicking when I started using it: your infra is just a file, which means it gets versioned, reviewed, and rolled back like any other piece of code. That idea stuck with me well past that job.

A site for my sister

My sister runs an online French tutoring business (nativefrenchteacher.com). She's not technical, and she needed to manage her own content without calling me every time. WordPress made sense.

And honestly, it worked great for her. Whatever I needed (bookings, SEO, forms, caching) there was a plugin. The ecosystem is massive.

Building with it as a developer was another thing entirely.

I used the Code Snippets plugin constantly. And every time I touched a snippet, the same thought: if something breaks, I have no history. No diff. Just hope it doesn't break.

The real moment was when I needed to manipulate PDFs and wanted to pull in a Packagist package. So I SSH'd into the server, installed Composer manually, ran the install, crossed my fingers. It worked. But it felt wrong. This is a solved problem everywhere else.

The gap

I came from a world where code lives in Git and environments are reproducible. WordPress assumes you click things in the admin, upload files via FTP, and remember what you changed. Production is always slightly different from local.

That's not a knock on WordPress. It's built for a different audience. But the developer building on top of it is left to figure things out alone.

What I built

I started building Loopress: a CLI to version-control code snippets in Git and sync them to any WordPress instance, and a plugin that brings Composer dependency management into the admin panel, no SSH needed.

The goal was to bring the same idea I took away from Terraform into WordPress: your snippets, your dependencies, your configuration, all of it living in a repo, reviewable, deployable, not scattered across admin panels and SSH sessions you'll never remember.

Still building. If any of this sounds familiar, I built it for you.