Content Visibility for Divi Builder

Yes! In Divi 4 and below: This plugin detects and modifies Modules and Sections by class inheritance. As long as Elegant Themes continues to have a single root class for everything, this plugin should detect all of them, including third party ones! In Divi 5: This plugin detects and modifies Modules and Sections by instrumenting all Gutenberg block render callbacks. As long as Elegant Themes continues to utilize Gutenberg blocks with render callbacks for everything, this plugin should detect all of them, including third party ones!

Yes. If you decide to deactivate or uninstall this plugin, the "Content Visibility" configuration option will disappear from the Divi Builder, and will not have any effect on the frontend output. Of course, the "Content Visibility" settings that were defined for a particular Section or Module will continue to persist in the database, until that post/page is updated. This can be a good thing, however, as you may want to reinstall/reactivate in the future and not have to re-enter all of your "Content Visibility" expressions!

Once the plugin is installed and activated, a "Content Visibility" option will appear in each Section or Module's settings on either the Advanced tab under Visibility (for Divi 4.x or higher) or the General Settings / Content tab (for Divi 3.x or lower.) You may enter any PHP boolean expression you would like, (e.g. is_user_logged_in()), and the Section or Module will only display if the expression evaluates to true. NOTE: Complex expressions are usually best entered as a custom function call defined in a child theme or plugin! So, for example, you could enter my_custom_function() in the Content Visibility option, and then define that function (returning true or false) in your child theme's functions.php. If there are several common boolean expressions you use, this also has the added benefit of allowing you to change the behavior of your content by simply modifying the function body once instead of re-entering Content Visibility options all over the place.

Starting in version 5.00, the plugin includes expression validation that checks visibility expressions before they are evaluated. This prevents potentially dangerous PHP code (such as system commands, file operations, or network calls) from being executed via visibility expressions. Expression validation works by: Tokenizing the expression using PHP's built-in tokenizer. Checking each token against allowlists of safe token types and operators (function calls, literals, comparison and logical operators, etc.). Checking each callable against a denylist of dangerous functions (e.g. exec, system, file_put_contents, eval, etc.) first, so an accidental allowlist entry never lets a destructive function through. Checking each callable (function or static-method name) against an allowlist of known-safe names. The default list ships WordPress conditional tags (is_user_logged_in, current_user_can, etc.); admins add custom helpers via the content_visibility_for_divi_builder_allowed_callables filter. Detecting attempts to use strings as callable functions (e.g. 'system'('ls')). New installs have validation enabled automatically. Existing installs upgrading to 5.00 will see a non-dismissible admin notice directing them to the Expression Validation tab under Tools > Content Visibility for Divi Builder API Reference. That tab provides a content scanner that checks all existing posts for expressions that would be blocked, plus a copy-paste filter snippet that pre-allowlists every custom callable found in current content. Paste the snippet into a site-specific plugin or your theme's functions.php, re-scan to verify zero remaining errors, then click "Enable Validation". Validation can be disabled later (a "Disable Validation" form appears once it is enabled, requiring you to type DISABLE to confirm). Use this if validation causes unexpected behavior on your site while you investigate. When validation is enabled and an expression is blocked, the content will be shown (not hidden) and an email notification is sent to the site admin with details about the blocked expression. Publishing posts whose content contains expressions that fail validation is blocked at the editor - Gutenberg / the Divi 5 Visual Builder surface a clear error, and the classic editor and the Divi 3 & 4 builders abort the save before any database write so the existing post is left exactly as it was (a published page stays published with its previous content; in-progress edits remain in the editor for you to fix and re-save).

Validation uses a curated allowlist of safe callables (WordPress conditional tags) plus an extension filter for adding your own. Out of the box the following work:

current_user_can('editor')

Numeric / string literals, true / false / null Custom callables (e.g. my_custom_helper() or MyTheme::shouldBeVisible()) are NOT allowlisted by default - admins explicitly add them via the content_visibility_for_divi_builder_allowed_callables filter (a ready-to-paste snippet is generated by the content scanner on the Expression Validation tab). The following types of expressions are blocked: Unknown callables: function or static-method calls not on the allowlist - fix by adding to the allowlist filter or removing from content Bare identifiers: wtf (without parens) - must be a function call, static method, class constant access, or a true/false/null literal Dangerous functions: system('ls'), update_option(...), wp_mail(...), etc. - built-in denylist (filterable) Variable access: $_GET['cmd'] - $ and T_VARIABLE are not allowed String-as-callable: 'system'('ls') - string literal followed by ( Object instantiation: new ReflectionFunction(...) - new keyword blocked (write a static helper that does the new internally instead) Instance method chains: Foo::bar()->baz() - cannot be reliably analyzed; rewrite as a static helper Code execution keywords: eval(...), include(...) - blocked token types Backtick execution: `ls` - backtick character blocked Assignment: $x = 1 - both $ and = are blocked characters

Yes! Three filters are available for developers to customize validation behavior. See the "Developer Filters" section below for details.