How Snipfire keeps your site safe

A broken snippet in functions.php can take a whole site down. Snipfire catches problems at four points, so a mistake stays a mistake and doesn't become an outage.

1. While you type #

The editor checks your code as you write. Problems get a red underline on their line and are listed in the Problems panel under the editor. Click a problem to jump to its line.

2. When you save #

Before saving, Snipfire checks:

• PHP syntax, in PHP snippets and in PHP mixed into HTML snippets. (It uses PHP's own parser; no shell commands are needed on your server.)
• Functions and classes that already exist. Declaring a function that WordPress, a plugin or another snippet already declares would crash the site with "Cannot redeclare". Snipfire stops that before it happens.
• Conditions that can't work at the chosen location, such as a page rule on a hook that runs before WordPress knows the page. See Where snippets run.
• Invalid values: a URL pattern that isn't a valid regular expression, a number rule without a number, a shortcode tag another snippet already uses.
• SCSS and LESS compile errors (Pro).

It also warns about things that aren't errors but often cause trouble, for example a PHP snippet that ends with ?> followed by blank lines (which can cause "headers already sent" errors).

Your code is always saved, so you never lose work. What happens next depends on what was found:

The problems are shown on their lines and in the Problems panel.

Saving with problems also applies to a snippet that's already live: if you save a broken change to it, Snipfire switches it off rather than run broken code. The previous version is in its history, one click away. (A live SCSS or LESS stylesheet is the exception: it keeps its last compiled CSS on the site until you fix it.)

3. When you switch a snippet on #

When a PHP or HTML snippet that runs automatically is switched on, Snipfire test-loads your site with the snippet active, the same way WordPress tests a plugin edit: it loads a page as you, in the background. If that page load crashes, the snippet is switched straight back off and you see why: The snippet crashed when the site loaded, so it was switched off: followed by the error, for example Error: Call to undefined function get_field(), and its line. Your visitors never see it.

Snippets on admin locations are tested by loading an admin page instead of the front end.

Switching on many snippets with a bulk action runs one test load for all of them. A snippet that makes it crash is switched off again and listed.

4. While your site is running #

Some errors only show up later: on one particular page, for one kind of visitor, or inside a callback that runs long after the snippet itself. Snipfire watches for them:

• If a snippet throws an exception or causes a fatal error, Snipfire switches that snippet off and records the error and its line.
• This covers errors in functions the snippet hooked into WordPress (add_action, add_filter), and fatal errors that happen before any page output.
• An error thrown while the snippet itself runs is caught on the spot: the page is built without the snippet, and the visitor doesn't notice.
• A real fatal error (or an error later, inside a hooked function) can't be caught in time for that one request. The visitor sees WordPress's error page, with a line from Snipfire: Snipfire has switched off the code snippet that caused this (#12). Reload the page. The next page load works, without the snippet.

Then Snipfire tells you:

• A notice in the WordPress admin: Snipfire switched off snippet #12 "…" because it caused an error., with the error and a Fix it link that opens the snippet at the broken line.
• In the editor, the snippet shows Switched off after an error on line … and the message Fix it and save with Active on; Snipfire tests it before it goes live.
• The Errors filter in the sidebar lists every snippet switched off this way.
• With Snipfire Pro, the activity log records it too.

Fix the code, turn Active on and save. Saving clears the recorded error.

Snipfire's own screens never run snippets #

The Snipfire editor, its Tools page and its REST API never run your snippets. Even if a snippet breaks the rest of the admin, you can still open Snipfire and fix it. If you can't reach the admin at all, use safe mode.

Edits take effect immediately #

Some hosts cache PHP files aggressively. Snipfire gives each version of a snippet a new file name, so an edit (from the editor, WP-CLI or Git sync) is picked up on the very next request, even on those hosts.

Locking Snipfire down #

Hosts, agencies and security-minded site owners can limit what Snipfire may do with a line in wp-config.php (above That's all, stop editing!).

No PHP at all: SNIPFIRE_DISABLE_PHP #

define( 'SNIPFIRE_DISABLE_PHP', true );

With this line, no PHP runs from Snipfire, for anyone:

• PHP snippets don't run, and neither do HTML snippets that contain PHP. HTML without PHP, CSS and JavaScript snippets keep working.
• You can still open PHP snippets and their history. Saving one keeps your code but leaves it switched off, and it can't be switched on or run with Run. The editor says why: PHP is turned off for Snipfire on this site (SNIPFIRE_DISABLE_PHP in wp-config.php), so this snippet can't be switched on or run.
• Tools & Safe Mode → Storage shows PHP snippets: Off for everyone.

When you remove the line, PHP snippets that were on start running again. Ones saved while the line was there are off: switch them on to use them.

WordPress's own DISALLOW_FILE_EDIT turns off the theme and plugin file editors, but it doesn't stop Snipfire from running PHP. If a site has it, the Tools page reminds you that SNIPFIRE_DISABLE_PHP is the line that blocks PHP snippets too.

Read-only for everyone: DISALLOW_UNFILTERED_HTML #

define( 'DISALLOW_UNFILTERED_HTML', true );

This WordPress constant stops everyone, administrators included, from adding unfiltered HTML to the site. Snippets are unfiltered code by nature, so with it Snipfire becomes view only for everyone signed in:

• Snippets that are on keep running.
• In the editor you can look at snippets and their history, but not change, switch or delete them. It says Snipfire is read-only on this site because DISALLOW_UNFILTERED_HTML is set in wp-config.php.
• Screens that only change things (Tools & Safe Mode, Header & Footer) aren't shown. Save your safe mode link before adding the line, or get it with wp snipfire safe-mode.
• WP-CLI still works, so whoever manages the server can still make changes.

Both constants are listed in Storage and constants.

What Snipfire can't catch #

Snipfire catches errors, not wrong behaviour. A snippet that runs without errors but does the wrong thing (hides the wrong element, sends the wrong email) keeps running until you change it. For trying changes on a live site without visitors seeing them, use testing mode (Pro).