Developer documentation

Veyo's core plugin covers the editor, cart, checkout, and print-ready export. Everything else — pricing rules, new design-item types, admin panels, export formats — is a drop-in addon. This section documents the SDK so you can build your own.

These pages assume you already have a licensed copy of Veyo Product Personalizer installed, with access to its plugins/ folder (where addon packages live) and a local WordPress install for testing.

How the addon system works

Every addon is a self-contained folder under plugins/{slug}/. Core auto-discovers any folder with a valid manifest.json — there are no core files to edit, and no registration step beyond dropping the folder in place. New addons are disabled by default until an admin turns them on from the Apps & Integrations screen.

A typical addon package looks like this:

plugins/my-addon/
  manifest.json          — required, describes the addon
  bootstrap.php          — PHP entry point (server-side hooks, REST routes)
  dist/my-addon.bundle.js   — designer/admin JS bundle
  dist/my-addon.bundle.css  — matching styles
  src/                    — source (Vue components, TS modules)
  hooks/                  — PHP hook registration files
  admin-js/, admin/css/   — assets loaded only on wp-admin screens

See the manifest reference for every field manifest.json supports, including which platform surfaces (designer, admin, storefront, server) an addon runs on and what services it declares it needs (database, routes, media, etc.).

Platform abstraction

Core logic is written against a PlatformInterface rather than talking to WordPress directly — auth, products, tax, uploads, and email all go through a platform services layer. The WordPress/WooCommerce implementation is what ships today; the same addon code is designed to keep working as additional platforms (OpenCart, PrestaShop) are added. In practice this means: prefer the portable hook registry and services described in PHP hooks over calling WordPress functions directly wherever a portable equivalent exists.

Load order & dependencies

Each manifest declares a numeric priority — lower numbers load earlier. Addons that provide low-level primitives (like preflight checks) load early; addons that build on other addons (like Dynamic Pricing, which depends on the base pricing catalog from Printing & Pricing) load later and can declare that dependency explicitly via dependencies in the manifest. An addon whose declared requires version doesn't match the installed core version stays installed but is blocked from loading until it's compatible.

Extending the designer without a special registry

Design items are an open data shape with no closed type union — you're not limited to the built-in item kinds (text, image, shape…). A brand-new item type needs only three registrations:

  1. Create it via Veyop.designer.commands.addItem from a toolbar action.
  2. Render it via Veyop.itemRenderers.register.
  3. Export it via Veyop.imagePipeline.registerItemSvgExporter, sharing the same render function used on canvas so the live preview and the print-ready export always match.

Save, load, undo, and multi-select all work automatically once those three pieces exist — see the full API in JS runtime API. The free Text Curve addon is a good real-world reference for a self-contained designer-only addon (a toolbar action, an item renderer, and an SVG exporter, sharing one render function).

Real-world extension examples

Quick Personalization (Templates & Smart Layouts) is a storefront surface: it registers REST routes under veyop_register_rest_routes (notably /design-templates/quick-config and assignment endpoints) and ships a lightweight custom-element panel on the shop grid — without forking the core designer. Smart Color Mockups stay in core's product/mockup pipeline (platform services + designer config), showing how color re-tint and composite preview are product data, not a separate addon API. Prefer the same patterns: portable routes, platform services, and item renderers when you need new behaviour.

Signing & distribution

Addon packages are signed before distribution and verified on install — an addon whose signature doesn't match a trusted key is rejected. For local development, your wp-config.php can disable signature enforcement so you can iterate on an unsigned addon folder directly; leave enforcement on for anything installed on a production site.

Where to go next

Next: Addon manifest →