ndiego / block-visibility Goto Github PK

Add an integration for Metabox.io, much like the the existing ACF integration.

This request is similar to #14

What problem does this address?

Hi and thanks for a brilliant plugin!

One thing I’m missing, when working with a lot of different visibility options on different blocks is to be able to preview the page under certain conditions.

Like if I have a bunch of blocks that are scheduled to show at a certain date and time, other blocks scheduled to be hidden at another time, and other blocks visible only to people logged in etc. Then it would be awesome to be able to preview the page with specific conditions. Like “logged in user at 9.30 march 12th 2022”, and see what the page would actually look like then.

Kind regards,
Simon

This issue was ported from the support forum on WordPress.org

What problem does this address?

"Hello. Please add conditional rules by Custom Fields in the free plugin. It should be there before the ACF feature, in my opinion, because a lot of us actually run away from ACF custom implementation of post metas and prefer working with custom fields natively: in Pods, Metabox, CMB2... and using a Gutenberg page builder as Toolset, Kadence, GenerateBlocks in order to retrieve values and create loops, those plugins work better or only with native custom fields, not always ACF's. Please imagine the various scenarios that are restricted right now and in which we need to code the custom field block visibilities separetely, despite using your plugin. I don't understand how this work, but I suppose you may not be able to cover all default custom field types, but if only a simple text, number, email field, it is going to be okay. And leave repeater fields etc for pro versions, following the same price model of Metabox, Toolset, ACF and Pods. Thank you."

This issue was submitted via email

It would be amazing if you add support for the use of shortcodes, and had the UI similar to the ACF integration.

What problem does this address?

This would allow developers to create and use any custom shortcode to manage block visibility, and would greatly extend functionality, making the support of third-party plugins like Restrict Content Pro easy without requiring native integration.

What is your proposed solution?

The Editor flow would be:

• Select the option Shortcode in Controls
• Provide a text input field to paste the shortcode
• Show/Hide the block if (as found in ACF integration)
• Select Condition (as found in ACF integration)

What problem does this address?

Largely in the context of Blocks as Widgets (or other full-site-editing), I think this plugin could really benefit from some more flexible Location style rules. Let's say I have a Gardening website, and I have sections for things like Flowers, Fruits, Vegetables, etc. I'd love to be able to say: "This block only shows up in I'm on the /flowers/ page, or any child pages of that page."

What is your proposed solution?

I see two primary methods - but both have their own merits and they could certainly coexist.

1. Include a rule for matching URLs. That is, show the block if the URL contains "mysite.com/flowers". This would make it appear on the Flowers landing page, and any child pages that are descendants of it.

2. Include the option for including descendent posts automatically.
   Currently, I can choose the following:
   Show the block if
   Post
   Page
   Is any of the Selected
   Flowers.

What if there was a checkbox that said: "Include child/descendent posts" automatically? This would prevent users from having to go back and add another child-page to the block rules each time they add a new child page in that section.

If i wan't add some notice when block hide, how can i do this

Ported over from WordPress.org.

The list of available options for “Show the block if User Metadata…” are:

• Has any value
• Has no value
• Value is equal to
• Value is not equal to
• Value contains
• Value does not contain

If the meta field contains numeric data, it would be helpful to choose block visibility if the meta

• “value is equal to or greater than”
• “value is equal to or less than”

Alternatively, if the “Enter meta value” field could accept arguments like “<=1” instead of just integers, that could work perhaps?

That would then allow the existing 6 options to suffice, because I could choose option 3 and then enter “<=1” instead of just “1”

Bug submitted via support email:

If I use the "Any" Query String feature for the same variable on 2 or more lines, it doesn't work.

For example in case of google search and display network ads, the landing URL would have either one of the 2 query string in the URL:

source=GoogleDisplayNetwork
source=GoogleSearchNetwork

The behaviour expected would be that in case of either one of the 2 query strings above is present, the block should be visible. However, the block in question does not display for either string being present in the URL. It works fine if the variable names are different, but not if they are the same like in the use case above.

What problem does this address?

Advertisers create many different ad variations that lead to the same landing page. Unfortunately this can create a messaging mismatch between the ad and landing page which causes confusion and a lower conversation rate.

What is your proposed solution?

Enable a block's text to change based on the text in a url. For example the copy of headline block could be "Free Ebook for Developers"

If the URL string includes example.com/?headline=free+ebook+for+WordPress+developers

... Then the copy in the block should change to "Free Ebook for WordPress Developers"

The block should have a default key, but also allow the user to change the key to something like "headline".

When I was a full time advertiser, "Dynamic Text Replacement" was a heavily used Unbounce feature for my team https://documentation.unbounce.com/hc/en-us/articles/203661004-Working-with-Dynamic-Text-Replacement

It allowed us to experiment with and deploy new messaging rapidly, without having to create completely new landing pages.

Block visibility does allow changes based on the URL string, but this feature proposal is more flexible because you do not need to know the text change beforehand.

Ported over from WordPress.org:

I’d like to create a reusable block that displays a week after each post is published. Is there any way to show or hide a block after a specific number of days rather than after a specific date?

Description

Some blocks are missing from the Block Manager. Of note, all EDD blocks and custom blocks, like the Icon Block.

What problem does this address?

It's really easy to set custom visibility for some blocks and to forget about it.

If you do so, you may deactivate the plugin and make public some content without noticing.

What is your proposed solution?

If at least one block has a visibility option set, warn user before plugin deactivation. The message could be like :

You have at least one block with a visibility option set. Deactivating this plugin will make this content public.

It doesn't have to specify which blocks or where to find the blocks (even if this would be nice).

Description

In v2.5.0 the date/time picker was updated, and custom functionality was stripped out. As reported, this functionality was useful and should be added back, if possible, in the new component.

• Time is not set to 00:00 by default, time is set to the current time, I think it’d be the same as before which is 00:00 by default because we are setting time in the future.
• ‘End to’ day does not change automatically to one day after the ‘Start from’ day, so it is quite time consuming.

System information

• Block Visibility version: v2.5.0

Description

The Conditional Opacity setting allows you to optionally make blocks transparent when visibility conditions are applied. Due to how blocks in the Editor are structured, this functionality does not work for Paragraph and Heading blocks.

However, if markup exists within a Paragraph or Heading block, for example, <mark>, the opacity will get applied to that element. Paragraph and Heading blocks should be excluded entirely from the Conditional Opacity styles to avoid this issue.

Expected behavior

Actual behavior

System information

• Block Visibility 2.5.0

Description

Custom class names that get added to the BlockList element via the editor.BlockListBlock hook get overwritten by custom classnames from Block Visibility Plugin.

I believe this could be fixed by doing the following:

let classes = classnames( 
 	{ 
 		'block-visibility__is-hidden': isHidden, 
 	},
 	props.className, 
 	controlsClass 
 ); 

Here is an example of how it is done in core: https://github.com/WordPress/gutenberg/blob/70ba9218ae53e31d2c26689eed2e698dcea7f3aa/packages/block-editor/src/hooks/layout.js#L457-L460

Step-by-step reproduction instructions

Add another sample plugin that tries to filter editor.BlockListBlock and adds a custom class name to the element. See that this class doesn't get added when the Block Visibility Plugin is enabled.

Expected behavior

The custom classNames added in the filter get added

Actual behavior

Only the classes from Block Visibility get added. It overrides custom classes added by other filters

Screenshots or screen recording (optional)

System information

• Block Visibility version: 2.5.2
• Block Visibility Pro version: Not installed
• WordPress version: 6.1.1
• Gutenberg version: 15.0
• Are all plugins except Block Visibility, Block Visibility Pro (if installed), and Gutenberg (if installed) deactivated? Yes
• Are you using a default theme (e.g. Twenty Twenty-One)? Yes

Description

Does not detect translation to other languages in the Site/Post/Page Editor. On the settings page everything works fine.

Step-by-step reproduction instructions

1. Add sample translated files to the directory:
   /wp-content/languages/plugins/block-visibility-de_DE.mo
/wp-content/languages/plugins/block-visibility-de_DE-2b47503f90344d6580630a5c3c521589.json
/wp-content/languages/plugins/block-visibility-de_DE-528469e0eb827b69963521f596eeae41.json
2. Check Editor if the translation has been detected.

System information

• Block Visibility version: 3.0.0
• WordPress version: 6.1.1 & 6.2-RC4
• Gutenberg version: 15.4.0
• Are all plugins except Block Visibility, Block Visibility Pro (if installed), and Gutenberg (if installed) deactivated? Yes
• Are you using a default theme (e.g. Twenty Twenty-Three)? Yes

What problem does this address?

If a site uses a lot of scheduled blocks, it could easily get littered with blocks that are past their scheduled dates - never to be shown again - but clogging up page editing screens. It would be great if I could say that "This block stops showing on Date X and then should be removed from the content."

What is your proposed solution?

Add a checkbox to Schedule logic that says something like: "Remove this block after the last scheduled interval."

Then, when parsing the page's blocks for conditional display, if a block's scheduled logic has passed and this option was selected, remove the block from the page completely.

Bug reported via support email:

Block Visibility Pro loads various admin scripts on the front-end for pages that run Ajax which caused issues on our site. I've recorded a 3 minute video:
https://www.loom.com/share/f6e45f00c414401b9ff4111c353c1e81

I fixed it with the following:
file: /block-visibility-pro/includes/class-block-visibility-pro.pho
line 118
change this:
if ( is_admin() || ( defined( 'WP_CLI' ) && WP_CLI ) ) {

to this:
if ( is_admin() && ! ( defined( 'DOING_AJAX' ) && DOING_AJAX ) ) {

What problem does this address?

There have been numerous requests to compare a custom field to the current date. A few examples:

I am wondering if there is a way I can hide a block based on a custom date field? The use case I’m thinking is have a form show on the bottom of all event single posts and that form only shows until the event end time.

I have a ACF field in my (CPT event) page that sets the date the event is expired. If that field is greater then today’s date I want to hide the block. So is it possible to something to compare the field to today’s date?

Is there a way to add a input mask to the url URL query string visibility settings? This way the value has to be in a certain format.

This issue was ported from the support forum on WordPress.org

Description

My use case: I am creating a new website and moving off of some old technologies, and am looking to use WP Fusion and Block Visibility going forward. We require our site to have "bypass" links which would allow a visitor using a specific link to view a page even if certain content would normally require a user to be logged in and have a specific membership level.

For a working example, here's our current website (not using Block Visibility), if you visit this page, you'll be told to signin or signup:
https://apexauthors.com/introduction-to-self-publishing/
However, if you visit this link, then it will treat you as though you were logged in with the right membership level even if you aren't logged in:
https://apexauthors.com/introduction-to-self-publishing/?key=2b4dd2fb2f8598caf8b8ed6f917dec5f

When using the block_visibility_is_block_visible filter to control access, however, it is ignoring the filter when a user is not logged in because it hard-codes the user as not having access after the filter is applied.

Step-by-step reproduction instructions

1. Create a block, set a user role (logged in, or subscriber, or any valid option so a normal link will appear if they fit that user role), save the page.
2. Visit the page; if you are logged in, it appears. If you are not, it won't.
3. Add the following code to your functions.php file:

add_filter( 'block_visibility_is_block_visible', 'private_tags_bypass_bv_check', 15,3 );
function private_tags_bypass_bv_check($is_visible, $settings, $controls) { return true; }

4. Visit the page; if you are logged in, it appears. If you are not, it still won't.

(In my actual use case, I have a plugin which decides if the block should be visible or not depending on other criteria, but the above reproduction steps are an easy way to spot the bug.)

Expected behavior

The filter should be able to control the block visibility.

Actual behavior

The filter is ignored if the user is not logged in.

Screenshots or screen recording (optional)

System information

• Block Visibility version: 3.0.2
• Block Visibility Pro version: Not installed
• WordPress version: 6.2
• Gutenberg version: WordPress Core
• Are all plugins except Block Visibility, Block Visibility Pro (if installed), and Gutenberg (if installed) deactivated? Yes*
• Are you using a default theme (e.g. Twenty Twenty-One)? Yes*

*Screenshot is from my previous testing but I have confirmed on just the default settings as requested.

What problem does this address?

"I like this plugin very much because it allows me to show different content to visitors who are logged in versus those who are not. Invariably this leads to the creation of two similar blocks within an article, both of which would presumably be visible if the plugin were to be uninstalled or encounter unforeseen issues. In those cases it would be useful if the site owner had a readily available list of which posts make use of this plugin.

For example, you might have a gallery block of vacation pictures which includes images of your family, all of whom are able to log into your WP site, so you make that block available to logged-in users only. If you don’t want to show family pictures to the rest of the world then you can duplicate the gallery block, remove the personal images, and make this second gallery block available only to visitors who are not logged in. In the event of something going wrong, or the plugging being uninstalled, I assume that both gallery blocks would be available to all visitors. In lieu of a more graceful failure (which may or may not exist – apologies for not testing this fully yet) it would be useful to have a list of which posts make use of this plugin’s functionality so that those posts can be reviewed.

I’m not sure if I’ve explained that clearly. If I have then feel free to put it on the pile of possible enhancements. Cheers!" - @muppix

This issue was ported from the support forum on WordPress.org

Ported over from WordPress.org.

What a great plugin! Should be part of WordPress core. Thanks for bringing this to life. Part of my go-to stack.

I would love to have an integration with LearnDash. Simple stuff like conditionals for being enrolled in a course vs being a visitor. Course complete, etc. LD has the visitor and student shortcodes, but eh… shortcodes.

What problem does this address?

If I craft a complex rule set, it's cumbersome to apply it to multiple blocks that all want the same ruleset. And then if I want to modify the ruleset, I need to remember exactly which blocks on the site were using it so I can go back and find them all.

What is your proposed solution?

Support the concept of "Reusable Rule Sets".

I would love to be able to craft a complex rule set, and apply it to multiple blocks easily. (that is, just select a predefined rule set in the Block Visibility settings rather than do all the settings again.)

A sample use case: Black Friday Promotion

I could craft a complex rule set such as:

Only during a certain time frame
Only to users to aren't logged in
Only show if a certain URL parameter exists.

Then, each time I want a block to follow these rules, I just choose my existing rule set "Black Friday 2021 Promotion".
Then, if I decide to extend the promotion, I can easily adjust the schedule in one place, etc.

What problem does this address?

Can there be an option to make all the blocks that are hidden on a certain page to un-hide in a single click/toggle?

Thanks for the fast response! Exactly something like a 'visibility reset' button. At the moment we have a ton of hidden stuff on a lot of pages and after some time we update the page with more content + unhide all the content. It takes only a lot of time to unhide everything block by block.

Submitted by user via the contact form on blockvisibilitywp.com

There is no guide on how to create a new addon

I want to create my own addon, but right now I am spending a lot of time for searching original code snippets. There are different filters in Gutenberg, in PHP, so it's hard to unite different parts in one best-practice code

What is your proposed solution?

It would be nice to have some dummy addon in Github + article on your website about that. For example, right now I can't get to work filter 'blockVisibility.VisibilityControls'. I want to create something like "Integration" (ACF, WPFusion, etc) for personal use only. What do you think?

What problem does this address?

As of version 2.0.0, the ACF control only evaluates fields applied to the post/page/CPT that the block is on. However in ACF, fields can also be applied to users. There is currently is no way to create conditional content based on ACF fields applied to users.

What is your proposed solution?

Add a rule field where the user can choose between "User" and "Post" when selecting ACF conditionals.

This feature request stems from this support ticket on WordPress.org.

Description

Click the "Reset Settings" button in the Block Visibility plugin settings, which gives you the option to reset the settings on the current tab or all settings. The option to reset the settings on the current tab does not work reliably.

System information

• Block Visibility 2.5.0

What problem does this address?

We have Blocks that make sense when viewing online, but shouldn't be printed out if the user prints the page. It would be great if Block Visibility pro could hide certain blocks from printing. (I'm sure there are also cases where people want blocks to show ONLY when printed as well; that's just not our current need.)

What is your proposed solution?

Add a basic control that allows blocks to have their visibility based on whether or not we're currently printing.

What problem does this address?

"I think the option to show/hide a block per user for a specific time based on detection technique (Cookies, IP, or both). So each visitor/user gets a block show for a set time (eg. 48hours), after that the block is hidden for that visitor/user." – @Kapppa

This issue was ported from the support forum on WordPress.org

Description

When using Block Visibility with WordPress 5.8+, on the Widgets screen a PHP notice will appear when debug is enabled. This is a very common error that is cropping up in other plugins like Yoast SEO and Gravity Forms. A reference to the issue in Yoast SEO is here.

While this issue does not impede the functionality of Block Visibility in the Widgets screen, it is annoying to users that have debug enabled.

Step-by-step reproduction instructions

1. Install Block Visibility, the TT1 theme and make sure you are using WordPress 5.8+
2. Enable debug in wp-config.php
3. Navigate to the Widget screen and you will see the following notice.

Notice:

( ! ) Notice: wp_enqueue_script() was called incorrectly. "wp-editor" script should not be enqueued together with the new widgets editor (wp-edit-widgets or wp-customize-widgets). Please see Debugging in WordPress for more information. (This message was added in version 5.8.0.) in /Users/Local Sites/blockvisibility/app/public/wp-includes/functions.php on line 5663

Hey Nick

I am retesting your plugin. Doing a quick test. Looking through plugin settings and Gutenberg sidebar settings.

Activating and clicking settings leads me to Settings -> Block Visibility.

I notice a popup with a message with the title: "Thank you for using Block Visibility"
Spelling error: recieve -> receive

I see the information within the Block Editor area. Wonder what some of these are and then click the i (tool tip) for additional information. That is very helpful!

A very clean settings page with a nice overview of various features!

Going to an existing page. Clicking a Cover block.
Opening the sidebar settings area and checking out Visibility controls.

Wow you are actually using the new progressive disclosure panel. Which is brand new in Gutenberg.

There is also a PR being worked on here for Gutenberg:
Dimensions Panel: Add new progressive disclosure panel and update spacing supports
WordPress/gutenberg#32392

There are a lot of powerful options there.
Ending the test here for this mini round.

Description

When using WP Fusion checks with Block Visibility, warnings are thrown that $attributes are undefined.

This is coming from

The visibility options are still applied as expected at this time, but may not in future versions of PHP or similar with warnings behing served.

Notice: Undefined variable: attributes in /sites/testsite.localhost/files/public/wp-content/plugins/block-visibility/includes/frontend/visibility-tests/wp-fusion.php on line 100

Step-by-step reproduction instructions

1. Enable debugging on your site
2. Add a block, and add visibility options with WP Fusion enabled
3. Visit the front-end of your site where the block should be shown, making sure that no other rules previously would have set $is_visible to true
4. Observe warnings being thrown once per block that has visibility settings in place.

Expected behavior

No warnings should be generated by the base plugin.

Actual behavior

Warnings are thrown.

System information

• Block Visibility version: 2.2.0
• Block Visibility Pro version: 1.3.2
• WordPress version: 5.8.2
• Gutenberg version: Not installed
• Are all plugins except Block Visibility, Block Visibility Pro (if installed), and Gutenberg (if installed) deactivated? No
• Are you using a default theme (e.g. Twenty Twenty-One)? No

Bug reported via support email:

While working on a client's site over the weekend I noticed this plugin conflicted with Sensei.
I thought it was an issue with their plugin on the "render_block" filter but it appears it is an issue with Block Visibility Pro not returning a string for the variable $block_content but instead null of pages where it is hiding widgets. As a temporary solution I'm adding this filter but can you please patch this.

add_filter( 'render_block', function( $block_content ) {
if ( empty( $block_content ) ) {;
return '';
}

return $block_content;
} );

Description

For numeric ACF values, there is no proper working for the rule set because the condition in PHP is strict - https://github.com/ndiego/block-visibility/blob/main/includes/frontend/visibility-tests/acf.php#L205

If you remove === to == or try to add some type for this check, there will be the desired result.

Step-by-step reproduction instructions

1. Add any block (paragraph) to Gutenberg.
2. Add a rule set with ACF. ACF rule is "Show the block if 'Numeric ACF' is equal to 12"
3. Save the page

Expected behavior

You will see this block because the code tries to compare 12 == '12' (integer with string but without strict comparison)

Actual behavior

You will not see this block because the code tries to compare 12 === '12' (integer with string)

Screenshots or screen recording (optional)

System information

• Block Visibility version: 2.4.6
• Block Visibility Pro version: Not installed
• WordPress version: 6.1
• Gutenberg version: "Not installed" as a plugin, used from Core
• Are all plugins except Block Visibility, Block Visibility Pro (if installed), and Gutenberg (if installed) deactivated? Yes
• Are you using a default theme (e.g. Twenty Twenty-One)? Yes

What problem does this address?

"The default boolean boolean for multiple conditions is AND by default (ex : Schedule AND User Role).

It would be great to be able to choose the OR boolean operator.

Example: display from date1 to date2 OR user logged-out.

For the moment, I use the same block 2 times with different conditions. Not a big issue but it would be less error-prone to group all the conditions in the same block." - @mousstix

This issue was ported from the support forum on WordPress.org

What problem does this address?

"How can i hide blocks for some specific users (user name or user ID)?

I dont want hiding blocks by roles. I want hiding blocks for each specific user ID/ Name which i decide.

Because on my site i have for each user 30 tasks that he has to do. and if a user has done 1 of this tasks i dont want that he is seeing the task anymore because he has make it already." - @kleinefrage

This issue was ported from the support forum on WordPress.org

Description

Reported: https://wordpress.org/support/topic/there-are-some-areas-in-block-manager-where-the-translation-is-not-working/

My native language is Japanese. When I set the language of the site to Japanese, some parts are translated in the Block Manager in the settings page and some parts are not.

Screenshots or screen recording (optional)

https://gyazo.com/4ab13f7eb9862b70a1f120b55c09fff4

Hello,
A feature that would be nice, would be to have some kind of "global" variable (a boolean for example) that would be tested for value to activate or no a block. My use case is that I have a dozen of pages where I have a specific block element that I want to activate/deactivate all at the same time, but not according to a time parameter. If there was a variable that could be tested...

Description

Currently the Visibility panel forces any block such as the core paragraph that usually don't have any settings to get their settings tab shown. It would be kind of cool if the Visibility panel could work similar to the Advanced panel. Where it's aware of whether there are other elements in the settings tab and if not just render at the bottom of the styles tab.

Hey Nick

Here is an example from the plugin: https://wordpress.org/plugins/post-type-archive-mapping/

Query:
Post Type -> Taxonomy -> Terms

First of all thank you for such an amazing plugin.

You already promised for this feature:
"Show a block when someone has purchased something from your WooCommerce store..."

In addition, I want to request some thing:

Show a block when someone has purchased something from our WooCommerce store +
Let this also expire by number of hours/days since the date of purchase.

This way your plugin can be used as a Pay Per View (Block) plugin with Hours/Days based expire after purchasing any specific woocommerce product.

If you implemented this feature, your plugin will be rocking.

God bless you.

One tip for you:

Instead of using CRON (if you are using it)

Use new modern method suggested by WordPress:

That is action scheduler API:

Ref: https://actionscheduler.org/ (provided by wordpress)

Ref: https://woocommerce.github.io/code-reference/namespaces/default.html#function_wc_customer_bought_product (inbuilt function to check if bought)

I don't know why but I think:

This plugin can prove as a life saver for many of us!

Using your plugin will help too much for all.

Please consider this feature that I have shared above.

Content Future is: pay per view with expiry (hours/days)

Block Visibility currently only supports "Basic" ACF fields. There is a need to add support for "Choice" fields, which include checkbox, radio group, etc.

This feature was requested in the WordPress.org support forums.

Ported over from the WordPress.org support forum.

I would be nice to show / hide block based on custom query (but not in the URL)

I mean e.g. message like: “There aren’t posts of that category at this moment, but you may also like blah blah blah…” to be shown/hidden. if there are no posts in specific category (on archive category page),

What problem does this address?

"Similar to password protected pages or posts, I’d love to be able to password protect blocks" - @chzumbrunnen

This issue was ported from the support forum on WordPress.org

This issue was reported in the support forum here: https://wordpress.org/support/topic/hidden-content-7/

Currently WordPress does not provide a way for us to filter the widget wrapper markup conditionally based on the blocks it contains. We will need to followup with WordPress/Gutenberg to see if a filter, or another workaround, can be enabled.

A user's email address is not stored in metadata, so we need an alternative way to accomplish this.

Can I make a block visible based on the email of the logged-in user?

For example:
if email of logged-in user is [email protected], Harvard logo block should be visible.
if email of logged-in user is [email protected], Stanford logo should be visible.

Requested by existing Pro customer. Need a way to conditionally display blocks based on Fluent CRM tags.

What problem does this address?

The plugin has a limitation for visibility settings if a block has parent property. But in my case, I need an exception for my custom block with a custom parent parameter (not core/columns > core/column).

What is your proposed solution?

It would be great if you can add here some filters or give me the possibility to include my custom blocks in allow list even with parent property. Thanks!

I wondered if a feature request was possible for a repeater value? I know there will be limitations on you being able to validate this, but I know the field and value exists.

I have an ACF repeater field that, in most cases, consistently contains 5 rows of 2 (number) fields: Year and Value.

I’d like an option available to “show the block if” and then a raw text field to input a known repeater item.

Similar to how the ACF shortcode allows me to use: [acf field="rank_0_position"]

I’d like to add the following string to the “show block if” filter: rank_0_position

And still have all existing conditions available. Also, would it be possible to add “greater than”, and “less than” options to the condition field? This adds much more flexibility for numeric-based fields.

This issue was ported from the support forum on WordPress.org