內容簡介
Stillgate 外掛提供了一個編輯凍結的功能，確保在進行 WordPress 部署時，後端內容不會被修改，避免資料遺失。此外掛讓編輯者在部署期間無法更改受保護的內容，同時前端仍可正常運作。
【主要功能】
• 在部署期間凍結編輯功能
• 阻止特定用戶對內容的修改
• 支援即時或排程凍結設定
• 自訂角色可獲得繞過權限
• 保護所有用戶的內容不被更動
外掛標籤
開發者團隊
② 後台搜尋「Stillgate — Editorial Freeze for Deployments」→ 直接安裝（推薦）
原文外掛簡介
Deploying a WordPress site — syncing a database, pushing files, running a
migration — usually needs a window where the database will not change
underneath you. In practice, editors keep working, and a post, upload, or
menu change made mid-sync can be silently lost. Stillgate puts the
backend into a controlled editorial freeze during that window, while the
public frontend keeps working normally the whole time.
What a freeze does
While active, a logged-in user without the deployment_guard_bypass
capability is blocked from creating, editing, deleting, or restoring
protected content — posts, pages, custom post types, media, revisions,
taxonomies and terms, navigation menus, widgets, or the Customizer —
through classic wp-admin, the block editor, the REST API, and XML-RPC;
WP-CLI commands and WP-Cron events are blocked from the same content
changes. Scheduled posts of a protected type do not publish while the
freeze is active; they remain scheduled and publish normally, through
WordPress’s own mechanism, once it ends.
A freeze can be turned on immediately, or configured as a scheduled window
in the site’s own timezone. Whether it is active is computed from the
current time and stored configuration on every relevant request — it never
depends on a WP-Cron event firing on time.
Bypass is capability-based, not role-based
Roles with manage_options (Administrator, by default) receive the
deployment_guard_bypass capability automatically on activation — the
check is against the capability, never hardcoded to a role’s name, so a
custom role can be granted it too. A bypass holder can keep working during
a freeze, though their own changes can still be lost if a deployment
proceeds concurrently; the freeze protects everyone else’s content.
WP-CLI is not exempt. wp post update, wp term create, wp media
import, and equivalent commands from other plugins are blocked the same
way during a freeze; --user=
act as a specific person from the command line. Stillgate’s own wp
stillgate status|enable|disable|schedule commands keep working,
because they only change Stillgate’s own state.
Security and privacy
Stillgate makes no outbound HTTP requests, sends no data to any
external service, requires no account or license key, and collects no
telemetry. It uses no custom database table — two options, both removed on
uninstall — and its small internal activity log never stores request
payloads, message bodies, or IP addresses.
Known limitations, stated plainly
A bypass holder’s own changes are not protected from being overwritten.
Freeze state lives in the database; a database import during a migration
can lift or copy it. The DEPLOYMENT_GUARD_FORCE constant in
wp-config.php (the boolean true or false; any other value is
ignored) forces the freeze on or off independently of the stored state,
for exactly this situation.
With a persistent object cache not shared between WP-CLI and web
workers, a CLI-issued change may need wp cache flush to take effect
immediately for web requests; a long-running PHP process keeps the state
it read until it restarts.
Changes that go around WordPress’s own content functions and capability
checks are not blocked: direct database queries, third-party code that
writes content without checking the user’s capabilities, plugin REST
routes with controllers of their own, and direct wp_publish_post()
calls.
In WP-CLI and WP-Cron, post meta, term assignments to existing terms,
widgets, menu locations, theme mods and other options are not blocked,
nor are term updates and deletions made during a cron event.
Automated writes to protected content fail while a freeze is active:
cron jobs such as emptying the trash or updating products, and plugin
activation routines run through WP-CLI.
Restricted users cannot preview drafts of protected content during a
freeze.
WP-Cron keeps running; unrelated events are unaffected, and only
publishing protected scheduled content is held back specifically.
Comments, Notes, users, plugins, themes, and general site settings are
out of scope.
Operates per site on Multisite in this version; there is no
network-wide freeze screen yet, and network activation or deactivation
affects the current site’s state only.
Full architecture notes, the complete enforcement matrix, and every hook
this plugin exposes are documented in the GitHub repository.
