Sign In

Static WordPress Publishing Queue and 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

Targeted content-sync also maintains baseline, cursor, checkpoint, candidate manifest, impact-plan, deploy-diff, and invalidation state in this runtime directory. These files are operational state, not disposable cache, while a content-sync job is queued, running, or waiting for retry.

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

content-sync jobs are created by Professional or Agency scheduler rules. They are not a free-form manual URL command: the job claims an immutable range from the WordPress content journal and uses the rule's saved scope. Incremental publishing and targeted content sync require the same active subscription level.

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.
  • repeated content-sync demand is coalesced; changes arriving during a claimed range become trailing work rather than extending the running range.

Before enabling a content-sync schedule, run a successful normal full or incremental publish. That release establishes the trusted manifest and verified baseline. Theme, plugin, permalink, sitemap, rewrite, scope, or deployment target changes intentionally mark the baseline stale and require another normal publish. The Scheduler Settings screen reports this state directly.

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.

Content-sync retries preserve the same claimed range and checkpoint. The bounded backoff prevents a failing target from being hammered continuously. If an operator abandons a queued retry in WordPress, its local plan is removed but the journal cursor remains unchanged; a later scheduler tick can rediscover the unacknowledged range. See Targeted Content Sync for the deletion and baseline safety rules.

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.