Content Visibility for Divi Builder
| 开发者 | jhorowitz |
|---|---|
| 更新时间 | 2026年5月23日 04:03 |
| 捐献地址: | 去捐款 |
| PHP版本: | 7.0 及以上 |
| WordPress版本: | 7.0 |
| 版权: | GPLv2 or later |
| 版权网址: | 版权信息 |
详情介绍:
安装:
- Upload the plugin files to the
/wp-content/plugins/content-visibility-for-divi-builderdirectory, or install the plugin through the WordPress plugins screen directly. - Activate the plugin through the 'Plugins' screen in WordPress
- You're Done! You will notice that Section and Module settings dialogs will now have "Content Visibility" as a configurable setting.
屏幕截图:
常见问题:
Will this work for any module, even custom ones?
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!
What if I deactivate this plugin? Will all of my content reappear automatically?
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!
How do I use it!?
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.
What is Expression Validation?
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 an allowlist of safe token types (function calls, literals, operators, etc.).
- Checking function names against a denylist of dangerous functions (e.g. exec, system, file_put_contents, eval, etc.).
- Detecting attempts to use strings as callable functions (e.g. 'system'('ls')).
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).
What expressions are allowed with validation enabled?
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:
is_user_logged_in()current_user_can('editor')is_admin() && is_singular()is_page() || is_archive()- Comparison and logical operators:
==,!=,===,!==,<,>,&&,||,!,?:,?? - Numeric / string literals,
true/false/null
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 atrue/false/nullliteral - Dangerous functions:
system('ls'),update_option(...),wp_mail(...), etc. — built-in denylist (filterable) - Variable access:
$_GET['cmd']—$andT_VARIABLEare not allowed - String-as-callable:
'system'('ls')— string literal followed by( - Object instantiation:
new ReflectionFunction(...)—newkeyword blocked (write a static helper that does thenewinternally 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
Can I customize the validation rules?
Yes! Three filters are available for developers to customize validation behavior. See the "Developer Filters" section below for details.
更新日志:
- Fix blank content visibility expressions causing PHP errors in Divi 5. Thanks to @ighulme and @beachmat for the bug reports!
- Visibility expressions are now evaluated against an allowlist of known-safe callables (default: WordPress conditional tags). Function calls and static method calls not on the allowlist are rejected with a "Contact the site administrator" error.
new, instance method chains (Foo::bar()->baz()), variable functions, string-as-callable, and bare identifiers are hard errors and cannot be allowlisted — rewrite as a static helper. New installs have validation enabled by default; existing installs ship with validation off and a persistent admin notice prompting the migration workflow. - The Expression Validation tab now generates a copy-paste
add_filter('content_visibility_for_divi_builder_allowed_callables', ...)snippet pre-populated with every custom callable found in current content (with first-sighting context: post id, module name, admin label, file:line via Reflection when available). Non-allowlistable patterns (instance methods, etc.) are listed separately as "must be rewritten." - Posts whose content contains expressions failing validation cannot be published while the toggle is on. The REST flow (Gutenberg / Divi 5 VB / API clients) returns
WP_Errorwith a structured error message; the classic editor and the Divi 3 & 4 builders abort the save before any database write so an already-published page stays published with its previous content, and the in-progress edits remain in the editor for you to fix and re-save. - After every save, validation findings are stored as private post meta and surfaced as a yellow (validation off) or red (validation on) admin notice on the post's edit screen.
- New REST endpoints under
cvdb/v1/:security/scan,security/validate-expression(server-truth validator for the inline UI),notices/rating/dismiss(replaces an AJAX action). - Persistent red admin notice on every admin page when PHP
eval()is unavailable on the host (e.g. Suhosin'sexecutor.disable_eval, custom hardening). Detected via runtime smoke probe. - New filter:
content_visibility_for_divi_builder_allowed_callables. Extension point for admins to allowlist custom callables. Accepts function names andClass::methodstatic-method entries; namespace-qualified names are normalized (leading\,namespace\prefix stripped, lowercased). - New "Expression Validation Filters" tab** on the API Reference page documenting all four expression-validation filters (
blocked_functions,allowed_tokens,allowed_chars,allowed_callables) with paste-ready examples.
- Add Plugin URI.
- Fix undefined variable in cvdb-et-builder-element.class.php. Thanks to @kindred for the quick bug report!
- Refactor the code for performance and maintainability.
- Add Divi 5 public alpha support!
- Drop Divi 2.x support.
- Catch errors in visibility expression evaluation; this allows the rest of the page to load while only hiding the module or section that triggered the error.
- Email site admin when errors in visibility expression evalution occur with helpful debugging information (i.e. the error that occured, the URL on which it occured, and the full shortcode contents of the relevant module or section as an attachment).
- Fix compatibility with Stop Spammers plugin. Thanks to @kindred for providing access to a test environment exhibiting the issue!
- Fix compatibility with the Divi Library.
- Fix compatibility with the Divi Theme Builder.
- Restore support for DiviExtension modules in Divi 4.10.x.
- Fix the backend documentation page so that currently-available modules are shown.
- Fix the rating link image's styles.
- Restore support for lazy-loaded modules in Divi 4.10.x. Special thanks to @chaostica, @jgarces and @sthaney for contributing information which helped lead to the fix!
- Fix extraneous inclusion of builder.js, which in turn fixes various backend/classic editor logic. Thanks to Bernard Lemieux of bernardlemieux.ca!
- Fix the behavior of content_visibility_for_divi_builder_shortcode_* filters.
- Emergency hotfix for crash introduced in 3.13.
- Fix PHP v7.4.x notice spam with recent Divi versions.
- Fix interoperability issues with newer WordPress versions.
- Fix issues with Divi Builder 4.x releases.
- Remove hold harmless agreement.
- Remove usage tracking entirely.
- Fix request parameter sanitization.
- Fix optional usage tracking.
- Fix an interoperability issue with other Divi module extender plugins.
- Fix deprecation notice spam. Thanks to Ben Harper of 3dtek.xyz!
- Fix missing ET_BUILDER_DIR . 'layouts.php'.
- Fix version checker options.
- Update license terms.
- Fix the issue wherein builder-fixes.js forces builder.js to be loaded in the header instead of in the footer. Special thanks to @kihoshin for helping to locate this error!
- Better multisite support.
- Remove the need to clear local storage in modern browsers to see the "Content Visibility" settings on Sections / Modules.
- Fix distributable...
- Fix "Currently Available Module-Specific Actions and Filters" tab not displaying available actions and filters in the Module Extender API Reference.
- Add support for Visual Builder in Divi 3.x.
- Fix Builder UI to handle ']' characters in Content Visibility expressions.
- Add Module Extender for Divi Builder functionality; see API page after upgrading under Tools -> Module Extender API Reference.
- Add usage tracking. If you prefer not to submit your usage data, this can be disabled on the plugins page by clicking "Disable anonymous usage tracking".
- Add links to ratings and reviews to help spread the word.
- Call load_plugin_textdomain().
- Added i18n support.
- Fix handling of double quotes in Content Visibility expression. Thanks to Dave Bullock of memberium.com!
- Initial Release