@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:
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:
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!
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!
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!
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!
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:
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 …
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:
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:
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.
@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.
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]
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
For dynamic data:
@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.
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.
7 Likes