Title: Spintax
Author: Franky
Published: Méi 11, 2026
Last modified: Méi 14, 2026
---
Search plugins
# Spintax
By [Franky](https://profiles.wordpress.org/301st/)
[Download](https://downloads.wordpress.org/plugin/spintax.2.1.1.zip)
* [Details](https://su.wordpress.org/plugins/spintax/#description)
* [Reviews](https://su.wordpress.org/plugins/spintax/#reviews)
* [Installation](https://su.wordpress.org/plugins/spintax/#installation)
* [Development](https://su.wordpress.org/plugins/spintax/#developers)
[Support](https://wordpress.org/support/plugin/spintax/)
## Description
Spintax is a content-generation toolkit for WordPress. Author reusable templates
in spintax markup (enumerations, permutations, conditionals, plural agreement),
then either embed them inline via shortcodes / PHP, or **bind them to ACF and post-
meta fields so every matching post gets its own rendered variant on save, on a cron
schedule, or on demand**. A built-in Logs page surfaces what each Bulk Apply / Run-
now walk did; a WP-CLI surface covers staging-to-production sync.
**Key features:**
* **Enumerations** `{a|b|c}` — randomly pick one option, with nesting support
* **Permutations** `[a|b|c]` — pick N elements, shuffle, join with custom
separators
* **Variables** `%var%` — global, local (`#set`), and shortcode-level variable
scopes
* **Conditionals** `{?VAR?then|else}` — render a branch based on whether a variable
is set (also `{?!VAR?then}` inverted)
* **Plural agreement** `{plural : form1|form2|form3}` — pick grammatically
correct noun form by count. RU/UK/BE 3-form (one|few|many), EN-style 2-form (
one|many). First spintax engine with first-class plurals.
* **Nested templates** — embed templates within templates via `#include` or `[spintax]`
* **ACF / post-meta bindings (NEW in 2.0)** — configure once per post type, render
Spintax templates into ACF text/textarea/wysiwyg fields or post-meta keys on
every matching post. Auto-seed empty fields, preserve manual edits, Bulk Apply
via Action Scheduler.
* **Object cache** — rendered output cached via WP Object Cache API (Redis/Memcached
ready)
* **Cron regeneration** — optional scheduled cache refresh per template, plus per-
binding cron walks
* **WP-CLI** — `wp spintax bindings list|apply|test|export|import`
* **Validation** — bracket matching, circular reference detection, syntax checking
* **Admin UI** — code editor, live preview, shortcode copy, settings page, bindings
list
**Syntax based on the GTW (Generating The Web) standard.**
### External services
This plugin does **not** connect to any external services, APIs, or third-party
servers.
All content generation happens locally on your WordPress server. No data is sent
externally. No remote requests are made during activation, rendering, or caching.
### Privacy Policy
This plugin does not collect, store, or transmit any personal user data. It does
not use cookies, tracking pixels, analytics, or any form of telemetry.
Templates and their rendered output are stored entirely within your WordPress database
and object cache.
### Credits
* Syntax based on the [GTW (Generating The Web)](https://spintax.net) standard
* Developed by [301st](https://301.st)
## Screenshots
* [[
* Template editor with spintax markup and live preview.
* [[
* Settings page with global variables editor.
* [[
* Template list with shortcode, cache status, and cron schedule.
* [[
* Binding edit form: three-tab layout (Source & Target / Behavior / Test), ACF
combobox with stable field-key autofill, post-type and status scope filters,
shared-template vs per-post source modes.
## Installation
1. Upload the `spintax` folder to `/wp-content/plugins/`
2. Activate the plugin through the ‘Plugins’ menu in WordPress
3. Create templates under the “Spintax” menu in the admin sidebar
4. Embed templates using `[spintax slug="my-template"]` in posts/pages or `spintax_render('
my-template')` in theme files
**Recommended optional dependency:** install [Action Scheduler](https://wordpress.org/plugins/action-scheduler/)
if you plan to use the “Bulk Apply” button on ACF / post-meta bindings, or schedule
bindings via per-binding cron on a site with many matching posts. The plugin works
without it — admins can use the synchronous “Run now” button on each binding card,
and the same walk is available as `wp spintax bindings apply --binding= --all`.
Action Scheduler turns those into one-click chunked async jobs that don’t block
the request. If you already use WooCommerce or another plugin that bundles Action
Scheduler, you’re already set; the Bindings page only shows the install notice when
AS isn’t loaded.
## FAQ
### How do I create a template?
Go to Spintax > Add New in the WordPress admin. Enter a title and your spintax markup
in the editor.
### What syntax does the plugin use?
* `{a|b|c}` — randomly picks one option
* `[a|b|c]` — permutation: picks N elements, shuffles, joins with space
* `[ a|b|c|d]` — configured permutation
* `%variable%` — variable reference
* `#set %var% = value` — local variable definition
* `{?VAR?then|else}` — conditional: render a branch by truthiness of `%VAR%` (also`{?!
VAR?then}` inverted)
* `{plural %Count%: form1|form2|form3}` — plural agreement: picks the correct grammatical
form by count (RU 3-form, EN 2-form)
* `/#comment#/` — block comment (stripped from output)
* `#include "slug"` — embed another template
Full syntax reference with examples and a live playground: https://spintax.net/docs/
syntax
### Where can I learn more?
* **Documentation hub:** https://spintax.net/docs/ — guides, reference, recipes
* **Compact syntax reference:** https://spintax.net/docs/syntax — all primitives
in one page (13 languages)
* **Plural agreement guide:** https://spintax.net/docs/plural-spintax/ — `{plural
N: form1|form2|form3}` in depth (EN/RU)
* **Conditional spintax guide:** https://spintax.net/docs/conditional-spintax/ —`{?
VAR?then|else}` value-driven branching (EN/RU)
* **Authoring mindset:** https://spintax.net/docs/authoring-mindset/ — write the
final text first, add markup last (EN/RU)
* **Live playground:** https://spintax.net/play/ — write a template, set variables,
render N variants in your browser (EN/RU)
### Does caching require Redis or Memcached?
The plugin uses the WordPress Object Cache API. With a persistent backend (Redis,
Memcached), cached output persists across requests. Without one, templates are re-
rendered on each page load.
### Can I pass variables through shortcodes?
Yes: `[spintax slug="greeting" name="Alice" city="Moscow"]` makes `%name%` and `%
city%` available inside the template.
### What are ACF / post-meta bindings?
A binding pairs a Spintax template (or a per-post inline source) with one target
field on one post type — for example “Posts ACF: hero_subtitle”. Configure it once
under Spintax Bindings and the plugin populates the field on every matching post
on save, on a cron schedule, or on demand via Bulk Apply. Manual edits are preserved
by default (hash-tracked); flags control whether the binding auto-seeds empty fields,
regenerates on every save, or clears the field when the template renders to empty.
### Can I bind to ACF fields?
Yes. Bindings support both ACF (text / textarea / wysiwyg, top-level fields) and
plain post-meta keys. ACF Free and Pro are both supported; nested fields (repeater/
flexible_content rows) are not supported in 2.0 — that lands in a later release.
The form-side field picker auto-fills the stable ACF field key so writes work on
the first save without ACF’s reference-meta handshake.
### Do I need Action Scheduler?
It’s a recommended optional dependency for binding-heavy sites. The plugin works
without it: admins can run a walk via the synchronous **Run now** button on each
binding card, or `wp spintax bindings apply --binding= --all` from the CLI.
What Action Scheduler adds is chunked async execution, so:
* The admin **Bulk Apply** button can dispatch a non-blocking background job instead
of holding the request.
* Per-binding cron schedules enqueue an async job instead of running the walk inline
on the cron tick — useful on large catalogues where the synchronous path risks
PHP-FPM timeouts.
Many WP shops already ship Action Scheduler bundled with WooCommerce or other plugins—
check Plugins Installed Plugins for “Action Scheduler” before installing it separately.
If the Bindings admin page shows an “Action Scheduler is not installed” notice at
the top, you don’t have it loaded yet.
### What’s the difference between Bulk Apply and Run now?
Both walk every matching post for a binding and produce the same writes. They differ
in _how_ the walk runs:
* **Bulk Apply** — dispatches the walk to Action Scheduler as chunked async jobs.
The request returns immediately and you can watch progress on the Logs page.
Requires Action Scheduler.
* **Run now** — runs the entire walk synchronously in the current request. No async
dependency, but the page blocks until the walk finishes. Available to administrators,
and the recommended path on sites without Action Scheduler.
When Action Scheduler isn’t loaded, the Bulk Apply button is disabled with a tooltip
pointing at Run now / WP-CLI; the stale-source banner on the binding edit form promotes
Run now to its primary action.
### Where do I see Bulk Apply or Run now progress?
**Spintax Logs** in the admin sidebar. Both paths log a completion entry per walk(
e.g. `Bulk Apply run_synchronously completed for binding — wrote=N skipped=
M cleared=K.`), plus warnings for partial failures. The Logs page supports level
filtering, substring search, and pagination; entries are kept in a ring buffer sized
by Settings Spintax Max log entries.
### What WP-CLI commands does the plugin add?
Five subcommands under `wp spintax bindings`:
* `wp spintax bindings list [--format=table|json|csv]` — list all bindings on the
site.
* `wp spintax bindings apply --binding= [--all|--post=]` — run a binding
against every matching post (`--all`) or a single post (`--post=`). This
is the synchronous fallback path for Bulk Apply.
* `wp spintax bindings test --binding= --post=` — dry-run a binding against
one post and report what would be written (target value, rendered preview, skip
reason). Same logic as the admin Test panel; use this instead of `apply` when
you want a preview.
* `wp spintax bindings export {--binding=|--all} [> bindings.json]` — emit
one binding or the full store as JSON to stdout, deduped by `(post_type, target.
key)`.
* `wp spintax bindings import --file=bindings.json [--overwrite] [--dry-run]` —
import bindings from JSON. `--overwrite` updates matches on the same target triple;
without it, duplicates are skipped. Use `--dry-run` to preview the plan without
writing.
The export/import pair is the recommended stagingproduction sync path; bindings
are not exposed over REST in 2.0.
### What variables can I use inside a bound template?
A binding template sees four layered variable sources (later layers override earlier
ones):
* **Global variables** — the `#set` block in Settings Spintax. Site-wide.
* **Per-binding overrides** — a `#set` block in the binding’s Variables tab. Applies
to that binding only.
* **Post context** (opt-in checkbox) — `%post_id%`, `%post_title%`, `%post_url%`,`%
post_slug%`, `%post_date%`, `%post_modified%`, `%author_id%`, `%author_name%`.
* **ACF sibling fields** (opt-in checkbox, ACF-target bindings only) — every top-
level text / textarea / wysiwyg field in the same ACF group, available as `%acf_
%`. Siblings are always fresh on save: the binding runs after ACF
persists.
The binding’s source can also use the rest of the Spintax syntax (`{a|b|c}`, `[a
|b]`, `{?VAR?then|else}`, `{plural %N%: …}`, `#include "slug"`, `/#comment#/`).
### How do I schedule bindings to run automatically?
Two trigger paths, both configurable per binding under “Triggers”:
* **Fire on post save** (checkbox, default on) — runs after the post (and ACF,
if present) finishes saving. Skipped on autosaves, bulk-edits, batch REST imports,
revisions, and trash flips.
* **Cron schedule** (dropdown: disabled / hourly / twicedaily / daily) — each binding
gets its own scheduled tick. With Action Scheduler installed the tick enqueues
an async walk; without it, the walk runs synchronously on the cron worker.
For a one-off “apply now”, click **Bulk Apply** (async, needs Action Scheduler)
or **Run now** (synchronous, admins) on the binding card.
### How does the plugin handle manual edits to bound fields?
Each binding signs its last-rendered value and re-checks the target before every
write. With **Preserve manual edits** enabled (default):
* If the current value still matches the last render, the binding is free to regenerate.
* If the value has been edited outside the binding, the run is skipped and the
skip is logged.
Pair this with **Regenerate on every save** for a “refresh on save unless edited”
workflow. With **Auto-seed empty fields** alone, the binding only writes when the
target is empty — manual edits are preserved by definition.
Cold-start safety net: when a binding first sees a post with non-empty target content
and no prior render on file, it treats the existing value as a manual baseline and
skips that post until the field is cleared or the binding’s “Initialize from current
value” flow is run.
### I edited a template. Why aren’t the changes showing up on the front end?
Bindings are a **pre-generation** system, not a render-on-read layer. The rendered
string is stored in the target field; consumers (themes, blocks, REST readers) get
that stored value directly. Editing the source template doesn’t propagate to existing
posts until a trigger writes a fresh value to each one.
When you edit a template that has bindings pointing at it, the plugin:
1. Bumps an internal render-cache version on each affected binding.
2. Surfaces an admin notice on the template-edit screen (“N bindings depend on this
template”).
3. Shows a “Stale: source template edited” badge on each affected binding’s card.
To push the new content to existing posts, click **Bulk Apply** on each affected
binding (or run `wp spintax bindings apply --binding= --all` from the CLI).
The Stale badge only clears when the entire walk completes with zero failures —
partial-failure walks keep the badge so you notice the divergence and retry.
### Is there a hard cap on bindings?
200 bindings per site. The store is a single autoloaded option (~500 bytes per binding),
and the cap keeps autoload memory bounded. If you genuinely need more, please open
an issue with your use case.
### Which fields can’t I bind to?
The form rejects a handful of unsafe targets at save time:
* WordPress-internal meta keys (anything starting with `_wp_`, `_edit_`, `_oembed_`,
etc.).
* Plugin-internal `_spintax_*` slots used to store source, signatures, and cache
versions.
* `wp_posts` columns like `post_title`, `post_content`, `post_excerpt`. These are
not post-meta and writing to them via the meta API would silently create shadow
rows.
* The same target name already bound by another binding — one binding per (post
type, target field), whether the kind is ACF or post-meta.
* For ACF targets: the stable ACF field key must be present and resolvable when
ACF is loaded.
### On multisite, are bindings shared across the network?
No — bindings are per-site. Each subsite manages its own. Use `wp --url=site2 spintax
bindings import --file=site1-bindings.json` to copy bindings between subsites via
the WP-CLI export/import round-trip.
### Can I manage bindings via REST?
Not in 2.0; bindings are admin-only. The `wp spintax bindings` WP-CLI surface covers
stagingproduction sync scenarios. REST API exposure is tracked for a later release.
### I’m coming from `nested-spintax-for-acf`. Is there a migration path?
Yes. After activating Spintax 2.0, a dismissible admin banner points to **Tools
Spintax Migration**. The wizard scans for predecessor data, shows a per-row preview,
and creates bindings deduped by `(post type, target field)`. Per-post sources and
variables are copied non-destructively — the old plugin’s data stays in place until
you delete it.
## Reviews
There are no reviews for this plugin.
## Contributors & Developers
“Spintax” is open source software. The following people have contributed to this
plugin.
Contributors
* [ Franky ](https://profiles.wordpress.org/301st/)
[Translate “Spintax” into your language.](https://translate.wordpress.org/projects/wp-plugins/spintax)
### Interested in development?
[Browse the code](https://plugins.trac.wordpress.org/browser/spintax/), check out
the [SVN repository](https://plugins.svn.wordpress.org/spintax/), or subscribe to
the [development log](https://plugins.trac.wordpress.org/log/spintax/) by [RSS](https://plugins.trac.wordpress.org/log/spintax/?limit=100&mode=stop_on_copy&format=rss).
## Changelog
#### 2.1.1
* UX (Bindings list): “Bulk Apply” button now disables and exposes a tooltip pointing
at the Run-now / WP-CLI fallback when Action Scheduler isn’t installed — previously
the click hit the `no_action_scheduler` error path so users had to click-to-learn.
* UX (Bindings list): clean synchronous Run-now walks now write a log entry too(`
Bulk Apply run_synchronously completed for binding — wrote=N skipped=M cleared
=K`), so the “View details in Logs ” CTA on the success notice always lands on
a populated page. Previously only failures logged.
* UX (Bindings form): the stale-source banner above the edit form now mirrors the
list-view’s Bulk Apply / Run-now pair. Without Action Scheduler, Bulk Apply is
disabled with the same explanatory tooltip and Run-now is promoted to the primary
action — previously the banner’s only CTA routed straight into the no-AS error
path.
* UX (Bindings form): the ACF field picker no longer collapses to an empty list
after you select a field and refocus the input. The display string the picker
writes (`name (field_key)`) is now stripped before the haystack filter, so “browse
without retyping” works as documented.
* UX (Bindings form): defensive — the ACF field-key row is hidden unless `kind=
acf_field` exactly (previously hid only when `kind=post_meta`, leaving an empty-
kind edge case where the row could render without `hidden`).
* UX (Bindings list): Run-now capability failure now redirects back to the binding’s
edit form, consistent with the rest of the binding-edit error paths, instead
of bouncing to the silent list view.
* UX (Settings): the **Max log entries** ring-buffer size (clamped 10–5000, default
200) is now exposed as a form field on Settings Spintax. The option key was
already wired up internally; this release adds the missing control.
* Internal: tightened `test_run_now_handler_rejects_non_admin` — replaces a conditional
soft assertion with two unconditional invariants (walk-lock never acquired, no“
Wrote N” success flash).
* Internal: 520 PHPUnit tests, 950 assertions (was 514 / 938 in 2.1.0).
#### 2.1.0
* UX (Settings): Spintax Settings is now also reachable from the Spintax submenu(
under Bindings), not only from WP Settings Spintax — both menu paths resolve
to the same page.
* UX (Settings): Default Cache TTL and per-template Cache TTL no longer use a bare
seconds input. Both surfaces now offer human presets (No caching / 1 hour / 6
hours / 1 day / 1 week / 1 month) plus a “Custom…” option for any exact-seconds
value.
* UX (Settings): “Purge All Template Caches” button moved inline into the Default
Cache TTL row.
* UX (Bindings): New **Logs** admin page under Spintax Logs — newest-first table
of ring-buffer entries with level filter, substring search, pagination clamped
to settings.logs_max. Editors view; admins clear. Replaces the pre-2.1.0 “Check
logs” admin notice that pointed at a screen that didn’t exist.
* UX (Bindings): Admin notices that point at logs (Bulk Apply enqueued, etc.) now
ship a real “View progress in Logs ” link. The flash-notice trait accepts a `{
text, action_url, action_label}` payload alongside legacy strings.
* UX (Bindings): Binding edit / create form is now a three-tab layout (Source &
Target / Behavior / Test). WAI-ARIA tablist + keyboard navigation (Arrow keys,
Home / End). Validation errors redirect back to whichever tab the offending field
lives on; the active tab survives the PRG round-trip via flash transient and `?
active_tab=` query arg.
* UX (Bindings): ACF field picker on the form is now a custom searchable combobox(
replaces the buggy `` + `