In many places in my app, I want to set a Thing’s slug based on one or more fields of the Current Page Thing. I can do this successfully using the Set a Thing’s slug action.
But the problem is that all my fields on the page go blank. It’s like the autobinding connections are broken. I have to refresh the page (with the new slug URL), and it works again.
Thanks so much for your reply. So it is supposed to work - that prompted me to investigate it in depth now and I successfully narrowed it down.
There is definitely a bug which I will raise with support: when the slug updates, any Group on the page whose Data Source is set to Current Page Thing, loses its connection to that Thing (it becomes empty). If you’re using Current Page Thing directly on an input or text etc., then you don’t have a problem - that stays connected to the Thing. But Groups lose their connection.
Since my fields were autobound to the Group Thing’s Field X, they lost their connection and all go blank.
A workaround for now is to use a Display data workflow action to explicitly set the Thing on the Group immediately after changing the slug.
Thanks again for confirming it does work in simple cases.
Indeed, I was able to reproduce the issue by wrapping the Input in a Group whose data source is Current Page Thing.
Another work-around is to set a custom state of type Thing in the Page is loaded event (set it to Current Page Thing) and then use that custom state as the group’s data source (instead of referencing the Current Page Thing directly). At least it worked in my test setup.
An update on this. I was in touch with support and they tried it on the demo page I created - and it works fine for them. I went back and found it now worked fine for me… for about 5 or so changes, and then breaks. The app where I first observed the problem is also showing the same behaviour - i.e. it now works the first few times. Am investigating further.
Demo of the problem with full explanation. This demo takes an unusually long time to surface the bug - over 60 slug changes. Usually it’s been a lot less than that.
Hi @sudsy, an extremely disappointing response from Bubble support.
They recommend the workaround! No acknowledgement that there is a BUG/race condition that they’ll actually FIX and in the meantime they’ll update the documentation to warn people about it. Just, use the workaround and let’s hope nobody else runs into the same problem.
The worst part is, because it looks like a race condition, maybe in dev testing this will work absolutely fine, but some end users out there will have these mysterious glitches which nobody can explain. And hours of support time and lost customers for both Bubble and the app developer will be the result.
Every time I’ve reported a bug to Bubble ‘support’ their response has been the same: shrug “I can see what you mean, but we’re not going to fix it”. I’ve wasted at least a dozen hours trying to help them - won’t make that mistake again.
Worse, this thread will close shortly because I’m the only one replying. A lonely day bubbling.
There’s a very slightly simpler way to use @sudsy’s Custom State workaround.
In the Page is loaded workflow, use a Set Data action on your outermost group to set that Group’s data source to Current Page Thing. Although you might expect it’s the same as configuring the Current Page Thing as the data source directly in the property editor for that outermost Group, setting it in the Page loaded event is more reliable for me: the Thing remains connected through thousands of slug changes.
