Meta Box Show Hide - WordPress Plugin

A Guide to Configuring Meta Box Show Hide for Conditional Meta Boxes in WordPress

Meta Box Show Hide is useful when extra field groups only get in a WordPress editor's way. This guide is not a generic product pitch. Instead, it walks through a practical setup: what to check before installation, how to wire up show and hide conditions, how to choose between page template, post format, category, taxonomy, parent page, and field value, and then how to confirm that a meta box appears only in the right context.

The extension is especially useful for developers who already use Meta Box for custom fields and want to keep the edit screen cleaner. If a post has dozens of settings, but some of them only apply to a page template, category, post format, or selected toggle, hiding unnecessary blocks reduces editor mistakes and removes interface noise.

One important boundary to keep in mind: Meta Box Show Hide controls the visibility of entire meta boxes. If you need conditions at the level of individual fields, tabs, external elements, or more advanced operators, MB Conditional Logic is usually the better fit. If a block should not be rendered into the editor HTML at all, MB Include Exclude or the rwmb_show filter makes more sense. Those differences matter because this is exactly where wrong expectations tend to show up.

Where the Extension Fits into a Meta Box Workflow

Meta Box, as the core plugin, gives developers a framework for custom fields, custom meta boxes, and dynamic data in WordPress. Meta Box Show Hide adds a conditional visibility layer on top of that framework: when registering a meta box, the developer adds a show or hide array, and the extension watches the selected context in the editor to show or hide the entire block.

According to the official documentation, conditions can be based on page template, post format, categories, hierarchical custom taxonomies, whether a parent page exists, and values of individual interface elements through CSS selectors. In practice, that covers a common use case: keeping the editor from being overloaded with settings that only matter in a narrow scenario.

Imagine a site with several page types. A standard page only needs SEO fields and a few short internal notes. A page using the "Landing" template should expose settings for the hero section, buttons, benefits block, and form. A post with the "Gallery" format needs gallery fields, while those same fields would only confuse an editor on a regular post. Meta Box Show Hide lets you tie those blocks to context without writing separate display logic for every screen.

The key practical takeaway: this extension does not create fields or render them on the front end. It helps control which field groups an editor sees in the WordPress admin when editing a specific piece of content.

Because it uses a JavaScript-based approach, a block can appear without reloading the page after a condition changes, such as when a category or controlling field value is selected. But that comes with an important consequence: hidden fields still exist in the editor markup, and their values may still be submitted when the post is saved. That means Meta Box Show Hide should not be used as a security mechanism, an access-control layer, or a way to remove data from the form.

Who Meta Box Show Hide Is For, and When Another Approach Is Better

This extension is aimed primarily at developers, webmasters, and agencies building sites with Meta Box and controlling field structure through code or through the Meta Box extension stack. It works well when you want to keep a single data model but make the edit screen more context-aware.

When It Is a Good Fit

Meta Box Show Hide works especially well on projects where different content types share some fields, but not every field should be visible all the time. That can include magazine-style sites, catalogs, landing pages inside a corporate site, event databases, educational content, or any project with multiple editorial workflows.

• You need to show a settings block only for a specific page template.
• You need to hide a meta box for specific categories or custom taxonomies.
• You need to change which blocks are visible based on the selected post format.
• You need to show an additional block when the editor picks a value in a controlling field.
• You need it to work in both the Classic Editor and the block editor, assuming your installed extension version supports both.

When Show Hide Should Not Be Your Starting Point

If the requirement sounds like "show one field when another field equals X," Show Hide may be too coarse a tool. It works at the group level, not at the level of each individual form row. For targeted dependencies, advanced operators, tabs, and external HTML elements, MB Conditional Logic is usually a better match.

If the task involves user permissions, security, removing unnecessary fields from the form, or preventing values from being saved, JavaScript-based hiding does not fully solve it. In that case, look at server-side checks, WordPress roles, separate meta boxes, MB Include Exclude, or a custom filter that decides whether a group should be shown before the HTML is rendered. That is server-side logic, not just editor convenience.

This extension is also not always the easiest starting point for a no-code visual workflow. If the team wants to manage everything strictly through the interface, check in advance which parts of the Meta Box stack are available through UI tools in your installed setup. Core Meta Box is often used as a developer library, while extensions like MB Builder add a visual layer.

What to Check Before Installation and Activation

Before installation, it is important to understand not just whether WordPress is present, but how the edit screen itself is assembled. Meta Box Show Hide depends on meta boxes already being registered through Meta Box and on the selected conditions actually existing in the editing interface.

Dependencies and Where the Code Lives

The core Meta Box plugin is required. If your fields are created through code, check where the rwmb_meta_boxes filter is attached: in a child theme, a custom mini-plugin, or an mu-plugin. For client projects, it is usually safer to keep that configuration in a separate plugin so a theme switch does not disable the site's data structure.

If you use Meta Box AIO or a premium extension bundle, make sure the required module is enabled. On sites with multiple environments, compare staging and production carefully. Sometimes the extension is active on the test site but missing on the live one, and a show rule in code does not produce the expected behavior.

The Context Your Condition Will Depend On

Before writing code, put together a short condition table. This saves time during troubleshooting because Show Hide is sensitive to exactly how the context is checked: ID, name, slug, CSS selector, or the post_type:template-file.php format for post type templates.

If the rule depends on a custom taxonomy, make sure that taxonomy is actually available on the edit screen for the relevant post type. If the editor cannot see that block, or if it has been replaced by a custom interface, the condition may not behave the way you expect.

Rollback Plan

Before enabling rules on a live site, prepare a simple rollback path: temporarily comment out the show or hide array, disable the extension on staging, or restore the previous mini-plugin file from version control. Do not start configuring this on the only live copy of the site without a fallback plan, especially if editors rely on those fields every day.

Installation and Initial Validation in the Admin Area

Installation usually means adding the extension to an already working Meta Box setup. You do not need to build authentication into the project or enter any secrets into the code examples. For this article, the general sequence is enough: install the core Meta Box plugin, add the extension, activate it in WordPress, and verify that existing meta box registration still works.

Basic Sequence

1. Confirm that the core Meta Box plugin is active and existing fields are visible in the editor.
2. Install the Meta Box Show Hide extension using the method that matches your setup: a separate ZIP, Meta Box AIO, or another official package.
3. Activate the extension through Plugins or through the extension management panel if you use Meta Box AIO.
4. Open a post or page that already has a meta box registered through Meta Box.
5. Do not add complex rules yet. First, confirm that the existing meta box configuration still behaves normally.

After installation, do not expect a brand-new magic screen with a single "configure everything" button. Most of the work still happens in the meta box configuration itself. That is normal for the Meta Box ecosystem: the product is designed around developers and data structures, not only around visual toggles.

Minimal Post-Activation Check

Open an edit screen with an existing meta box and save a test post without making changes. If you see JavaScript errors at this stage, if all blocks disappear, or if the editor starts behaving unpredictably, first disable third-party plugins on a test copy and switch to a default theme. That matches the standard Meta Box support approach: isolate Meta Box, Meta Box AIO, and a default theme to determine whether the conditional logic is conflicting with the environment.

Quick summary: the first check is not about conditions. It is about stability. If the core Meta Box fields work the same way before and after activating the extension, you can move on to visibility rules.

How show and hide Rules Work

In Meta Box Show Hide, a rule is added directly to the meta box configuration array. You use either the show key or the hide key. Both accept a set of conditions and an optional relation parameter that combines those conditions as AND or OR. By default, the logic is OR.

The difference between show and hide is simple, but worth making explicit. show means "display the block when the conditions match." hide means "hide the block when the conditions match." In a single project, it is better to agree on one style: either most rules are written as inclusive rules or most are written as exclusion rules. Mixing both approaches without a reason makes maintenance harder.

OR and AND Logic

If you have multiple conditions and use OR, matching any one of them is enough. For example, a meta box might appear for a page with a specific template or for a post in a certain category. If you use AND, all conditions must match at the same time: the correct template is selected, the post belongs to the correct category, and the controlling checkbox is checked.

For editorial workflows, it is usually safer to start with narrower logic. If a meta box appears too often, editors see extra fields and may fill out the wrong block. If a rule is too narrow, the block will not appear, but that is easier to catch when testing against a predefined checklist of conditions.

Conditions by Page Template and Post Type Template

Page template is one of the clearest use cases. If settings are only needed for a landing page, specify the template file in template. For WordPress post type templates, the expected format is post_type:template-file.php. If the post_type: part is omitted, the extension treats the template as a regular page template.

That detail matters on sites where templates exist not only for pages but also for custom post types. If the event post type has a single-event.php template, the rule needs to reflect the post type explicitly. Otherwise, a developer may spend a long time chasing a JavaScript issue when the real problem is simply the value format.

Conditions by Category and Custom Taxonomy

Categories use the category key. The documentation makes it clear that categories expect IDs or names, not slugs. For a custom taxonomy, the key becomes the taxonomy slug, such as location, and the values are term IDs or names. This is exactly where it is important not to mix up the human-readable name, slug, and ID.

If the project is multilingual or editors sometimes rename categories, IDs are usually more stable than names. But IDs are less readable in code, so a short comment can be useful. That comment should not explain the obvious, but it can preserve the context of which term the number refers to and why it controls the block.

The input_value Condition

input_value lets you react to the value of a specific interface element. It is powerful, but also more fragile, because it depends on a CSS selector and on the editor's actual markup. It works well for a custom controlling field. For example, a checkbox labeled "Use advanced layout" can reveal a meta box with additional settings.

Before using input_value, inspect the selector in the browser and confirm that it exists on the edit screen in the mode you care about. If the same site uses both the Classic Editor and the block editor, test both. For checkboxes, the documentation shows an approach where the value true corresponds to the checked state.

Detailed Configuration: From a Simple Rule to a Maintainable Setup

The most valuable Meta Box Show Hide configuration is not the one that merely works today, but the one that still makes sense a month later. Conditional visibility usually breaks down not because the code is too complex, but because the logic is unclear: nobody knows why the block is hidden, which condition matters most, which terms are being checked, or what should happen after the editor makes a selection.

Basic Example for a Template-Based Page

The example below shows a meta box only for pages using the specified templates. This code is best kept in the project's mini-plugin or in the same file where the Meta Box fields are already registered. The example does not change WordPress core and does not require editing the extension files.

add_filter( 'rwmb_meta_boxes', 'project_register_landing_meta_boxes' );

function project_register_landing_meta_boxes( $meta_boxes ) {
    $meta_boxes[] = array(
        'id'         => 'landing_controls',
        'title'      => 'Landing controls',
        'post_types' => array( 'page' ),
        'show'       => array(
            'relation' => 'OR',
            'template' => array( 'templates/landing.php', 'templates/campaign.php' ),
        ),
        'fields'     => array(
            array(
                'name' => 'Hero button label',
                'id'   => 'hero_button_label',
                'type' => 'text',
            ),
        ),
    );

    return $meta_boxes;
}

After saving, open a page with a standard template and a page with one of the specified templates. In the first case, the meta box should stay out of the editor's way. In the second, it should appear. If the block does not change state, check the exact template file name, the path relative to the theme, and whether the template selector is visible in the current editor.

Example Using a Category and a Custom Taxonomy

When a block is needed for a specific type of editorial content, taxonomies are often the cleanest option. For example, settings for a sponsored-content block may need to appear only for posts in the "Partner" category or for events in the "USA" region. For rules like these, do not rely on a single visual test. Check a post with no term, with one term, with multiple terms, and after removing the term again.

'show' => array(
    'relation' => 'OR',
    'category' => array( 12, 'Partner' ),
    'region'   => array( 'USA' ),
),

If a term gets renamed, a name-based rule may stop matching. That is why long-lived projects often use term IDs and keep lightweight documentation nearby. This is not mandatory, but for a client site that will be maintained over time, IDs are usually safer than names.

When to Use hide Instead of show

hide is convenient when a meta box should be visible almost all the time except for a few exclusions. For example, an editor notes box may be needed on most pages but not on system templates where content is assembled automatically. In that case, an exclusion rule reads more clearly than a long list of allowed conditions.

But do not turn hide into a way to cover up structural problems. If a block only belongs to one type of content, it is usually better to show it explicitly with show. The less hidden logic you have, the easier it is to explain to editors why they do or do not see a specific block.

Safe Rollback for a Questionable Rule

If editors complain after a rule goes live because a block disappears, do not change multiple conditions at once. Disable just one layer first. For example, temporarily remove input_value and keep template. Then test again. This kind of step-by-step rollback makes it much easier to identify what actually broke: a bad selector, the wrong term, editor incompatibility, or a JavaScript conflict.

Validation after every change: open a new post, open an existing post, change the condition, save, reload the screen, and confirm that the meta box stays in the expected state.

Practical Example: Event Settings Only for the Right Template and Content Type

Now let us look at a concrete scenario. The site has a custom post type called event. For a standard event, the editor fills in the date, venue, and short description. For an event with an expanded landing-style page, an additional meta box is needed: hero background, button text, partner block, and a "Show map" toggle. That block should appear only for events using the event:templates/event-landing.php template and the event_type taxonomy term "Conference".

Goal

The goal is for editors to see advanced settings only where they actually affect the event page. For standard events, those fields should not take up space or encourage editors to fill in data that will never be displayed.

Preparation

Before writing code, verify four things: the event post type is registered, the template is available for that post type, the event_type taxonomy is displayed in the editor, and the advanced-settings meta box is already defined through Meta Box. If even one of those pieces is missing, the visibility rule will not be able to evaluate the context correctly.

Setup Steps

1. Create or open the meta box for the advanced event settings.
2. Add the show key to the configuration.
3. Set relation to AND because both conditions must match.
4. Specify the template in the format event:templates/event-landing.php.
5. Specify the event_type taxonomy and a stable term value.
6. Test a new event, an existing event, and an event with a different type selected.

'show' => array(
    'relation' => 'AND',
    'template' => array( 'event:templates/event-landing.php' ),
    'event_type' => array( 'Conference' ),
),

Expected Result

When the editor selects both the correct template and the correct event term, the meta box with advanced settings appears in the editor. If a different template or a different term is selected, the block stays hidden. When those conditions are toggled, the block should react without a manual reload anywhere WordPress and the surrounding environment correctly pass those changes into the interface.

A Note About Previously Saved Values

If the fields were filled in earlier, hiding the block does not automatically remove those values. That is an important property of JavaScript-based visibility. If the site should not output old values, apply the same condition in the front-end template as well. Meta Box Show Hide improves the admin experience, but it does not replace server-side rendering logic on the public site.

Editor Validation

Ask an editor to walk through the same scenario without prompts: create an event, choose the type, choose the template, see the correct block, fill in one field, save, and open the entry again. If the editor understands why the block appeared, the setup is not only technically correct but also ergonomically sound.

How to Validate the Result After Configuration

Result validation needs to go beyond "I saw the block once." Conditional visibility depends on editor state, saved values, script load order, and sometimes on other plugins. A good test should therefore cover multiple contexts.

Checklist for the Block Editor

• Create a new post or page in the relevant content type.
• Check the state of the meta box before selecting the condition.
• Select the template, category, format, or field value that should reveal the block.
• Save the post and reload the edit screen.
• Remove the condition and confirm that the block hides again.
• Check the browser console for JavaScript errors if the block does not change state.

Checklist for the Classic Editor

The Classic Editor still appears on older or specialized projects. The official extension page states support for both the Classic Editor and Gutenberg, but a real site may add its own scripts, meta blocks, and plugins. That is why this mode should be tested separately.

• Make sure the necessary blocks are not disabled in Screen Options.
• Verify that categories, taxonomies, and post format are available on the screen.
• Save the post after changing the condition and open it again.
• If the block behaves inconsistently, temporarily disable plugins that modify the edit screen.

The Public-Facing Site

Meta Box Show Hide does not output data on the site, but after configuration it is still worth checking the front end. If a field is hidden in the admin area, the site template may still read an old value. For that reason, the output template should reflect the same business rule: if an event is not using the advanced template, it should not show the partners block simply because the data was saved at some point in the past.

This separation keeps the responsibilities clear: the extension handles editor convenience, while the theme or custom code decides what the visitor actually sees. That reduces the risk of a hidden field continuing to affect the public page by accident.

Practical Usage Ideas for Real Sites

Meta Box Show Hide shows its real value not in a demo snippet, but in day-to-day editorial work. Below are a few scenarios where conditional visibility for an entire block genuinely reduces noise and helps editors avoid mistakes.

Landing Pages Inside a Regular Site

For pages that use a landing-page template, you can show blocks such as "Hero," "CTA," "Tracking note," and "Campaign settings," while hiding them on regular pages. Editors no longer have to wonder why a button field does nothing on a standard page. The test is simple: switch the page template and confirm that the set of meta boxes changes.

Editorial Post Formats

For posts with the "Gallery" format, you can show a gallery settings meta box. For the "Video" format, you can show a block with a URL and poster image. For a standard post, only the usual fields remain visible. This is especially useful when the theme renders content differently in archives and on single-post pages.

A Catalog with Custom Taxonomies

In a property or item catalog, different taxonomies may require different data blocks. For example, listings of type "Apartment" may need square footage and floor fields, while "Land" may require parcel details and zoning restrictions. Show Hide helps preserve a single editing interface while showing editors only the context-specific groups they actually need.

Internal Workflow Blocks

Sometimes a meta box is not meant for front-end output at all, but for process-related data: an editorial flag, a review status, or an internal comment. If that block is only needed for child pages or for items in a certain category, is_child and taxonomy-based conditions can keep it from appearing everywhere.

Across all of these scenarios, the rule is the same: define the editorial purpose of the block first, then choose the technical condition. If you start from the code, it is easy to end up with a beautiful condition array that nobody on the team can explain.

Limitations and How to Choose Between Show Hide, Conditional Logic, and Include Exclude

The official Meta Box documentation directly compares three approaches: MB Include Exclude, MB Show Hide, and MB Conditional Logic. That comparison is critical if you want to choose the right tool. They sound similar because of the words "show" and "hide," but they operate at different levels.

The most common misconception is to treat JavaScript-based hiding as equivalent to removing a field from the form. It is not. The documentation makes it clear that with Show Hide and Conditional Logic, the HTML has already been rendered and the inputs are only hidden. Their values may still be saved to the database when the post is saved. If that is undesirable, the check needs to happen in output logic, save logic, or some other server-side layer.

The second misconception is trying to solve every problem with a single extension. If you only need a "Video URL" field when the "Video" radio option is selected, Conditional Logic is usually the better choice. If you need a "Landing settings" block only on a landing template, Show Hide is simpler. If a non-admin user should not be able to access a block at all, Show Hide is not an access-control solution.

The third misconception is about performance. Hiding unnecessary blocks improves the editor experience, but it does not automatically turn a heavy edit screen into a lightweight one. If a meta box contains expensive fields, slow queries, or third-party scripts, JavaScript-based hiding does not always remove the cost of preparing those elements. For truly heavy blocks, server-side exclusion or a structural redesign is often the better option.

Why a Meta Box Does Not Appear or Hides Incorrectly

Troubleshooting should move from simple to complex: first check the condition and the editor screen, then the environment, then JavaScript conflicts. Below are the symptoms that commonly show up with conditional visibility in Meta Box and in the WordPress editor more broadly.

The Block Does Not Appear When a Category Is Selected

Symptom: the editor selects the correct category, but the meta box remains hidden. One possible cause is that the rule was given a slug, while the documentation for category expects an ID or a name. Also check the exact capitalization of the category name, because category matching is case-sensitive.

What to verify: the category ID, the exact name, whether that category is available on the current post type, and whether the behavior is the same on a new post and an already saved post. In most cases, the fix is to switch to an ID or use the correct name. If the rule becomes clearer with an ID, add a short code comment nearby.

A Template-Based Condition Does Not Work for a Custom Post Type

Symptom: the meta box should appear for a post type template, but it does not. A likely cause is that the template is being referenced like a normal page template file, without the post type prefix. For post type templates, use the format post_type:template-file.php.

What to verify: whether the post type supports templates, the exact file name, the path WordPress expects, and whether the path differs in a child theme. If the template only exists in the theme, check whether the structure changed after a theme update or theme switch.

A Hidden Block Still Saves Old Values

Symptom: the editor no longer sees the meta box, but old data still appears on the public page. That is not necessarily a bug in the extension. Show Hide hides the block in the interface, but it does not clear the database and it does not override template output.

The fix depends on the goal. If old values should not be displayed, add the same business-condition check to the front-end template. If the values need to be removed, do that through a separate migration or a careful admin-side cleanup procedure, not by hiding the field.

A Rule with input_value Behaves Inconsistently

Symptom: the block appears after one toggle, but not another, or stops working after the interface changes. A likely cause is that the CSS selector is too fragile, the element appears later than expected, or another script changes the state without triggering the event the conditional logic expects.

What to verify: whether the element exists in the markup, the exact value, the checkbox state, and whether there are errors in the browser console. If the value changes programmatically, MB Conditional Logic with manual JavaScript condition triggering may be a better fit for more advanced setups, but with Show Hide it is best not to complicate things unless there is a clear need.

The Behavior Differs Between the Classic Editor and the Block Editor

Symptom: the block works in one editor but not the other. First, check the extension version and changelog, because Gutenberg support was expanded over the product's history. Then verify that the block is not hidden in Screen Options and that no plugins are rebuilding the edit screen.

If the issue cannot be reproduced on a default theme with a minimal plugin stack, the cause is probably environmental. In that case, build a minimal meta box example and re-enable plugins one by one. That is faster than arguing with a large production edit screen where ten scripts are all active at once.

You Need to Hide by User Role

Symptom: the team is trying to use Show Hide as an "admins can see it, editors cannot" mechanism. For that requirement, do not rely on visual hiding. On the Meta Box forum, similar questions are typically redirected toward Include Exclude, separate meta boxes, or other permission-aware, server-side solutions.

If the issue is security or data access, use WordPress roles, capability checks, server-side filters, and dedicated save restrictions. Show Hide can improve the interface, but it should not be the only layer of protection.

Video on Meta Box Show Hide

The official product page includes a relevant video called Meta Box Show Hide Overview. It is useful as a quick visual confirmation that the extension works specifically with meta boxes and conditions based on template, post format, or category. Use it as a supplement to this guide if you want to see the general principle in motion, not as a substitute for testing on your own site.

When Meta Box Show Hide Is Worth Using

Meta Box Show Hide is a strong choice if the site already uses Meta Box and the goal is to make the WordPress editor more context-aware by showing entire field groups only for the right templates, formats, categories, taxonomies, child pages, or controlling field values. In that scenario, the extension gives you a clear way to remove unnecessary blocks from the screen without forcing editors to constantly figure out which fields apply to the current piece of content.

Before rolling it out on a live site, verify the dependencies, the exact condition values, the behavior in the editor you use, save behavior after reload, and front-end output of old values. If you need logic at the individual field level, look toward MB Conditional Logic. If a block should not be rendered into HTML at all, or if the condition is tied to permissions, choose a server-side approach.

Once the test scenario is complete and you clearly understand which meta boxes should appear in each context, you can download the installation package and test the extension on a staging copy of the site. That sequence is safer than enabling conditional visibility immediately on a live editorial screen.