Reworked Conditions and Dynamic Data

[Louis]

Hello everyone,

Following yesterday’s live, I wanted to take a quick moment to see with all of you whether the rework on conditions and dynamic data is as fundamental as I believe it is.

You can find the live here (up until around the 35’ mark):
https://www.youtube.com/live/5ALkO2odVUw

Some users have emitted some reserve on the use of nested conditions and dynamic data.

What are your thoughts? Do we pause this step until a later stage?

Thanks for your input.

[StrangeTech]

@Louis

What are your thoughts? Do we pause this step until a later stage?

You can probably guess what my response will be, here it is none-the-less.

The visibility conditions UI demoed on the live is a great improvement and addresses all of the points I raised here:

Visibility conditions limitations and logical quirks

As we have been doing more challenging and complex websites with Cwicly, we have been facing certain limitations in the visibility conditions. The first issue is that except for very simple cases, just being able to switch between AND / OR is not sufficient. Example: Display CTA section if - Pages are - Home, About or Contact Us AND Coming soon / Maintenance is not enabled OR User is admin There are many cases where a sequence of AND / OR logic is required. So far, due to the full-featur…

Also the dynamic data changes are incredibly powerful and bring a whole host of possible points for discussion.

The first thing that comes to mind if this is added to all places where dynamic data is used, is how it addresses simple things like being able to use Featured Image as the fallback for an image block if an ACF image is not available, or vice versa - this is something we have been interested in for a long time as a missing feature, so will be very much appreciated.

@Louis, regarding your question about whether the source should be dynamic, here is one possible use case:

Imagine you have an ACF field you define for a specific post or page, let’s say that has the possibility to be null. Then imagine you have an equivalent global ACF field in an options page. Making the source dynamic will allow you to use the global ACF field as a fallback to the page/post based one.

One questions I have @Louis, Does this allow us to specify a dynamic function and/or dynamic shortcode and pass dynamic parameters to them? This is a very important feature for us that has some limitations in the current UI, so I really will love to see this included. Based on what you demoed it seems eminently possible.

Regarding reservations, my only consideration is that everything is thoroughly tested and proven to work before it is released “in the wild”.

I am curious your thoughts about this.

[StrangeTech]

Also @Louis, you asked if we’d hit any limitations with visibility conditions, this is definitely one to test the new implementation against:

@StrangeTech

Confirming also that both text and image fields work fine with taxonomy archives.

So far, it is only:

1. Repeater fields
2. Relationship fields
   3. Visibility conditions

…that don’t work.

@StrangeTech

this same issue also affects visibility conditions, we have had to use a custom function for this also, instead of being able to use the built-in ACF field features:

function service_has_stats() {
	$has_stats = false;
	$term = get_queried_object();
	$stats = get_field( 'stats', $term);
	
	if ( $stats ) {
	  $has_stats = count($stats) > 0;
	}
	return $has_stats;
}

[Jonas]

Cwicly is very strong with Dynamic Data and Conditions since the beginning I believe. In fact Cwiclys implementation of Dynamic Data and Conditions was the reason I tried Cwicly almost 2 years ago resulting in becoming my favorite Site Editor very cwicly

The only limitations I remember encountering were about Dynamic Data:

• Make all dynamic data available for Attributes and Tooltips
• Dynamic Attribute: Source: »Taxonomy Query« missing
• ACF Label available for Attributes

So I do not think you should pause with these features. The new UI makes these features even easier to understand and therefore more accessible

[Marius]

Hello @Louis.

I don’t think they are “fundamental”, because that would mean that there were neither conditions nor dynamic data.
On the other hand, it is no secret that conditions lack in some areas and that a unification and enhancement of dynamic data is necessary.

The whole thing sounds to me as if you are now faced with a decision to do something (or not) that will take months of development time and other areas will have to wait.
I’m having trouble recognizing the “problem”.

I find this implementation important, not because I absolutely need it now, but because it forms the basis for important implementations to come.
That, in my opinion, is more the factor that should be given weight.

I have noticed that this time the excitement, or general interest, has not been so great compared to other previous presentations.
But that has more to do with the fact that we already have this functionality to some extent, and that users can’t quite get their heads around it yet and how much sense everything suddenly makes as soon as they can play with it themselves.

@Louis

Some users have emitted some reserve on the use of nested conditions and dynamic data.

Of course, I have no insight into what users write to you personally.
But that’s not what I’ve observed. At least not to an extent that stands out.

One last thing.
Please consider blocking this weirdo on the YT channel. He brings unrest to the live streams. This was not the first time, and won’t be the last otherwise.

[dazziebunz]

I don’t really have anything to add that hasn’t already been said, but just wanted to say I am really excited to see the conditions and dynamic data rework. It looks amazing and can definitely see myself using it to it’s full potential.

On the flip side, if there was a choice between this rework and something else taking priority it would help to know what that might be.

I wonder if perhaps there are some things that should be prioritised in the run up to getting cwicly on the WP repo?

[marc]

Nothing new to add from my side either, just posting to let you know that I can’t wait to start using the new Dynamic Data menu

I haven’t (yet) needed to use such deeply nested visibility conditions, but I definitely see the value in it. And I love to see how cwicly is opening up to a wider user base while continuing to enable advanced users in many ways that other page builders don’t (and/or can’t).

As to whether to pause further development of conditions/dynamic data, I fully agree with @dazziebunz – hard to say without knowing what other features would get pushed back as a consequence.

[StrangeTech]

@Louis, having thought about it and remembered some other previous experiences where we were missing certain features, here are a few more feature requests and bugs for the visibility conditions / dynamic data.

Hopefully this gives you a quick way to review them in one place, so you can include anything that you believe is high enough priority for the release.

Firstly, I just wanted to check about reordering the conditions, as it wasn’t 100% clear from your demo in the live if this is supported:

Ability to reorder and use and/or for each visibility condition

Currently we can specify either AND or OR for all inclusion and exclusion rules independently. This is fine for many cases but some logic requires more granular control. One example is, if you want to include all singular pages and then exclude specific pages, this works well with one “Show If” rule and one “Don’t Show If” rule. If you then then add other “Don’t Show If” rules that have different AND/OR requirements (such as for the coming soon / maintenance functionality), it becomes impossib…

Then there are these:

Add Query options from the Themer visibility conditions to block visibility conditions

Currently when adding Visibility Conditions to templates, we can set by singular/archive, by post type and by selecting specific posts. [Screenshot 2024-10-08 at 19.15.53] When adding Visibility Conditions to blocks, we don’t have the same options. It will be great to be able to have this same ability for blocks within templates. Thanks!

Add visibility conditions for Url and Url Path

Currently we can set visibility conditions based on URL parameters, but we don’t yet have access to the full url or the url path. So, I am requesting that the upcoming improvements can include this ability, as we have already needed it in at least 2 projects and had to workaround it. [Cwicly-VIsibility-Conditions-Dynamic-URL] This will really help when using a template for multiple post types or where blocks in a template needs to be customised based on different urls. Thanks!

Add visibility condition that accepts DateTime

Per this thread: It will be useful to have a Visibility condition that accepts a DateTime. This can be a completely new one, or the existing Date condition can be enhanced to accept an optional time portion. Thank you!

Add "contains" visibility condition operator to check if values are within an array

Similar to what was mentioned here: But adding specific support for testing whether values are present in an array. I noticed that in some Cwicly contexts, this works implicitly, for example checking whether the post term is within a set of selected terms. It will be great to have a dedicated way to do this for normal visibility conditions. Thanks!

Dynamic Attribute: Source: »Taxonomy Query« missing

Same goes for Visibility Conditions. Inside my Taxonomy Query I would like to show or hide things based on the term name, which is also not possible at the moment. [Bildschirmfoto 2023-08-30 um 20.07.13]

Repeaters:

Visibility conditions for Repeater - is first item, is last item

We are attempting to output a simple comma separated list of authors from a repeater: Examples: “Author One, Author Two.” “Author One.” We were thinking to use prefix or suffix in the dynamic inserter for the delimiters but these don’t appear to be able to be dynamically turned on and off. So we thought of including a separate block containing the ", " and the “.” and only show these if the item is not the last and is the last respectively. Because there are no visibility conditions based …

Condition operateur >, < ,<=, >+ based on nb items in Repeater, Query, ACF

Hi all, Would it be possible to add to the visibility conditions operators =, >, <, <= and >= to a value? Then this would require new conditions such as the number of values set in a repeater or the number of results in a query. I imagine it to be useful in multiple situations, for example, when the result of a repeater or a query is equal to 1, to change the grid or slider for a layout showing one item, or to be able to adjust the number of columns of a grid depending on the number of items. …

Components:

Component fields based conditions

In the conditions list to have the option to select the fields of a component without the need to add an extra conditional field on the component. From where the need? Currently if I add a field that will not have content in some cases, it will have the html tags display on the frontend anyways. I would just like to have a quick option to hide the frontend output if the component field is empty. Currently you can do that by adding another condition component field, but I feel it just clutter…

Lastly, here are some bugs that may be pending:

Conditional Visibility inside Query Loop with Front End Rendering

Hi. I noticed that element that has conditional visibility inside query loop is not showing when front end rendering is enabled. when frontend rendering is disabled, visiblity condition works inside query loop.

Repeater Conditional Visibility Issue

@Louis i saw the update. condition with woocommerce related works now. but still condition with function return it doesnt work. or i am missing something also as mentioned above, with cart context, acf fields are not rendering inside it. for example i have a product with custom field. when i add that using dynamic options on paragraph element it doesnt appear.

Issue with visibility conditions and :empty pseudo selector

Cwicly Plugin version: 1.2.9.9.1 Hi, It seems that Cwicly generates some spaces instead of completely removing blocks when their visibility condition is false, which prevents :empty pseudo selector to work properly on their wrapper element. NOTE: It seems to happen only with 2 or more blocks inside the wrapper. [image]

Visibility conditions don't work with arrays

Cwicly Plugin version: 1.3.1 Hi, This is an issue I constantly have to deal with. Though there are different workarounds, I think it’s worth requiring a fix to make life easier Let’s say I have an ACF file field, and that I don’t want to display it if no file has been selected. The get_field() function will return: false if no file has been selected; a non empty array with data if a file has been selected. (So, not only I don’t want to display it, but it will also cause an error w…

For dynamic data:

Dynamic tag for a group field inside of a repeater field

@Louis, just a quick follow up, without frontend rendering on, this works flawlessly. With frontend rendering on, it is coming back as [object Object]. Without frontend rendering: [Screenshot 2024-02-22 at 22.28.03] With frontend rendering: [Screenshot 2024-02-22 at 22.26.48] Show in REST API is enabled and other fields work correctly, so it is specific to these Repeater + Group fields.

Make {acffield=field_name} work in taxonomy terms

Hello @Louis, I can confirm we have used this multiple times and it works. The only limitation we found was it didn’t work in an attribute for a Section block. We had to use a Div block change the html tag to section and add the default Cwicly Section block attributes to it.

[Louis]

Hello @StrangeTech,

Thank you very much for going through the feature requests and bugs relative to conditions.

The conditions UI and logic is nearly finished and I expect to have the beta out in the next couple of weeks.

Drag & drop definitely has to be part of the deal