Code snippets

Manage small pieces of code from the admin, without editing theme or plugin files and without FTP. Snippets are a suite feature (the Settings tab, key snippets), so the whole system can be switched off site-wide.

Every snippet has a type, a place where it runs, and a status. The plugin keeps a compiled runtime cache, so a normal page load performs zero snippet queries against the database.

Snippets is a Pro feature#

The whole feature lives in Ultivo Toolkit Pro. The free version on wordpress.org does not hide it behind a locked screen: the code is physically absent from that build.

The reason is wordpress.org policy. They no longer accept plugins that let you save arbitrary CSS, JavaScript or PHP from the admin, with the argument that WordPress already ships its own CSS editor in the Customizer. That applies to CSS as well, so a CSS-only version was not an option either.

Types and where they run#

The type determines which contexts are available:

CSS is printed inline in its own <style> tag; JS is printed the same way in a <script> tag; HTML is echoed as-is at the chosen spot, where shortcode_only prints nothing by itself; and PHP runs on plugins_loaded, so a snippet can register its own hooks just like a plugin does.

Snippets of the same type run in priority order, lowest first (default 10). Use it when one snippet depends on another having run already.

The shortcode#

It places an HTML snippet:

[ultivo_snippet id="slug-or-id"]

By slug or numeric ID. It works for a snippet in any HTML context, not just shortcode_only: a snippet that already prints in the footer can also be dropped somewhere specific in a post.

Conditions#

Each snippet can carry a rule set: param == value / param != value rules combined with match all or match any. An empty rule set always matches: conditions are opt-in. Rules are evaluated per request rather than baked into the cache, because most of them depend on things that are only known once WordPress has resolved the current URL.

CSS snippets run late enough in the request to get the full list.

PHP snippets get a shorter list. A PHP snippet runs on plugins_loaded, before WordPress has parsed the main query, so nothing is known yet about which page was requested. Parameters marked late are simply not offered for PHP snippets: they are never evaluated as "no match", so a rule can't silently stop a PHP snippet once the page resolves later. JS and HTML snippets run later in the request and get the full list.

Without the taxonomy: prefix, taxonomy_term matches only the singular view of a post carrying that term, not the taxonomy archive itself. Use the prefix when the archive should match too.

Adding your own condition#

Two filters let a theme or plugin extend the register: ultivo/snippets/condition_params adds a parameter to the editor's list, and ultivo/snippets/condition_match/{param} supplies the matching logic. Returning anything other than null from the match filter overrides the plugin's own handling.

add_filter( 'ultivo/snippets/condition_params', function ( $params ) {
    $params['cart_empty'] = array(
        'label'   => __( 'Cart is empty', 'my-theme' ),
        'late'    => true, // depends on the resolved page, so not offered for PHP.
        'values'  => 'boolean',
        'choices' => array(),
    );
    return $params;
} );

add_filter( 'ultivo/snippets/condition_match/cart_empty', function ( $override, $value ) {
    return function_exists( 'WC' ) && WC()->cart->is_empty() === ( '1' === $value );
}, 10, 2 );

Register ultivo/snippets/condition_params on plugins_loaded or earlier if PHP snippets should be able to use the parameter: a parameter added from an init callback does not exist yet when PHP snippets are evaluated, and the rule is then ignored (not treated as "no match"). CSS, JS and HTML snippets are unaffected.

Safe mode#

A CSS snippet cannot take a site down; PHP can, so there are three layers against it.

1. Syntax check on save. A PHP snippet is parsed (not executed) when you save it. One with a syntax error cannot be enabled; it is saved and switched off, with the parse error shown above the code, so the work isn't lost.
2. Runtime catching. PHP snippets execute inside a try/catch. An uncaught error disables the snippet (status Error) and writes to the log instead of breaking the page.
3. Probation window. For 60 seconds after you enable or edit a PHP snippet, a flag is written to the database right before it executes. If the process dies hard (out of memory, or a fatal in a hook callback the snippet registered) the flag survives, and the next request logs the crash and disables the snippet automatically.

All three apply when you restore an older version from the Revisions tab as well.

Statuses are Enabled, Disabled and Error. A snippet is simply on or off: there is no separate publishing step, and a new snippet starts switched off. Error is only ever set by the engine, never chosen directly. Set it back to Enabled once the code is fixed. Fatals and exceptions land in one shared log (capped at 50 entries site-wide, newest first); a snippet's Log tab shows only its own entries, each with the file and line so you can tell whether the crash really came from that snippet.

One thing safe mode cannot catch is a snippet calling exit; or die; unconditionally. Those end the request immediately: there is no exception to catch and no shutdown check that can undo it. Such a snippet stays enabled and ends every request that reaches it, including wp-admin. The way back is to add this to wp-config.php:

define( 'ULTIVO_DISABLE_SNIPPETS', true );

That disables the entire snippets runtime until you remove the line again.

Organizing and moving snippets#

• Tags: a comma-separated list per snippet, purely organizational. The Tags column on the list screen is clickable and filters the list.
• Duplicate: a row action that copies code, type, context, priority, conditions and tags. The copy is always created disabled, so a duplicate never quietly starts running.
• Import / export: export a selection (bulk action), a single snippet (row action) or everything (the Import/Export screen); all three produce the same JSON. The format deliberately has no status field: an imported snippet always comes in as new and disabled, never overwriting an existing one. Anything that fails is skipped with a message instead of failing the whole import: an unknown type, a snippet you lack the rights to create, a PHP snippet that does not parse.
• Revisions: the Revisions tab on the snippet's own edit screen restores an older version. Use that tab rather than WordPress's built-in revision.php restore link, which reports success but changes nothing on a snippet.

Permissions#

• CSS, JS and HTML snippets require unfiltered_html.
• PHP snippets require the edit_plugins capability: the same one WordPress uses to gate the plugin and theme file editors. It disappears when DISALLOW_FILE_EDIT is set; define ULTIVO_ALLOW_PHP_SNIPPETS to allow PHP editing anyway, gated on manage_options.
• On multisite, editing PHP snippets is limited to super admins regardless of the above.

Existing enabled snippets keep running for everyone: permissions gate the editor, not execution.