Forum Academy Marketplace Showcase Pricing Features

Changing slug on a page breaks autobinding

Bugs
#1

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.

My reading of the manual page for slugs is that this should work okay:

Slugs can update in real-time, meaning if you update the slug on a page that uses the slug, the URL will automatically change.

Is this a bug?

#2

Seems to be working as expected for me. I can…

  • View a Thing’s page and display the value of a field via an Input element with auto-bind enabled.
  • Change the value of the field via the Input.
  • Generate a new slug via a workflow on the same page using the Input’s value. (And the URL auto-updates.)

Could it be related to privacy rules you have in place? Could it be related to the way in which you’re referencing the Thing?

Screenshots of your setup might be helpful for others to offer suggestions/feedback.

#3

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.

1 Like
#4

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.

1 Like
#5

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.

#6

I’ve made a new demo which updates the slug repeatedly until it breaks, no user intervention required:

I would be grateful if people can test this and report back how many slug changes it takes until the box on the right shows some red text.

#7

Sheesh, it takes anywhere from 5 to 56 changes for me - but eventually it does break!

#8

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.

#9

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.

#10

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.

1 Like
#11

This topic was automatically closed after 14 days. New replies are no longer allowed.