Developer Articles
15 coding-level guides. For end-user setup help, see the Support Center.
How PizzaTier's six Custom Post Types work: pizzatier_toppings, pizzatier_crusts, pizzatier_sauces, pizzatier_cheeses, pizzatier_drizzles, and pizzatier_cuts. Slug constants, register_post_type() arguments, and capability mapping.
Full reference for the /wp-json/pizzatier/v1/render endpoint — parameters, response format, authentication, and usage examples for headless builds.
Developer guide to building a PizzaTier template from scratch. Covers the six-file architecture, function namespacing with function_exists guards, CSS isolation, and JS instance pattern.
Reference guide for all apply_filters() hooks including ingredient data, rendered output, and Pro settings passing between PizzaTierPro and the base plugin.
Developer reference for the JavaScript events API — available events, instance methods via NP.createInstance(), and the window.PizzaTierProBuilder public API exposed by PizzaTierPro.
Every template must register window.PizzaTierAPI exposing getState() that returns a normalized flat layers[] array. Required for PizzaTierPro cart integration and any custom JS that reads builder state. Includes shape spec and event-vs-polling tradeoffs.
Deep dive into the file layout of a PizzaTier template: render.php, assets.php, settings.php, style.css, script.js, and meta.json. Function prefixing (pzt_yourname_), function_exists() guards, and how the loader discovers templates.
Server-side rendering and headless integration patterns. POST a state payload to /pizzatier/v1/render and receive an HTML fragment or JSON. Covers auth, caching headers, and rate limit guidance.
How to ship a Gutenberg-block-enabled template variant. Block registration, inner-block patterns, and how server-side render() falls back to the same render.php used by the shortcode.
Modify what gets rendered without forking a template. apply_filters() entry points covering ingredient lists, the canvas markup, the wrapper, and per-layer image URLs. Includes a worked example replacing the default crust filter.
Patterns for reading live builder state from external JavaScript without coupling to a specific template. Polling at 120ms (the Pro approach), the recommended event listeners, and avoiding double-dispatch bugs across multiple instances.
Why the codebase targets PHP 7.4 and what you can't use when contributing or building extensions: no union types, no match expressions, no named arguments, no str_starts_with()/str_ends_with(). Recommended polyfills.
Why classes extending WC_Product must be declared in the true global namespace using bracketed namespace syntax, not the plugin's PSR-4 namespace. The Pro Pizza product type as a worked example.
wp_add_inline_style() requires the target handle to already be enqueued; calling it on a registered-but-not-enqueued handle causes WordPress to flush raw CSS without <style> tags. How to order enqueue calls correctly for inline data.
Coding standards, PR workflow, the manual QA checklist, and the lint scripts run on every change. PHP lint + JS brace-balance + a Cypress smoke pass before merge.
Before you open a PR
Skip union types, match expressions, named arguments, and str_starts_with() / str_ends_with(). Plenty of shops run on shared hosting pinned to 7.4, where newer syntax dies the moment the file loads.
Pull every <script> and <style> block out into a properly enqueued file. Hand dynamic PHP data over with wp_localize_script() or wp_add_inline_script() — never echo it straight into the markup.
Every template has to publish window.PizzaTierAPI, and getState() must return a flat, normalized layers[] array. Pro reads it on a 120ms poll, since events on their own don't hold up consistently across all the templates.