Linux 软件免费装

在这里免费安装WordPress以及其他软件

Banner图

SmartCloud Static Publisher

开发者 smartcloud
更新时间 2026年10月10日 21:08
PHP版本: 8.1 及以上
WordPress版本: 7.1
版权: MIT
版权网址: 版权信息

标签

export s3 cloudfront static site playwright

下载

1.0.12 1.0.17 1.0.2 1.0.23 1.0.24 1.0.3 1.0.7 1.0.9 1.1.0 1.0.18 1.0.27 1.0.26 1.0.8 1.0.0 1.0.11 1.0.6 1.0.10 1.0.13 1.0.14 1.0.5 1.0.16 1.0.1 1.0.20 1.0.21 1.0.15 1.0.19 1.0.22 1.0.4 1.0.25

详情介绍:

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 and the publishing destination.
  • Base S3 deployment target and optional CloudFront invalidation settings.
  • The Publish dialog for selecting an available task and target.

升级注意事项:

1.1.0 WP Suite admin navigation now groups everyday tasks by capability and detailed settings under Advanced. Existing settings and bookmarked admin URLs remain available; no configuration migration is required. 1.0.27 Install @smart-cloud/publisher-exporter 1.1.83 on each queue-runner host and restart the runner after active jobs finish. Additional stylesheet URLs are optional; review their sources before adding them in WP Suite General Settings. Existing exports and queue configuration need no migration. 1.0.26 Install @smart-cloud/publisher-exporter 1.1.81 on the coordinator. Before selecting a delegated cross-account target, deploy the updated worker stack with its exact S3-only target role and external ID, then reinstall the generated remote-workers.json. Configure the queue-runner user's named AWS profile with the separate coordinator target role when local S3 or CloudFront calls need that identity. 1.0.25 Install @smart-cloud/publisher-exporter 1.1.74 and restart the external queue runner before enabling page-cache purge. Keep purge disabled until a server adapter implements the generic provider contract and a real source request proves MISS-to-HIT behavior without caching authentication redirects or logged-in HTML. The first incremental crawl after upgrading may render all supported pages once because the global token schema now includes the site revision and configured dependency hashes. 1.0.24 After active jobs finish, install @smart-cloud/publisher-exporter 1.1.72 and restart every external coordinator queue runner. The saved-page counter fix applies to new jobs; it does not rewrite an active job's progress. Existing tested Lambda workers on 1.1.71 can remain in place because the 1.1.72 remote-worker bundle is byte-identical; no stack update or remote-workers.json replacement is needed solely for this counter fix. If upgrading older worker infrastructure, deploy workers with the 1.1.71 Chromium launch fix and install the regenerated remote-workers.json to enable direct DynamoDB intra-batch progress; older configs expose progress only after a batch completes. Render batching defaults to 5 URLs; review render, rewrite, and deploy batch sizes before increasing them. Republish targets produced by the earlier delegated rewrite implementation to replace incorrect S3 Content-Type metadata. 1.0.23 Install @smart-cloud/publisher-exporter 1.1.65 and restart the external queue runner. Before enabling Lambda delegation, deploy the updated worker stack and install its new remote-workers.json containing functions.asset. Existing mixed local/remote settings remain unchanged until an administrator explicitly saves the unified delegation and concurrency controls. 1.0.22 Install @smart-cloud/publisher-exporter 1.1.63 and restart the external queue runner so it writes the safe target/rule discovery snapshot, then restart or refresh Agent Composer MCP tool discovery after updating both plugins. The scheduling response now returns a job_id used by the read-only job-status tool. Before queueing a standard content-sync job, complete one successful normal publish so the selected rule and target pair has a ready baseline. 1.0.21 Install @smart-cloud/publisher-exporter 1.1.62 on every runner host. Before enabling Lambda rendering, rewriting, or deployment, redeploy the CDK stack and copy its newly generated remote-workers.json to the site's Static Publisher runtime directory; existing files without deployment targets are insufficient for delegated deploys. Remove obsolete PUBLISHER_REMOTE_* variables from cron. Run a crawl or publish to populate Consent candidates, and run one normal publish before relying on targeted plugin-resource updates. 1.0.20 AI Kit public release gating requires @smart-cloud/publisher-exporter 1.1.54. Install that exporter on the runner host, let the scheduler evaluate the saved content-sync rules, then complete one successful publish before enabling or expecting gated Knowledge Sync delivery. Existing Static Publisher workflows do not require AI Kit or this opt-in gate. 1.0.19 Install @smart-cloud/publisher-exporter 1.1.52 on every runner host, then complete one normal full or incremental publish to establish the new release baseline before resuming targeted content sync. 1.0.16 Sites with theme-specific taxonomy archives must install the matching theme routing integration, then run one successful normal full or incremental publish to establish the new release baseline. Existing content-sync retries retain their original impact plan; the successful normal publish supersedes it safely. 1.0.15 Review content-sync rules and add Page where needed; remove Media if previously selected. Save PRO Scheduler Settings, then run one successful normal full or incremental publish to establish a baseline for the updated release and scope. Previously overwritten rules must be re-entered. 1.0.14 Recommended for sites running AI Kit or other Composer ability providers alongside Static Publisher. The shared Hub now preserves operation and review-safety metadata independently of runtime ownership order. 1.0.13 Recommended for sites using targeted content sync. Run one successful normal full or incremental publish after upgrading to establish the new release baseline and populate trusted Media Library asset tokens. 1.0.12 Recommended for incremental exports containing Query Loops or paginated archives and for Professional or Agency sites using targeted content sync. Run one successful normal publish after upgrading to establish the required baseline. Multisite subsite tracking is opt-in and requires network activation. 1.0.11 Declares compatibility with WordPress 7.1. 1.0.10 Recommended for multisite installations using the shared WP Suite Hub. 1.0.9 Recommended dependency refresh away from deprecated SmartCloud Amplify UI releases. 1.0.5 Recommended compatibility update for safe shared WP Suite Theme CSS management and reliable frontend bootstrap data when CSS-rich settings are present. 1.0.4 Recommended compatibility update for sites running multiple WP Suite plugins. It prevents a shared Abilities class redeclaration during plugin loading or updates. 1.0.3 Adds incremental change-token support for file-backed public routes and improves documentation sidebar readability. No configuration changes are required. 1.0.2 Small admin cleanup. No configuration changes are required. 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, url, and Professional/Agency-only content-sync.
  • Content sync requires a successful normal publish baseline and processes only the configured post types, multisite scope, listings, archives, and sitemap surfaces.
  • 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.

How do Processing concurrency and Lambda delegation work?

Processing concurrency sets the local page-render, asset-download, and final rewrite worker counts together. When Delegate processing to Lambda is enabled, the same value is also the coordinator's requested fan-out for each delegated page-render, asset-fetch, rewrite, or deploy phase. With full delegation, rendered HTML and downloaded assets remain in the worker S3 workspace for Lambda rewrite and direct S3-to-S3 deployment; the coordinator does not download them for a second HTML scan or restage the completed export. It still owns the dynamic URL queues, safety and incremental decisions, compact manifests, retries, logs, invalidation, and terminal job state. The setting is not an account-wide Lambda concurrency limit: function reserved concurrency, regional quotas, other sites, available batches, and downstream capacity can reduce effective parallelism. Existing installations that saved different legacy settings for individual phases keep those values until an administrator changes the corresponding common control. The Configuration screen shows a warning for that mixed legacy state. Render, rewrite, and deploy batch sizes are configurable independently. A render batch reuses one Chromium process for up to 20 sequential pages; rewrite and deploy support larger bounded batches because they do not load WordPress. Runtime progress advances after each completed batch. Asset downloads use protocol-bounded batches of 20 URLs. Retry counts remain internal compatibility settings.

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.

Can deployment targets use different AWS accounts?

Yes. The base target and each extra deployment target can select an optional named AWS credential profile. Local S3 deploy and CloudFront invalidation resolve that profile from the queue-runner user's standard AWS shared config. Only the profile name is stored in WordPress; do not store access keys in plugin settings. Temporary credentials attached to a queued job take precedence. When S3 deploy is delegated to Lambda, the VM profile is not available inside Lambda. Configure that CDK target with an allowlisted cross-account role instead. The coordinator still uses the named profile for CloudFront invalidation when configured.

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.1.0 1.0.27 1.0.26 1.0.25 1.0.24 1.0.23 1.0.22 1.0.21 1.0.20 1.0.19 1.0.18 1.0.17 1.0.16 1.0.15 1.0.14 1.0.13 1.0.12 1.0.11 1.0.10 1.0.9 1.0.8 1.0.7 1.0.6 1.0.5 1.0.4 1.0.3 1.0.2 1.0.1 1.0.0