{"id":381286,"date":"2026-10-12T08:53:47","date_gmt":"2026-10-12T08:53:47","guid":{"rendered":"https:\/\/wordpress.org\/plugins\/deployment-guard\/"},"modified":"2026-10-12T08:53:39","modified_gmt":"2026-10-12T08:53:39","slug":"stillgate","status":"publish","type":"plugin","link":"https:\/\/wordpress.org\/plugins\/stillgate\/","author":14779575,"comment_status":"closed","ping_status":"closed","template":"","meta":{"version":"0.1.1","stable_tag":"0.1.1","tested":"7.1.3","requires":"6.6","requires_php":"8.1","requires_plugins":null,"header_name":"Stillgate \u2014 Editorial Freeze for Deployments","header_author":"Linards Lazdins","header_description":"Locks editorial changes during deployments and migrations while the site stays online.","assets_banners_color":"","last_updated":"2026-10-12 08:53:39","external_support_url":"","external_repository_url":"","donate_link":"","header_plugin_uri":"https:\/\/github.com\/digibold\/wp-stillgate","header_author_uri":"https:\/\/createit.lv","rating":0,"author_block_rating":0,"active_installs":0,"downloads":30,"num_ratings":0,"support_threads":0,"support_threads_resolved":0,"author_block_count":0,"sections":["description","installation","faq","changelog"],"tags":{"0.1.1":{"tag":"0.1.1","author":"twelvell","date":"2026-10-12 08:53:39","revision":3740892}},"upgrade_notice":{"0.1.1":"<p>Renamed from Deployment Guard. If you installed 0.1.0 from GitHub, install this\nversion, deactivate Deployment Guard, activate Stillgate, and only then delete\nthe old copy; the FAQ has the exact steps. <code>wp deployment-guard<\/code> is now <code>wp stillgate<\/code>.<\/p>","0.1.0":"<p>Initial release.<\/p>"},"ratings":[],"assets_icons":[],"assets_banners":[],"assets_blueprints":{},"all_blocks":[],"tagged_versions":["0.1.1"],"block_files":[],"assets_screenshots":[],"screenshots":[]},"plugin_section":[],"plugin_tags":[16271,8485,263488,732,4155],"plugin_category":[52,59],"plugin_contributors":[286046],"plugin_business_model":[],"class_list":["post-381286","plugin","type-plugin","status-publish","hentry","plugin_tags-deployment","plugin_tags-editorial","plugin_tags-freeze","plugin_tags-maintenance","plugin_tags-migration","plugin_category-performance","plugin_category-utilities-and-tools","plugin_contributors-twelvell","plugin_committers-twelvell"],"banners":[],"icons":{"svg":false,"icon":"https:\/\/s.w.org\/plugins\/geopattern-icon\/stillgate.svg","icon_2x":false,"generated":true},"screenshots":[],"raw_content":"<!--section=description-->\n<p>Deploying a WordPress site \u2014 syncing a database, pushing files, running a\nmigration \u2014 usually needs a window where the database will not change\nunderneath you. In practice, editors keep working, and a post, upload, or\nmenu change made mid-sync can be silently lost. Stillgate puts the\n<em>backend<\/em> into a controlled editorial freeze during that window, while the\npublic frontend keeps working normally the whole time.<\/p>\n\n<p><strong>What a freeze does<\/strong><\/p>\n\n<p>While active, a logged-in user without the <code>deployment_guard_bypass<\/code>\ncapability is blocked from creating, editing, deleting, or restoring\nprotected content \u2014 posts, pages, custom post types, media, revisions,\ntaxonomies and terms, navigation menus, widgets, or the Customizer \u2014\nthrough classic wp-admin, the block editor, the REST API, and XML-RPC;\nWP-CLI commands and WP-Cron events are blocked from the same content\nchanges. Scheduled posts of a protected type do not publish while the\nfreeze is active; they remain scheduled and publish normally, through\nWordPress's own mechanism, once it ends.<\/p>\n\n<p>A freeze can be turned on immediately, or configured as a scheduled window\nin the site's own timezone. Whether it is active is computed from the\ncurrent time and stored configuration on every relevant request \u2014 it never\ndepends on a WP-Cron event firing on time.<\/p>\n\n<p><strong>Bypass is capability-based, not role-based<\/strong><\/p>\n\n<p>Roles with <code>manage_options<\/code> (Administrator, by default) receive the\n    deployment_guard_bypass capability automatically on activation \u2014 the\ncheck is against the capability, never hardcoded to a role's name, so a\ncustom role can be granted it too. A bypass holder can keep working during\na freeze, though their own changes can still be lost if a deployment\nproceeds concurrently; the freeze protects everyone <em>else's<\/em> content.<\/p>\n\n<p><strong>WP-CLI is not exempt.<\/strong> <code>wp post update<\/code>, <code>wp term create<\/code>, <code>wp media\nimport<\/code>, and equivalent commands from other plugins are blocked the same\nway during a freeze; <code>--user=&lt;account with bypass&gt;<\/code> is the explicit way to\nact as a specific person from the command line. Stillgate's own <code>wp\nstillgate status|enable|disable|schedule<\/code> commands keep working,\nbecause they only change Stillgate's own state.<\/p>\n\n<p><strong>Security and privacy<\/strong><\/p>\n\n<p>Stillgate makes no outbound HTTP requests, sends no data to any\nexternal service, requires no account or license key, and collects no\ntelemetry. It uses no custom database table \u2014 two options, both removed on\nuninstall \u2014 and its small internal activity log never stores request\npayloads, message bodies, or IP addresses.<\/p>\n\n<p><strong>Known limitations, stated plainly<\/strong><\/p>\n\n<ul>\n<li>A bypass holder's own changes are not protected from being overwritten.<\/li>\n<li>Freeze state lives in the database; a database import during a migration\ncan lift or copy it. The <code>DEPLOYMENT_GUARD_FORCE<\/code> constant in\n  wp-config.php (the boolean <code>true<\/code> or <code>false<\/code>; any other value is\nignored) forces the freeze on or off independently of the stored state,\nfor exactly this situation.<\/li>\n<li>With a persistent object cache not shared between WP-CLI and web\nworkers, a CLI-issued change may need <code>wp cache flush<\/code> to take effect\nimmediately for web requests; a long-running PHP process keeps the state\nit read until it restarts.<\/li>\n<li>Changes that go around WordPress's own content functions and capability\nchecks are not blocked: direct database queries, third-party code that\nwrites content without checking the user's capabilities, plugin REST\nroutes with controllers of their own, and direct <code>wp_publish_post()<\/code>\ncalls.<\/li>\n<li>In WP-CLI and WP-Cron, post meta, term assignments to existing terms,\nwidgets, menu locations, theme mods and other options are not blocked,\nnor are term updates and deletions made during a cron event.<\/li>\n<li>Automated writes to protected content fail while a freeze is active:\ncron jobs such as emptying the trash or updating products, and plugin\nactivation routines run through WP-CLI.<\/li>\n<li>Restricted users cannot preview drafts of protected content during a\nfreeze.<\/li>\n<li>WP-Cron keeps running; unrelated events are unaffected, and only\npublishing protected scheduled content is held back specifically.<\/li>\n<li>Comments, Notes, users, plugins, themes, and general site settings are\nout of scope.<\/li>\n<li>Operates per site on Multisite in this version; there is no\nnetwork-wide freeze screen yet, and network activation or deactivation\naffects the current site's state only.<\/li>\n<\/ul>\n\n<p>Full architecture notes, the complete enforcement matrix, and every hook\nthis plugin exposes are documented in the <a href=\"https:\/\/github.com\/digibold\/wp-stillgate\">GitHub repository<\/a>.<\/p>\n\n<!--section=installation-->\n<ol>\n<li>Upload the plugin files to <code>\/wp-content\/plugins\/stillgate<\/code>, or\ninstall it through Plugins &gt; Add New &gt; Upload Plugin.<\/li>\n<li>Activate the plugin. Roles with <code>manage_options<\/code> receive the\n   deployment_guard_bypass capability automatically.<\/li>\n<li>Go to Tools &gt; Stillgate to configure a freeze, or use WP-CLI:\n   wp stillgate enable.<\/li>\n<\/ol>\n\n<!--section=faq-->\n<dl>\n<dt id=\"will%20this%20stop%20the%20public%20site%20from%20working%3F\"><h3>Will this stop the public site from working?<\/h3><\/dt>\n<dd><p>No. Stillgate only restricts editorial <em>writes<\/em> from logged-in\nusers without the bypass capability. Anonymous visitors, logged-in\ncustomers, comment submissions, and every other frontend read or write\nthat is not editorial content stay unaffected.<\/p><\/dd>\n<dt id=\"does%20this%20protect%20against%20database%20changes%20made%20outside%20wordpress%3F\"><h3>Does this protect against database changes made outside WordPress?<\/h3><\/dt>\n<dd><p>No. Stillgate enforces its freeze through WordPress's own request\nhandling (admin screens, REST, XML-RPC, WP-CLI, WP-Cron), capability\nchecks, and content functions. A direct database edit, a raw SQL script,\nor a completely separate application writing to the same database is\noutside anything a WordPress plugin can see or prevent.<\/p><\/dd>\n<dt id=\"does%20wp-cli%20bypass%20the%20freeze%3F\"><h3>Does WP-CLI bypass the freeze?<\/h3><\/dt>\n<dd><p>No. Commands that create, update, or delete protected posts, pages, media,\nand terms are blocked and exit with an error. Lower-level commands that\nwrite post meta, term assignments, widgets, menu locations, theme mods, or\nother options directly are not blocked. Stillgate's own <code>wp\nstillgate<\/code> commands keep working because they only change the\nfreeze state itself.<\/p><\/dd>\n<dt id=\"what%20happens%20to%20scheduled%20%28future-dated%29%20posts%20during%20a%20freeze%3F\"><h3>What happens to scheduled (future-dated) posts during a freeze?<\/h3><\/dt>\n<dd><p>A protected post scheduled to publish during an active freeze stays\nscheduled instead. It publishes normally, through WordPress's own\nmechanism, once the freeze ends.<\/p><\/dd>\n<dt id=\"does%20this%20work%20on%20multisite%3F\"><h3>Does this work on Multisite?<\/h3><\/dt>\n<dd><p>Yes, per site. Each site's freeze is configured and enforced\nindependently; there is no network-wide screen in this version. A Super\nAdmin is always treated as a bypass holder.<\/p><\/dd>\n<dt id=\"does%20this%20send%20any%20data%20anywhere%3F\"><h3>Does this send any data anywhere?<\/h3><\/dt>\n<dd><p>No. Stillgate makes no outbound HTTP requests and has no telemetry.\nEverything it stores stays in your own site's database.<\/p><\/dd>\n<dt id=\"i%20installed%200.1.0%20as%20%22deployment%20guard%22.%20how%20do%20i%20switch%20to%20stillgate%3F\"><h3>I installed 0.1.0 as \"Deployment Guard\". How do I switch to Stillgate?<\/h3><\/dt>\n<dd><p>Stillgate keeps the earlier release's stored settings, so nothing needs to be\nreconfigured, but both copies share them and only one can run. Install the new\nZIP without activating it, deactivate Deployment Guard (this ends a freeze that\nis active), activate Stillgate, and then delete the old copy while Stillgate is\nactive: Stillgate keeps the freeze configuration, the activity log and every\nrole's bypass capability through that deletion. Do not delete the old copy while\nStillgate is inactive, which erases them. If you activate Stillgate first, it\nstays idle and says so on the Plugins screen until you deactivate the old copy.\nWith WP-CLI: <code>wp plugin install stillgate.zip<\/code>, <code>wp plugin deactivate\ndeployment-guard<\/code>, <code>wp plugin activate stillgate<\/code>, <code>wp plugin delete\ndeployment-guard<\/code>.<\/p><\/dd>\n<dt id=\"i%20removed%20my%20own%20bypass%20capability%20by%20mistake.%20how%20do%20i%20recover%3F\"><h3>I removed my own bypass capability by mistake. How do I recover?<\/h3><\/dt>\n<dd><p>WP-CLI (<code>wp stillgate disable<\/code>) and the <code>DEPLOYMENT_GUARD_FORCE<\/code>\nconstant in <code>wp-config.php<\/code> both work independently of the\n    deployment_guard_bypass capability.<\/p><\/dd>\n\n<\/dl>\n\n<!--section=changelog-->\n<h4>0.1.1<\/h4>\n\n<p>Renamed from Deployment Guard to Stillgate. The stored settings, activity log\nand bypass capability carry over. The freeze notice now appears only on the\nscreens where editing is affected and explains how the freeze ends. See the\nfull changelog at\nhttps:\/\/github.com\/digibold\/wp-stillgate\/blob\/main\/CHANGELOG.md<\/p>\n\n<h4>0.1.0<\/h4>\n\n<p>Initial release. See the full changelog at\nhttps:\/\/github.com\/digibold\/wp-stillgate\/blob\/main\/CHANGELOG.md<\/p>","raw_excerpt":"Locks editorial changes during deployments and migrations while the public frontend stays fully available.","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin\/381286","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin"}],"about":[{"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/types\/plugin"}],"replies":[{"embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/comments?post=381286"}],"author":[{"embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wporg\/v1\/users\/twelvell"}],"wp:attachment":[{"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/media?parent=381286"}],"wp:term":[{"taxonomy":"plugin_section","embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_section?post=381286"},{"taxonomy":"plugin_tags","embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_tags?post=381286"},{"taxonomy":"plugin_category","embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_category?post=381286"},{"taxonomy":"plugin_contributors","embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_contributors?post=381286"},{"taxonomy":"plugin_business_model","embeddable":true,"href":"https:\/\/wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_business_model?post=381286"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}