Yes sorry, I had forgotten about the security period you took for that when I made my recent comment, my apologies. Of course we appreciate all the work you did during that stressful period of time.
With that said, if I understand the timeline correctly, there was still nearly two weeks of the feature request idea sitting there pending approval before the security incident came to your attention. My two cents is that it should still not take that long to simply approve an idea for voting on (especially since that isn’t a commitment to doing the work, just for collecting interest details with votes). Ideally the approval time for that should be days at most, not weeks. And ideally it’d be no wait at all if we used the forum’s software for voting on ideas instead. I hope that’s taken into consideration again because there wasn’t much improvement at all since the original ideation process post unfortunately.
Again we all very much appreciate all the work being done, this product is fantastic! But that doesn’t mean there isn’t room for improvement in processes like ideation.
I’ve tested and is not working in this case:
I’ve a text field, field text is empty so I want to show a fallback → result is that dynamic data stop working
I just noticed that the @fallback interprets ‘0’ as empty. My use case requires the @fallback to output '1' when the field is truly empty, but the field can have values from '0' to '4'. Currently, when the field value is '0', the fallback of '1' is being output instead of the desired '0'. Is there a workaround for this behavior?
yep, I can replicate the issue with dynamic tag that returns 0. {acf_number @fallback:'NO DATA'} will output “NO DATA”, even though acf_number returns “0”.
I’ll open an internal bug report about this.
Thanks!