How to Manage WordPress Snippets Across Multiple Sites

The first snippet on a new client site is easy. The twelfth copy of "disable XML-RPC and hide the admin bar for subscribers" is how you end up with four versions, one of which still has last year's Google Analytics ID. Multi-site snippet management is not a multisite-network feature. It is a distribution problem: one reviewed artifact, many runtimes.

This is the operational guide. The process-and-people version lives in WordPress code management for agencies.

Why dashboards diverge

Every snippet plugin that only exists *inside* one wp-admin invites drift:

• A hotfix on production never gets back to staging
• Site B was "almost the same" so someone edited in place
• A vendor cloud sync pushed a bundle, then a contractor edited one file locally
• The snippet was pasted from a Slack thread that was already two revisions behind Git

Cloud libraries (Codevault, WPCode, WPCodeBox) solve "I need the same starter pack on a new site." They do not solve "site 7 has a one-line fork and nobody knows why." Bidirectional vendor sync without a review step is how a bad snippet becomes a fleet problem.

Pick a source of truth

You get to pick one.

GitHub (or GitLab) is the correct default if more than one human or more than one production URL is involved. The snippet files are the repo. Sites pull. Hotfixes go back as commits. GitHub sync for WordPress snippets is the SnipVault-shaped version of this; the principle holds if you rsync a FluentSnippets directory in CI.

A vendor cloud is acceptable if you are a solo freelancer, the library is small, and you will never need a pull request. Know that you are renting the source of truth.

The production site is not a source of truth. It is a deploy target that happens to have an editor.

SnipVault's remote sites feature is for switching context — manage staging and a client from one admin — not for replacing Git. Use both: Git for the artifact, remote sites for the operation.

A rollout that does not need a spreadsheet

Inventory once. Name snippets after the job (woo-checkout-hide-company-field), not after the client. If two clients share the PHP, it is one snippet with conditions, not two copies.

Review once. Security pass for eval, SQL, unsanitized input. PHP version parity with the oldest production host. The safety article is the standard.

Ship to staging first on the site that most resembles production (same WooCommerce version, same PHP). Playground is for parse/hook tests (Playground workflow); staging is for cart and login.

Promote by pull, not by paste. If the site is connected to the repo, pull the snippet. If you use remote site switching, open that site and sync. Do not open a gist in ten tabs.

Confirm, then clock out. Front, checkout, wp-admin. If you cannot name the pages the snippet touches, it should not have been global.

What to do with the one-off

Some PHP is genuinely per-site: a tracking ID, a pixel, a CPT slug the client invented. Keep those in a site workspace (SnipVault project workspaces are built for this) or a clearly named folder, not in the shared pack.

The failure mode is putting the one-off in the shared pack "just this once." Six months later every new site inherits a Klaviyo key from a different client.

Retiring a snippet across the fleet

Deletion is harder than deploy. If you remove legacy-ga-ua from Git and a site never pulls, that site still ships Universal Analytics in 2026.

Retirement checklist:

• Mark the snippet inactive in the repo (or ship a no-op with a log) for one release
• Pull everywhere you can still log in
• Then delete
• Keep the Git history. "Why did we have this?" is a 2am question

File-based storage helps: you can see the file on disk during an audit. Database-only plugins hide retired code as rows until someone exports.

Tools, ranked by how badly they drift

• Copy-paste between dashboards — maximum drift, still the industry default
• Vendor cloud push — low friction, weak review, easy fleet-wide mistake
• Git + manual pull on each site — honest, a bit slow, auditable
• Git + remote site context + GitHub sync — what we built so the honest path is not slow

Code Snippets Pro's Codevault and WPCode's library sit in the middle. They are better than paste. They are not a PR. If a client security questionnaire asks where custom PHP lives, "a third-party snippet cloud" and "our GitHub org" are different answers.

Multisite is a different sentence

WordPress multisite can run network-activated plugins and, depending on the snippet tool, network-wide snippets. That is one runtime, many sites. It does not help you when the sites are ten separate installs at ten hosts. Do not buy a "multisite compatible" plugin and expect it to manage unrelated client servers. That is the remote-sites job.

The test of a good setup

Ask a colleague to add a one-line fix to the XML-RPC snippet and get it onto staging plus two productions without Slack-pasting PHP. If the answer involves a zip file or "I'll just hop on each site," you do not have multi-site management. You have a list of logins.

Make the repo the product. Make each WordPress install a subscriber. Everything else is nostalgia for a time when you had three sites and a good memory.