Developer Articles
15 coding-level guides. For end-user setup help, see the Support Center.
How PizzaLayer's six Custom Post Types work: pizzalayer_toppings, pizzalayer_crusts, pizzalayer_sauces, pizzalayer_cheeses, pizzalayer_drizzles, and pizzalayer_cuts. Slug constants, register_post_type() arguments, and capability mapping.
Full reference for the /wp-json/pizzalayer/v1/render endpoint — parameters, response format, authentication, and usage examples for headless builds.
Developer guide to building a PizzaLayer 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 PizzaLayerPro and the base plugin.
Developer reference for the JavaScript events API — available events, instance methods via NP.createInstance(), and the window.PizzaLayerProBuilder public API exposed by PizzaLayerPro.
Every template must register window.PizzaLayerAPI exposing getState() that returns a normalized flat layers[] array. Required for PizzaLayerPro 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 PizzaLayer 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 /pizzalayer/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.
Working in the Codebase
No union types, no match expressions, no named arguments, no str_starts_with() or str_ends_with(). The codebase ships on shared hosting that pins to 7.4, so newer syntax breaks fatal-on-load.
All <script> and <style> blocks must be extracted to enqueued files. Dynamic PHP data passes via wp_localize_script() or wp_add_inline_script(), never echoed inline.
Templates must expose window.PizzaLayerAPI with a normalized flat layers[] array from getState(). Pro polls this at 120ms — events alone aren't reliable across the template family.