Skip to content

Early-bird lifetime licence: $199 once, for the first 200 buyers only. See the offer

All docs

Page code and the Snipfire block

Some code belongs on one page only: a conversion tag on a landing page, a schema block for one article, a script for one form. Snipfire adds a Snipfire panel to the block editor (and a box to the classic editor) for exactly that, and a Snipfire snippet block to place shortcode snippets in the content.

The Snipfire panel in the block editor

Open a post or page and look in the post settings sidebar for the Snipfire panel. When the page has code of its own, the panel's title shows how many boxes are in use, for example Snipfire (2).

It has three boxes, like the site-wide Header & Footer screen, but for this page only:

Box Where the code goes
Header Inside <head> on this page only
Body Right after <body> opens
Footer Before </body>

Paste the code as the service gives it, <script> tags and all, and save the post as usual (Update or Save). The code is saved with the post.

  • Printed as it is. No PHP runs from these boxes, and there are no checks or test loads: it's pasted code, like in a theme's header box. Smart tags such as {post_title} are replaced (and escaped).
  • Only on this post's own page, when it's shown on its own. Not in lists of posts, not on other pages.
  • After the site-wide code. Page code is printed after the Header & Footer boxes, so it can use what they load, such as the Google tag.
  • Safe mode stops it too. In safe mode, page code isn't printed either.

The panel appears on public post types that use the editor: posts, pages, products and custom post types. Developers can change the list with the snipfire_page_scripts_post_types filter.

Tick Leave out the site-wide Header & Footer code to keep the three Header & Footer boxes off this page, for example on a landing page with its own tracking, or a page embedded in an app. Other snippets still run as usual: use conditions to keep those off a page.

In the block editor, the switch only shows once at least one Header & Footer box is in use.

Snippets on this page

Under the boxes, Snippets on this page lists the active snippets that print or load something on this post, each with a link to open it in the editor:

  • Run on this page: their conditions say yes for this post.
  • Depend on the visitor (logged in, device, cookies…), testing mode or consent: they may or may not run, depending on who's looking or when. Snippets in testing mode or waiting for cookie consent are listed here too.
  • Used in the content (shortcode or block): snippets placed in this post as a shortcode or with the Snipfire block.

It covers HTML, CSS and JavaScript snippets on front-end locations, and PHP snippets on the page hooks (wp, template_redirect, wp_head, wp_body_open, wp_footer). PHP snippets that run earlier, such as on Run immediately or init, aren't listed, because they run on every request. Click Check again after changing snippets or conditions.

The classic editor

With the classic editor, the same boxes are in a box under the content: Snipfire: code for this page, with Header, Body and Footer, and Leave out the site-wide Header & Footer code on this page. Save the post to save them.

Who can change page code

Page code is unfiltered code on your site, so changing it needs both:

  • Snipfire access to HTML, CSS and JavaScript: administrators, or with Snipfire Pro, roles with CSS, JS and HTML (no PHP) or Full, including PHP in team access, and
  • WordPress's unfiltered_html capability, and the right to edit that post.

On a single site, administrators and editors have unfiltered_html; on multisite, only super admins do. With DISALLOW_UNFILTERED_HTML nobody has it: see Locking Snipfire down.

People with View only access see the list of snippets on the page, and a note when the page has code of its own: This page has its own code. Only people who may add scripts can change it. Everyone else doesn't see the panel.

The Snipfire block

The Snipfire snippet block puts a shortcode snippet into the content, with its attributes as block settings instead of typed into a shortcode.

  1. In the block editor, add the Snipfire snippet block (search for "snippet").
  2. Under Snippet, choose one of your shortcode snippets. The list shows PHP and HTML snippets set to As a shortcode; switched-off ones are marked (off).
  3. Under Attributes, fill in the values the snippet reads. Snipfire finds them in the code ($atts['name'], or the defaults in shortcode_atts()). Add an attribute adds one it didn't find.

The block shows the snippet's output in the editor. On the site it renders exactly like the shortcode: the same conditions, crash protection and cookie consent, and nothing at all when the snippet is off or its conditions don't match. If the editor preview is empty, it says why this may be: Nothing to show in the editor: the snippet is off, prints nothing, or its conditions don't match here. Check the page on the site.

The block supports wide and full alignment and an extra CSS class. Its output is wrapped in <div class="snipfire-block">.

Anyone who can write posts can use the block, like the [snipfire] shortcode. Escape attribute values in your snippet before printing them: see Using attributes.

No shortcode snippets yet? The block says No shortcode snippets yet. In Snipfire, set a PHP or HTML snippet to run "As a shortcode".

Something unclear or missing? Tell us