How rules are enforced
Knowing where each rule runs helps you choose the right one and avoid caching surprises.
Server-side rules: login state, roles and dates#
When WordPress renders a page, Pro looks at every Section Blocks block as it is rendered. If the block carries a visibility, role or date condition that fails for the current request, Pro returns an empty string for that block. The block’s HTML, CSS classes and content are not in the page at all, so a visitor cannot reveal it with browser tools. This is what makes “Logged-in users” and role rules safe for member content.
Dates are evaluated with the site’s current time (current_datetime()) in the site’s time zone (wp_timezone()), so they follow Settings → General → Timezone and daylight-saving changes.
The device rule: CSS#
The device rule does not remove anything. Pro adds a class to the block’s outer element, sbp-only-mobile or sbp-only-desktop, and loads this CSS on the public site:
@media (min-width: 768px) { .sbp-only-mobile { display: none !important; } }
@media (max-width: 767px) { .sbp-only-desktop { display: none !important; } }The HTML is delivered to every visitor and the browser decides what to display. Use the device rule for layout, never for hiding private information.
Caching#
Full-page caches store rendered HTML and serve it to later visitors without running WordPress. That interacts with the server-side rules:
| Cache behaviour | Effect on Pro | What to do |
|---|---|---|
| Serves cached pages to logged-out visitors only, bypasses the cache for logged-in users (the default in most caching plugins) | Correct. Guests get the logged-out version; members get a fresh render with their roles. | Nothing. |
| Serves the same cached page to everyone, including logged-in users | Wrong. Whoever triggered the cache decides what everyone sees. | Enable “do not cache for logged-in users” in your caching plugin. |
| Caches per role or per user | Correct, but more cache entries. | Fine for small sites. |
| Scheduled block (“Show from” / “Show until”) | A cached page keeps its old state until it is regenerated. The block may appear late or linger. | Clear the cache at the start and end times, or set a short cache lifetime on pages with scheduled blocks. |
| Device rule | Unaffected: one HTML works for all screens. | Nothing. |
Object caches (Redis, Memcached) are not affected; conditions are evaluated on each render.
Some CDNs and hosts cache HTML at the edge for all visitors regardless of cookies. Check with your host that logged-in requests bypass the edge cache before relying on login or role rules for sensitive content.
Where conditions are stored#
Conditions are block attributes saved in the post content with the block (sbpVisibility, sbpRoles, sbpDevice, sbpDateStart, sbpDateEnd). There are no extra database tables or options for conditions. Deactivating Pro leaves them in place; the free plugin ignores unknown attributes and shows the block to everyone.