BWS GP Layout Conditions

WordPress plugin that adds GeneratePress layout-state condition types to GenerateBlocks Pro, so blocks inside a Block Element can be hidden when the corresponding theme element is disabled.

Problem A: Layout Element settings don't apply to Block Elements

The Disable Element configuration in a Layout Element doesn't apply to Block Elements that replace theme sections. Of course, you can match or mirror the Location inclusion/exclusion settings between Layout and Block Elements, but if you want to toggle multiple elements in one place, rather than in every site-wide Block Element, you're out of luck.

This plugin tries to detect all the applicable settings from both Layout Elements and post settings at render time, and offers two ways to use them:

Workaround 1: GB Conditions

The plugin adds two new GenerateBlocks Pro condition types you can add to a block within a Block Element:

• Theme Element Status (gp_theme_element) — 8 rules: one per element state, plus one for GeneratePress' own featured-image slot.
• Theme Sidebar (gp_theme_sidebar) — 3 rules for the resolved sidebar layout.

Nothing is hidden automatically; you must configure the conditions yourself, with the granularity you want (e.g. separate conditions for the outer container of your Site Header, for the top bar section, and for the menu section).

Note: In the conditions, "Active" means not disabled by config, not that the element source is populated (e.g. Featured Image Active (post setting) is true on a thumbnail-less post — in case you want to use a fallback image).

Workaround 2: body classes

The plugin injects gp-no-{component} for each disabled state (unless GeneratePress already injects a class), to support custom CSS. See the table under Detection reference for the full list.

Problem B: Post-level toggles can hide too much

The post-level Disable Elements metabox applies display:none to GP wrappers like .site-header and .site-footer, so it will probably work if you're using the standard locations, but in my experience it's too broad: for example, it will hide the top bar inside your header element or the legal section at the bottom of footer element, even if you don't want that.

Workaround

The plugin prevent GeneratePress from using display:none to hide theme elements when they are disabled via the post metabox, leaving the PHP hook-based suppression active where available.

Design notes

Invariants, signal map, decisions, and terminology: see docs/ and CONTEXT.md.

Requirements

• GeneratePress Premium (hard — enforced via Requires Plugins header)
• GenerateBlocks Pro (soft — condition self-gates; display:none disabling + body classes run without it)
• WordPress 6.5+, PHP 7.4+

License

GPL-2.0-or-later

Detection reference

What each condition rule detects and its corresponding body class.

Theme Sidebar

Sidebar body classes are emitted by GeneratePress natively; this plugin adds none of its own. Sidebar rules are membership tests — "Left Sidebar Active" is true on a both-sidebars page too. To match the both-sidebars layout exactly, combine "Left Sidebar Active" and "Right Sidebar Active" with AND. Sidebar precedence is GeneratePress' own — Post Meta (the post's own Layout field) overrides Layout Element's sidebar setting, which overrides the Customizer default — not an OR across layers like the other conditions.

Theme Element Status

[^1]: Turning an element off globally in the Customizer is not detected. Setting Primary or Secondary Navigation to No Navigation, or featured images to off, removes the element from every page while the matching rule still reports it active — the per-page layers this plugin reads (Layout Elements, post settings) are unaffected. Featured Image Slot Active (theme) does see the image case, but only on sites running GP Premium's Blog module — see [^7]. There is no equivalent visibility for either nav rule.

[^2]: Means "you have not switched the image off for this post," never "GeneratePress is drawing an image here." Moving the image into a Content Template or Page Hero counts as moving it, not disabling it, so the condition stays true and blocks inside that template render — that's the point. It's also true on a post with no thumbnail at all, which is what makes a fallback image work. Ask the "is anything actually there" question with Featured Image Slot Active (theme) instead.

[^3]: Deliberately not read, not an omission. On real sites this setting is how you move the image — a Content Template or Page Hero draws it and GeneratePress' own copy has to be switched off to avoid a duplicate — so reading it here would hide the very blocks drawing the image. Use the per-post toggle to actually switch the image off; it now removes the image on both routes GeneratePress can render it through.

[^4]: The two Featured Image rows are coupled, not independent. Switching the image off with the per-post checkbox removes GeneratePress' own image callbacks, so the slot rule reads false too — "post setting off, slot active" cannot happen. Read the slot rule as answering "given you haven't switched it off yourself, is GeneratePress drawing one?"

[^5]: Says nothing about pixels either. It reports that GeneratePress has its own image callbacks wired up for this page, not that an image appears — on a post with no thumbnail it's still true. Use it with is_not to keep a block from duplicating GeneratePress' image, or to draw a fallback banner where a Layout Element has genuinely switched the image off and nothing has put one back. It gets no body class; the class surface stays where it is.

[^6]: A Content Template on its own does not make this false — and can make it wrong. It replaces the part of the page GeneratePress would have drawn the image into, but has no Disable featured image setting of its own (only a Page Hero does), so GeneratePress' image stays wired up and the rule still reports the slot active. With the image position set to Below title or Inside content — the two positions whose output lives in the part being replaced — nothing is actually drawn, so the rule says yes where you see nothing. Above content is unaffected: it renders outside the template, alongside whatever the template draws. This is the one place the rule can hide a block you wanted: use it with is_not for a fallback banner, and the banner won't appear. Two ways round it, both one setting: switch the featured image off in a Layout Element covering those pages, or move the image position to Above content.

[^7]: GeneratePress has two ways of drawing the featured image and only one is live per site. With GP Premium's Blog module active, this cell is exact: the module only wires its image up when the Customizer toggle is on, and stands down for a Page Header with its own content. Without the module, GeneratePress' own image callbacks are always registered, so this rule reports the slot active on any singular page unless an element has explicitly switched it off — including where a Page Header is drawing the image instead. The failure direction is the visible one: a duplicate image, rather than a block silently not rendering.

[^8]: On archives, this rule describes the heading at the top of the page, which no GeneratePress setting can disable, so it's always true there. A Layout Element's content-title setting does hide the titles on loop cards, but those are a different element this rule does not report on. Don't use this rule to gate anything per-card.

[^9]: Moving the title into a Page Hero counts as moving it, not disabling it, so the condition stays true and blocks inside the hero render — that's the point. Only the per-post Disable Elements metabox and a Layout Element's content-title setting turn it off. The trade: a block outside the hero wanting to hide itself to avoid a duplicate title has no rule to key on — put it inside the hero, or gate it with the element's own display conditions.

[^10]: A Page Hero that disables the title and then doesn't render one still reports this as true. The setting says the title moved; nothing can tell it moved somewhere you left it out.