Skip to main content

Static Publisher Overview​

Static Publisher turns WordPress into the editing and control layer for a professional static publishing pipeline.

Unlike a frontend widget plugin, Static Publisher is intentionally split into two coordinated parts:

  • WordPress plugin admin for configuration, queueing, status, diagnostics, and log access.
  • External exporter for crawl, rewrite, deploy, invalidate, and scheduler-driven execution.

That split is deliberate. The plugin does not shell out from PHP. It writes deterministic runtime JSON files, and the external Node.js runner processes them on a machine where Node.js, Playwright, filesystem access, and AWS credentials already exist.

What Static Publisher is good at​

  • publishing WordPress sites as static artifacts for S3 + CloudFront,
  • crawling the rendered frontend instead of only database content,
  • rewriting source URLs for staging or production targets,
  • queueing publish/deploy/invalidate work from WordPress admin,
  • reusing one crawl artifact across multiple deployment targets,
  • keeping WordPress as the editorial control plane while AWS becomes the delivery runtime.

Control plane vs execution engine​

Think about the product in two layers:

  • Control plane in WordPress: site owners configure runtime paths, target settings, job queueing, diagnostics, and scheduler rules from a familiar admin screen.
  • Execution engine outside WordPress: the exporter runs from shell, CI, cron, or a dedicated runner host and performs the heavy lifting against the fully rendered site.

This makes the model a better fit for production environments than a PHP-only exporter. The WordPress server does not need to run Playwright, manage shell execution, or hold long-lived deployment credentials in the request path.

Typical fit​

Static Publisher is a strong fit when you need one or more of these patterns:

  • WordPress stays private, but the public site should be edge-delivered,
  • the public runtime should live in a customer-owned AWS account,
  • crawl/deploy jobs need repeatable logging and external automation,
  • one environment should publish to several targets such as staging and production,
  • the static site later needs protected routes, Cognito login, AI, or backend-connected forms.

What this documentation covers​

  • Publishing Architecture — the product split, AWS delivery path, and how Static Publisher relates to the wider WP Suite stack
  • External Exporter Setup — host prerequisites, Node/Playwright install, and first-run commands
  • Operations — runtime files, queue workflow, scheduler rules, logs, and deployment profiles