Standalone mode: ship client sites with zero lock-in

Here is a question worth asking any plugin before you build a client site on top of it: what happens to the site when the plugin is gone?

For most snippet plugins the answer is that the snippets stop. The code lives in a table only that plugin can read, so removing the plugin removes the behaviour. Every site you hand over carries a dependency the client now has to keep installed, updated, and licensed.

Standalone mode is our answer to that.

What it actually does

FluentSnippets → Settings → Standalone Mode → Turn on Standalone Mode.

That writes one small file, wp-content/mu-plugins/fluent-snippets-mu.php. Being a must-use plugin, WordPress loads it automatically and nobody can deactivate it from the Plugins screen.

wp-content/
├── mu-plugins/
│   └── fluent-snippets-mu.php     the runner, written by the toggle
└── fluent-snippet-storage/
    ├── index.php                  the generated map it reads
    └── 1-google-analytics-4.php   your snippets, untouched

The file contains a copy of the snippet runner — the same code that reads your storage directory’s index.php, evaluates conditional logic, and includes your snippet files at the right hooks. It does not contain your snippets. Those stay exactly where they were, in wp-content/fluent-snippet-storage/, as ordinary PHP files.

So the plugin becomes the thing you edit snippets with, rather than the thing that runs them.

Note the third row of the file column: your snippets are never deleted either way. The only difference is whether they keep executing.

The handover workflow

1. Build the site. Write your snippets normally, with names, groups and conditions.
2. Enable standalone mode.
3. Load the front end and confirm everything still works. It will — same runner.
4. Deactivate FluentSnippets. Confirm again.
5. Delete the plugin, and hand over.

The client receives a site that works, with the custom code sitting in wp-content as readable files, and one fewer plugin to keep updated. If they later want to edit a snippet, they install FluentSnippets and everything reappears exactly as it was — because the state was always in the files, never in the plugin.

What you give up

You cannot manage snippets while standalone. The mu-plugin runs them; it has no admin interface. To add, edit or remove one you either reinstall FluentSnippets, or edit the files directly and rebuild the index by hand. For almost everyone, reinstalling is the answer.

Standalone mode is not meant to be a permanent way of working. It is a guarantee that removing the plugin does not break the site.

Keeping the copy current

The mu-plugin records the plugin version it was written from. When you update FluentSnippets, the first admin request after the update notices the runner is older than the plugin and rewrites it. Deactivating the plugin refreshes it first, too — so whatever takes over is always current.

The one gap: if you delete the plugin directory by hand, over SFTP, without deactivating through the admin, the mu-plugin stays at whatever version it last wrote. It keeps working, it just will not gain later fixes. Deactivate through the admin first and that never comes up.

Caveats worth checking

• WordPress must be able to create wp-content/mu-plugins/ if it does not exist. On a host that makes it unwritable, enabling standalone mode returns an error rather than failing quietly.
• If the site defines a custom WPMU_PLUGIN_DIR, the file goes there.
• Some managed hosts manage mu-plugins themselves and will remove files they did not put there. Check after enabling it, and check again after any host-side migration.
• The runner is a copy, not a symlink. Editing it by hand is pointless; it gets overwritten on the next update or toggle.

Why we shipped it

A snippet manager sits underneath everything else on a site. That is a lot of trust to ask for, and “you can leave whenever you like” is the only way we know to earn it.

It also has a quieter use: on a site where the snippets are finished and unlikely to change, standalone mode gets you the behaviour without the plugin loading its admin code on every request.

Full details, including how it interacts with Safe Mode, are in the standalone mode docs.