Linux 软件免费装
Banner图

SmartCloud Static Publisher

开发者 smartcloud
更新时间 2026年6月23日 16:48
PHP版本: 8.1 及以上
WordPress版本: 7.0
版权: MIT
版权网址: 版权信息

标签

export s3 cloudfront static site playwright

下载

1.0.1 1.0.0

详情介绍:

Static Publisher is a WordPress plugin + Node.js exporter workflow for deterministic static publishing. Static Publisher is part of the WP Suite product family by Smart Cloud Solutions, Inc. WP Suite keeps WordPress as the CMS and editing layer, while optional connected features can extend selected workflows into modular AWS-backed services for identity, AI, APIs, workflows, protected routes, and static delivery. The free Static Publisher features described here do not require a WP Suite account, subscription, or WP Suite-managed AWS backend; you control any AWS credentials and target infrastructure you configure for publishing. Project repository and extended documentation: https://github.com/smartcloudsol/static-publisher It is designed for setups where WordPress is the editor/origin and production is served from static hosting (for example S3 + CloudFront). The plugin provides: The Node.js exporter provides: This plugin does not execute shell commands directly from PHP. Instead, it writes queue/config runtime files that an external Node runner executes. This shell-first design is intentional: rendered frontend pages can be exported by Playwright/Node while WordPress/PHP remains focused on queueing and configuration. This plugin is not affiliated with or endorsed by Amazon Web Services or the WordPress Foundation. All trademarks are property of their respective owners.

安装:

  1. Upload the plugin ZIP (or install from the WordPress plugin repository).
  2. Activate the plugin in WordPress.
  3. Open WP Admin -> SmartCloud -> Static Publisher.
  4. Configure source/target settings and queue an export job.
  5. Run the Node exporter in your environment so queued jobs are processed.
Install @smart-cloud/publisher-exporter separately on the queue-runner host. The plugin package itself does not ship the Node runtime or npm dependencies. Package docs: https://www.npmjs.com/package/@smart-cloud/publisher-exporter Direct CLI invocation from cron is the recommended setup. If you redirect cron stdout/stderr to a file, create that parent directory before enabling cron. Shell redirection will not create missing parent directories for you. sudo install -d -o <cron-user> -g <cron-user> -m 755 /path/to/wordpress/wp-content/uploads/smartcloud-static-publisher/logs Run one queued job manually on the runner host: publisher-exporter queue-runner --runtime-dir /path/to/wordpress/wp-content/uploads/smartcloud-static-publisher/runtime --max-jobs=1 Same host Linux cron example: SHELL=/bin/bash HOME=/home/<cron-user> PATH=/home/<cron-user>/.nvm/versions/node/v24.15.0/bin:/usr/bin:/bin PLAYWRIGHT_BROWSERS_PATH=/var/lib/playwright-browsers RUNTIME_PATH=/path/to/wordpress/wp-content/uploads/smartcloud-static-publisher/runtime LOG_PATH=/path/to/wordpress/wp-content/uploads/smartcloud-static-publisher/logs * * * * * /usr/bin/flock -n /tmp/static-publisher.cron.lock publisher-exporter queue-runner --runtime-dir "$RUNTIME_PATH" --max-jobs 1 >> "$LOG_PATH/queue-runner-cron.log" 2>&1 17 3 * * * publisher-exporter prune-logs --runtime-dir "$RUNTIME_PATH" --older-than-days 30 >> "$LOG_PATH/prune-logs-cron.log" 2>&1 If you want a stable launcher across Node upgrades under NVM, prefer a small ~/bin/publisher-exporter wrapper over a plain symlink to ~/.nvm/versions/node/vX.Y.Z/bin/publisher-exporter. A plain symlink to the versioned NVM path breaks after upgrades. Separate hosts with shared mounted storage: Keep outputDir and logDir storage-relative in admin, for example export and logs, then point the crawler host at its own local mount path of the shared publisher storage. Example crawler-host cron: SHELL=/bin/bash HOME=/home/<runner-user> PATH=/home/<runner-user>/.nvm/versions/node/v24.15.0/bin:/usr/bin:/bin PLAYWRIGHT_BROWSERS_PATH=/var/lib/playwright-browsers RUNTIME_PATH=/mnt/site/runtime LOG_PATH=/mnt/site/logs * * * * * /usr/bin/flock -n /tmp/static-publisher.cron.lock publisher-exporter queue-runner --runtime-dir "$RUNTIME_PATH" --max-jobs 1 >> "$LOG_PATH/queue-runner-cron.log" 2>&1 If postCrawlCopyMap also needs to see the WordPress tree from the crawler host, set STATIC_PUBLISHER_WP_ROOT (or WPSUITE_STATIC_PUBLISHER_WP_ROOT) on that host too. Windows / LocalWP manual run example: $env:STATIC_PUBLISHER_RUNTIME_DIR='C:\Local Sites\my-site\app\public\wp-content\uploads\smartcloud-static-publisher\runtime'; npx @smart-cloud/publisher-exporter queue-runner --runtime-dir $env:STATIC_PUBLISHER_RUNTIME_DIR --max-jobs=1 Windows / LocalWP scheduled run:
  1. Create a PowerShell wrapper file, for example C:\smartcloud-static-publisher\run-queue-runner.ps1.
  2. Put this into that file:
$env:STATIC_PUBLISHER_RUNTIME_DIR='C:\Local Sites\my-site\app\public\wp-content\uploads\smartcloud-static-publisher\runtime'; & 'C:\Program Files\nodejs\npx.cmd' '@smart-cloud/publisher-exporter' 'queue-runner' '--runtime-dir' $env:STATIC_PUBLISHER_RUNTIME_DIR '--max-jobs' '1'; exit $LASTEXITCODE
  1. In Windows Task Scheduler create a task with a trigger that repeats every 1 minute indefinitely.
  2. Use powershell.exe as Program/script and -NoProfile -ExecutionPolicy Bypass -File "C:\smartcloud-static-publisher\run-queue-runner.ps1" as Add arguments.

屏幕截图:

  • Core export configuration panel
  • S3 and CloudFront settings
  • Job queue and command selection
  • Runtime logs viewer

升级注意事项:

1.0.1 Recommended compatibility update in preparation for upcoming WP Suite Agency subscriptions. No configuration changes are required. 1.0.0 Initial release.

常见问题:

Does this plugin run crawling and deploy from PHP?

No. For safety and reliability, PHP only stores config and queue instructions. The actual crawl/deploy is performed by the Node exporter.

Does WordPress WP-Cron execute queued jobs automatically?

Not by default. This plugin does not spawn Node.js from PHP. Recommended production setup is system cron (or systemd timer) that runs publisher-exporter queue-runner.

Do Scheduler Settings run jobs by themselves?

No. Scheduler rules are evaluated only when the external publisher-exporter queue-runner process starts from cron, systemd timer, or Windows Task Scheduler. Important details:

  • Scheduler only adds matching jobs to runtime/queue.json; the same runner tick or a later tick then processes them through the normal queue.
  • Recommended cadence is every 1 minute.
  • Supported scheduled commands are publish, crawl, deploy, invalidate, retry-timeouts, and url.
  • The scheduler timezone field is currently informational for operations context; interval matching is based on elapsed minute buckets checked at each runner start.
  • If an equivalent queued or running job already exists for the same command, crawl mode, deployment profile, and URL, the rule is skipped for that interval bucket.

Can this run on LocalWP / Windows too?

Yes. Start publisher-exporter queue-runner or npx @smart-cloud/publisher-exporter queue-runner manually from PowerShell for one-off processing, or use Windows Task Scheduler with a repeating 1-minute trigger plus a small PowerShell wrapper. Linux production should use system cron.

Can I download a queued job and run it from another machine?

Yes. Use Download config next to the queued job, extract publisherConfig into publisher.config.json, then run the exact manualExecution.commands.jobPosix or manualExecution.commands.jobPowerShell command from the downloaded JSON. This replays the job outside WordPress and does not update queue state automatically.

Can I choose deploy strategy for S3?

Yes. Exporter config supports two SDK modes:

  • sdk-upload-delete
  • sdk-upload-only

Is deploy progress logged?

Yes. Deploy and invalidate now write detailed progress logs in addition to crawl logs. Use logLevel (error, warn, info, debug) to control verbosity.

Does SDK deploy re-upload unchanged files every time?

No. SDK deploy now skips unchanged files using S3 ETag + size fast checks, with checksum metadata fallback (x-amz-meta-wpsuite-sha256) when ETag is not decisive.

Can pages and assets use different concurrency values?

Yes. concurrency controls parallel page rendering workers, assetDownloadConcurrency controls the later asset download phase, and rewriteConcurrency controls the final text rewrite pass. If rewriteConcurrency is omitted it falls back to assetDownloadConcurrency, so existing configurations keep the earlier behavior.

How should I use blocked query fragments?

Use blockedSearchFragments for preview or editor query patterns that must never enter the crawl queue. The setting is empty by default. If your WordPress setup exposes plugin-specific preview URLs, add those fragments explicitly to your config. Typical examples include page-builder previews, WordPress Customizer preview parameters, multilingual editor preview flags, and similar per-plugin markers. This matters because exported page output paths ignore query strings, so a preview URL can overwrite the canonical output for the same page path.

Why is there a generator meta tag in exported HTML?

Sites without an active WP Suite subscription receive this tag in exported HTML pages: <meta name="generator" content="WPSuite.io Static Publisher" /> The exporter adds it during HTML rewrite only once per file, so repeated rewrite/deploy passes do not duplicate it. Sites with an active WP Suite subscription do not receive this tag.

Can I pass temporary AWS credentials from admin?

Yes, for publish, deploy, and invalidate jobs. Use the Temp AWS creds dialog in the Job Queue panel and provide:

  • AWS_ACCESS_KEY_ID
  • AWS_SECRET_ACCESS_KEY
  • AWS_SESSION_TOKEN (optional)
These are attached to the queued job and injected by queue-runner only for that job process.

Why use sitemap-based crawling?

It avoids non-deterministic router crawling and gives controlled page discovery, including sitemap index recursion.

Can I export only one URL?

Yes. Queue the url command with a specific path.

Does it support retries?

Yes. Timeout retries are supported (retry-timeouts) without requiring a full rerun. They now look at the newest archived full crawl or publish job logs, not at the most recent unrelated root log files from a later deploy or single-URL run.

Where are runtime and logs stored?

Runtime state lives under wp-content/uploads/smartcloud-static-publisher/runtime/. Exporter logs are written under wp-content/uploads/smartcloud-static-publisher/<logDir>/. After each finished, failed, or stopped job, queue-runner also writes gzip-compressed per-file artifacts plus job.json into wp-content/uploads/smartcloud-static-publisher/<logDir>/archive/<timestamp-command-jobId-status>/ together with the latest progress snapshot when available. Audit Log rows for finished and stopped runs can download those archived artifacts from WordPress admin. Use publisher-exporter prune-logs --runtime-dir /path/to/wordpress/wp-content/uploads/smartcloud-static-publisher/runtime --older-than-days 30 from daily cron if you want automatic retention cleanup.

Will it work with Elementor and lazy-loaded frontends?

Yes. Export uses Playwright rendering, so runtime-loaded markup/assets can be captured.

Where should Playwright browsers be installed when using cron?

Install them for the same OS user that executes the queue-runner cron job. If needed, set PLAYWRIGHT_BROWSERS_PATH to a shared location and ensure that cron user has access.

Can crawl run against self-signed certificates?

Yes. Enable Allow self-signed TLS certificates during crawl in admin. This should only be used for trusted internal environments. Keep it disabled for strict certificate validation.

更新日志:

1.0.1 1.0.0