Skip to main content

Queue, Scheduler & Operations​

Static Publisher is designed around queued jobs and external execution.

Runtime files​

The plugin writes state under wp-content/uploads/smartcloud-static-publisher/runtime, including:

  • config.json
  • queue.json
  • current-run.json
  • last-run.json
  • export.lock

Logs live under the configured log directory, and finished jobs archive their artifacts under archive/<timestamp-command-jobId-status>/.

Queue commands​

The admin UI can enqueue these commands:

  • publish
  • crawl
  • deploy
  • invalidate
  • retry-timeouts
  • url for a single-path run

Temporary AWS credentials can be attached to publish, deploy, and invalidate jobs. They are injected only into the child process environment for that job and are redacted from admin status payloads.

Scheduler model​

Scheduler rules are evaluated by publisher-exporter queue-runner at the start of each runner invocation.

Important implications:

  • the plugin does not spawn the runner by itself,
  • production setups should use cron, systemd timers, CI, or another external scheduler,
  • a 1-minute runner tick is the recommended baseline,
  • duplicate-equivalent jobs are skipped within the current interval bucket.

Typical Linux cron pattern:

* * * * * /usr/bin/flock -n /tmp/static-publisher.cron.lock \
  publisher-exporter queue-runner \
  --runtime-dir /var/www/site/wp-content/uploads/smartcloud-static-publisher/runtime \
  --max-jobs 1 >> /var/www/site/wp-content/uploads/smartcloud-static-publisher/logs/queue-runner-cron.log 2>&1

Deployment profiles​

Static Publisher treats the top-level target settings as the base target. Extra targets live under deploymentProfiles and are selected during deploy or invalidate.

This lets you:

  • crawl once,
  • deploy to the base target,
  • reuse the same artifact for staging, production, or client-specific targets,
  • avoid re-crawling the origin for every promotion step.

If a profile changes targetOrigin, prefer an absolute rewrite mode so deploy can retarget the already crawled artifact safely.

Logs and retry workflow​

  • root log files are the current working set,
  • finished, failed, and stopped jobs archive gzip-compressed log artifacts and job.json,
  • retry-timeouts resolves retry URLs from the newest archived full crawl or publish run when possible,
  • old archives should be pruned with publisher-exporter prune-logs from a retention job.

Off-host execution​

If the WordPress host cannot run Node, Playwright, or cron, process the queue from another machine that can see the same runtime directory, or download a queued job config and replay it from your own shell or CI runner.