Spintax

Go to Spintax > Add New in the WordPress admin. Enter a title and your spintax markup in the editor.

• {a|b|c} — randomly picks one option
• [a|b|c] — permutation: picks N elements, shuffles, joins with space
• [<minsize=2;maxsize=3;sep=", ";lastsep=" and "> 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

• 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)

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.

Yes: [spintax slug="greeting" name="Alice" city="Moscow"] makes %name% and %city% available inside the template.

Yes, since 2.2. On a single-product page the plugin auto-detects the current product and exposes it to [spintax] and spintax_render() as %product_*% variables — for example %product_name%, %product_slug%, %product_sku%, %product_type%, %product_stock_status%, %product_categories%, %product_tags%, %product_short_description%, and one %product_attribute_<slug>% per product attribute. So a template embedded as [spintax slug="product-seo-block"] on a product renders that product's data, and the same template on two products gets two separate cached variants. Pricing (%product_price% and friends) is intentionally not exposed: it is volatile commerce data, not generated copy, and folding it into templates would churn the render cache on every price change. To target a specific product regardless of the current page, pass [spintax slug="…" product_id="123"]; any explicit variable you pass always overrides the auto-detected one. WooCommerce is optional: with it inactive, or on non-product pages, behavior is unchanged. Since 2.4 the plugin can also write generated copy into a product — see the next question. Product loops and cards are still deferred.

Yes, since 2.4. Create a binding with the target kind WooCommerce product field, on the Product post type, and pick Description or Short description. Every matching product then gets its own rendered copy — seeded when the field is empty, or regenerated on save if you ask for that — through the same machinery as ACF and post-meta bindings: cron schedules, Bulk Apply, WP-CLI, and the Logs page. Turn on Expose WooCommerce product data in the binding's Variables tab and the template can use that product's own facts — %product_name%, %product_sku%, %product_type%, %product_categories%, %product_tags%, %product_attribute_<slug>% — so each product gets copy that is actually about it, not just a differently-worded version of the same sentence. Three deliberate limits:

• Only those two fields are writable. Price, SKU, stock and sale dates are commerce data, not copy. A template cannot reach them — the whitelist is enforced when you save the binding and again before every write.
• Manual edits win. With "Preserve manual edits" on (the default), a description a human has changed is never overwritten; the binding skips it and says so in the Logs.
• Writes go through WooCommerce. Not straight into the database — so WooCommerce's own caches, lookup tables and save hooks stay consistent, and other plugins that listen for product saves still hear them.

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.

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.

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=<id> --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.

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.

Spintax → Logs in the admin sidebar. Both paths log a completion entry per walk (e.g. Bulk Apply run_synchronously completed for binding <id> — 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.

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=<id> [--all|--post=<id>] — run a binding against every matching post (--all) or a single post (--post=<id>). This is the synchronous fallback path for Bulk Apply.
• wp spintax bindings test --binding=<id> --post=<id> — 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=<id>|--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.

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_<field_name>%. Siblings are always fresh on save: the binding runs after ACF persists.

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.

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.

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.

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.

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.

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.

Not in 2.0; bindings are admin-only. The wp spintax bindings WP-CLI surface covers staging→production sync scenarios. REST API exposure is tracked for a later release.

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.

Yes — it is published as a standalone open-source library, so a template you author here renders identically elsewhere:

• PHP: composer require spintax/core — https://packagist.org/packages/spintax/core
• JavaScript / TypeScript: npm i @spintax/core — https://www.npmjs.com/package/@spintax/core
• OpenCart 3.x: a separate extension built on the same engine.