Personalizing a WordPress site usually means extra plugins, custom templates, or a lot of manual work. Conditional Blocks takes a different route. It lets us show or hide personalized content inside the WordPress block editor, based on conditions we choose. That can be as simple as “Is the user logged in?” or as detailed as location, device, memberships, and eCommerce behavior.
Key Takeaways
- Conditional Blocks lets us show or hide individual WordPress blocks based on clear rules (for example, logged-in status, user role, date and time, device, referrer, query string, or cookies).
- The plugin adds visibility controls inside the block editor sidebar (and optionally the toolbar), so we set rules per block without a separate dashboard settings flow.
- Presets let us save and reuse condition sets across blocks, with AND OR logic, so rules stay consistent across pages.
- Geolocation conditions use IPinfo and require an API key, IPinfo offers a free tier with 50,000 lookups per month.
- Conditional Blocks supports common plugin stacks through integrations like WooCommerce, ACF, EDD, Paid Memberships Pro, FluentCRM, WP Fusion, GTranslate, Meta Box, and ProfilePress.
How to Get the Best Deal on Conditional Blocks
InfluenceWP has an exclusive Conditional Blocks deal.
Top 10 Pro—First Look Video
What We See on the Conditional Blocks Website Before Installing Anything
Before touching WordPress, we like to scan a product’s site the same way an agency or DIY site owner would. We look for the pages that answer basic trust questions quickly: What does it do, how do we set it up, and is it actively maintained?
The Conditional Blocks site makes a strong first impression with a short path to the pages we care about. The main navigation points us to features and documentation right away, which speeds up evaluation.
A Large Feature List That’s Easy to Sanity Check
The “All Features” area does a good job of listing what we can condition against, and it groups items in a way that matches how we think about real builds. Here’s what stood out, organized the same way we’d evaluate it for client work.
- General capabilities include a custom conditions API (useful for developers), presets (for reuse), responsive controls tied to breakpoints, and “lockdown actions.”
- User-based conditions cover logged-in users, logged-out users, user roles, and user meta fields.
- Date and time conditions include schedule ranges and recurring schedules, which matter for promotions or seasonal pages.
- Post and custom post type conditions include post type, post meta and custom fields, taxonomy terms, and post archive handling. That’s the core of most content sites, especially when custom post types drive templates.
- Server and request conditions include query strings, URL variables, HTTP cookies, user agents, devices, browsers, URL paths, and domain referrers. Those options open the door to campaign-specific landing experiences without duplicating pages.
- Advanced conditions include PHP logic and post IDs.
- Geolocation supports IP visitor location based on country and continent.
Then there’s a long list of integrations for Conditional Blocks:
- WooCommerce: Cart contents, cart total value, WooCommerce geolocation, recent orders, customer spend
- Advanced Custom Fields (ACF): Field value conditions
- Meta Box: Metabox field value conditions
- Easy Digital Downloads (EDD): Products in cart, products purchased, product categories in cart, cart value
- Paid Memberships Pro: Membership level and user fields
- FluentCRM: Contact tags and lists
- WP Fusion: CRM tags
- GTranslate (Google Translate): Detected language
- ProfilePress: Active membership plan
That’s a lot of surface area, and it matches how many WordPress sites are actually built today: blocks for layout, plus a few major plugins for commerce, CRM, translation, and memberships. If we can control visibility at the block level, we can keep a single-page layout and still tailor what different visitors see.
Documentation That Includes Video, Search, and Integration Guides
The documentation section includes guides for core features and separate areas for integrations. We also see video embedded in the docs, which helps when a feature is easier to understand by watching the UI.
Search is available and works. For example, searching for “ACF” returns relevant documentation, which matters because integrations are only useful if setup steps are easy to find later when we’re mid-build.
One small behavior we notice is that the search box appears after opening a guide, rather than being visible immediately from the documentation landing page. Still, the important part is that the search exists and returns the right pages.
About Page and Changelog Signals We Look For
In the footer, we find an About page that includes the founder’s name and face. Morgan Hvidt (X) is listed as the founder, and the page gives a short background plus context on Conditional Blocks itself. That simple touch helps trust because we know who’s behind the product.
We also find an active changelog with dates and version numbers. For WordPress professionals, that’s one of the quickest ways to confirm ongoing maintenance without guessing.
How Conditional Blocks Works Inside the WordPress Block Editor
For the hands-on test, we run Conditional Blocks Pro with the default Twenty Twenty-Five theme. Because the plugin works with the block editor, any block theme should be a fit.
One thing we notice right away is what we do not see: there’s no separate settings menu in the WordPress dashboard. Instead, Conditional Blocks shows up where it matters, on a per-block basis, inside the editor sidebar.
That design choice keeps the workflow focused. We don’t have to leave the page we’re building just to control what appears on the front end.
Adding a Block and Finding Visibility Controls
We start by editing a page in the block editor. To add a block, we can either:
- Type the slash command (for example,
/button) - Use the plus icon in the top-left and pick a block from the inserter
After adding a Button block and selecting it, a new panel appears in the right sidebar labeled Conditional Blocks. Expanding it shows the core promise in plain terms: configure visibility conditions to control when the block appears on the site.
From there, we choose “Edit Visibility,” and the conditions builder opens.
Setting a Simple Condition With Logged-In Users
For the first test, we choose a simple condition: User Logged In.
There’s no obvious “Save” button inside the builder. Instead, closing the builder applies the condition to the block. After saving the page, we view it on the front end.
- When we view the page while logged in, the button appears.
- When we view the page in a separate browser where we are logged out, the button disappears.
That’s the basic workflow, and it works as expected.
A nice touch shows up back in the editor. The sidebar gives a quick summary of the visibility rule we set. That means we can confirm what’s active without reopening the builder every time. It feels like a small thing, yet it speeds up real production work where pages may have many conditional blocks.
The builder also supports AND/OR logic, so we can create more complex rules as needed.
Reusing Rules With Presets Instead of Rebuilding Conditions
Next, we move to the Preset Manager tab. Presets matter because most of us repeat the same visibility logic across many pages and patterns. Rebuilding conditions block-by-block gets old fast.
We create a preset named “My Preset” and add the same rule as before: user must be logged in. Back on the Current Block tab, we apply presets to the selected block. The UI also explains the logic options:
- All presets must be successful (AND logic)
- At least one preset must be successful (OR logic)
We apply “My Preset” and test again on the front end. The behavior matches the manual condition setup, which is what we want. In other words, presets are not a second-class feature. They produce the same result, with less repetition.
To push the test further, we create a second preset, “My Preset 2,” with a user role requirement. First, we set it to “Author,” and we apply both presets to the same block.
Because the role requirement is now part of the rules, the button disappears even while we’re logged in as an admin. “Admin” is a different role than “Author,” so the preset correctly hides the block.
Then we edit the preset and switch the role requirement to “Admin.” After refreshing the front end, the block behavior updates as expected.
Another small but meaningful detail shows up here: changing preset conditions doesn’t require saving the page again to see the new behavior. That makes presets feel like a true rule system, not just a copied snippet.
For quick reference, this is the basic preset workflow we follow:
- Create a preset in Preset Manager and define conditions.
- Apply the preset to a block from the Current Block tab.
- Test the page logged in and logged out (and with different roles when needed).
Responsive Visibility, Geolocation Setup, and Extra Editor Settings
Conditional Blocks also includes a Visibility Settings tab with a few items that matter most once we go beyond simple user rules.
Responsive Blocks and Theme Breakpoints
The settings mention responsive blocks and breakpoints. The idea is simple: if we use responsive screen size conditions, we may want those breakpoints to match our theme’s breakpoints.
To visualize this, we add an Image block (the demo uses a beach photo) and then look at how breakpoints could matter for different screen sizes. While the demo doesn’t build a full responsive rule set end-to-end, the presence of breakpoint controls signals that responsive visibility is meant to align with the theme, not fight it.
Geolocation Uses IPinfo and Requires an API Key
For location-based visibility (country or continent), we need an API key. The documentation confirms the service: IPinfo.
IPinfo includes a free tier with 50,000 lookups per month, which will cover many small to mid-sized sites. Setup follows a straightforward pattern: sign up at IPinfo, get an API key, add it in the plugin’s settings area, then verify the connection before building geolocation conditions.
A Few Helpful Quality-of-Life Toggles
At the bottom of the visibility settings area, we see a few options that help day-to-day building:
- Open conditions builder from the toolbar: adds a button in the block toolbar, not just the sidebar.
- Only show installed integration conditions: hides integration-specific conditions if the related plugin is not installed (for example, WooCommerce).
- Developer mode: shows extra info for development and debugging.
Each of these reduces clutter or saves clicks, especially on larger builds where editors work fast and pages can contain many blocks.
Why Conditional Blocks Fits Real Client Sites
Conditional Blocks stands out because it treats the block editor as the center of the site experience. Instead of sending us into templates, shortcodes, or custom logic scattered across plugins, it puts visibility rules right where we build content.
We also like the range of conditions. Basic user logic is covered, yet the plugin doesn’t stop there. Date scheduling, request-based rules (query strings, cookies, and referrers), and PHP logic help with advanced cases. At the same time, the integration list reads like a map of common WordPress stacks: WooCommerce, ACF, memberships, CRMs, translations, and digital downloads.
Presets are the feature that makes it feel scalable. Once we can name rule sets and reuse them, we reduce both build time and mistakes. That matters for agencies shipping multiple sites, and it also helps DIY users keep logic consistent across a growing site.
Documentation helps close the loop. We see video-based guides, integration topics, and search that returns relevant results (like ACF). When a plugin includes many condition types, docs stop being optional. Here, the docs look like a real part of the product.
Final Thoughts About Conditional Blocks
Conditional Blocks gives us a practical way to control block visibility using rules that match how WordPress sites are built today. We can start simple with logged-in checks, then scale into presets, responsive logic, geolocation via IPinfo, and deep integrations like WooCommerce, ACF, and memberships.
If personalized block content is part of our roadmap, this plugin is worth a serious look.
Frequently Asked Questions About Conditional Blocks for WordPress
What Does Conditional Blocks Do in WordPress?
Conditional Blocks lets us control block visibility inside the WordPress block editor. We can show or hide a block based on rules like logged-in status, roles, date and time schedules, device and browser signals, query strings, cookies, referrers, and more.
Where Do We Configure Conditional Blocks Visibility Rules?
We configure rules per block in the editor sidebar. After selecting a block, we open the Conditional Blocks panel, choose Edit Visibility, and then build the condition. The rule applies when we close the builder, and then we save the page.
How Do Presets Work in Conditional Blocks?
Presets let us save a set of conditions once, then apply it to any block. We create a preset in the Preset Manager, then apply it from the Current Block tab. Presets support AND logic (all presets must pass) and OR logic (at least one preset must pass).
Does Conditional Blocks Support WooCommerce, ACF, and Membership Plugins?
Yes. The plugin lists integrations such as WooCommerce, Advanced Custom Fields (ACF), Meta Box, Easy Digital Downloads (EDD), Paid Memberships Pro, FluentCRM, WP Fusion, GTranslate, and ProfilePress. These integrations add extra condition types tied to each plugin.
How Does Geolocation Targeting Work in Conditional Blocks?
Geolocation targeting uses IPinfo and requires an API key. Setup follows a simple flow: create an IPinfo account, get the key, add it in the plugin settings, then verify the connection before using country or continent-based conditions.