Skip to main content

1.27.0 - Exclude individual posts from a soft gated post type

· 4 min read
Konstantin Brazhnik
Senior Full Stack Engineer @ Yoko Co

Version 1.27.0 lets a single post opt out of Soft Gate when its whole post type is gated. Until now the only per-post control was an opt-in, which did nothing on a post type that was already gated wholesale — so one public post inside a gated type meant taking the whole type off the list.

  • [NEW FEATURE] Adds Exclude this post from soft gating, in both the block editor panel and the classic-editor metabox. It appears only on post types selected under Enable Soft Gate by post type, and it replaces Enable soft gate on this post rather than sitting beside it — an opt-in cannot add anything to a post that is already gated, so showing both would only offer a control that does nothing.

  • [FIX] The per-post panel now saves on custom post types in the block editor. It never did: two things were wrong at once, and both applied to every CPT generated from yoko.yml — so on a lot of sites the only post types the panel worked on were core Posts and Pages. The controls rendered, took a value, and lost it on save, with a 200 coming back.

    • The meta keys were registered at init priority 10, one tick before Yoko::setup_ctps registers the YAML CPTs at priority 11, so every generated type was enumerated before it existed. Registration now runs at priority 99.
    • register_post_meta( …, show_in_rest ) is only half the requirement: WP_REST_Posts_Controller adds the meta object to a post type's schema only when the type supports custom-fields, and the generated CPTs are registered without it — so the REST response carried no meta at all and the editor's write had nowhere to land. The support is now switched on for the post types soft-gate meta is registered for. Because that support also gives the classic editor its raw Custom Fields metabox, that box is removed again for the types we changed; types that already had the support are left as the site configured them.

  • [NEW FEATURE] Adds Enable Ad-Hoc Soft Gate by post type. A post type in this list gates nothing on its own — it makes the per-post opt-in available. The two lists together decide where the Soft Gate controls appear at all: a post type in neither list now gets no metabox and no sidebar panel, which keeps a tall metabox off the post types nobody is ever going to gate.

  • [IMPROVEMENT] The Soft Gate settings are hidden while Enable Soft Gate is Disabled, so the section is one field until you turn it on. Hidden fields still save — switching the master toggle off does not clear anything.

Upgrade note: an opt-in now needs its post type listed

A per-post opt-in used to work on any post type. It is now only honored on a type in the ad-hoc list, because the per-post control is hidden on an unlisted type — honoring the meta there would leave a post gated with nothing anywhere to switch it off.

So that this does not silently switch off lead capture on upgrade, a one-time migration seeds the ad-hoc list from post types that already have opted-in posts. Post types already gated wholesale are skipped, since their posts stay gated regardless. The migration runs once and will not undo a later change you make.

The resolution order is now: master toggle off, or hard-gate roles present, and the post is not soft gated; otherwise a wholesale-gated post type gates every post in it unless that post is excluded; otherwise an opt-in decides, but only on a post type in the ad-hoc list.

Nothing is lost when you change your mind

The opt-in and the exclusion are separate post meta keys, and only the one that applies is ever read. Removing a post type from the list brings its per-post opt-ins back into effect; adding it again brings the exclusions back. Neither overwrites the other.

Full documentation: Soft Gate → Per-post configuration.