Plugin Elements failing when color-fields are unconfigured (fixed as of 21:40 UTC)

Just a heads up - Over the past few hours i received a few e-mails from plugin-users having issues with their applications. Basically they complain about specific widgets not being rendered at all.

It turned out to be caused by unconfigured color fields (even though they are Optional). I figured i should share the heads-up in this forum.

Here’s what to look for when you encounter failing elements:

The workaround solution would be to configure the “empty” color-values.

For the code-nerds amongst us: when e =null, bubble crashes on initializing your plugin element

Note that i reported the issue.

4 Likes

Thank you for this. Whatever update was just pushed on the backend has fundamentally broken the Tabulator plugin that we’re relying on for our app. Please @bubble roll this back!

This is most likely because of V21 update. but the problems occure in V20 too. It is bad practice to change the base version because of an update…
set our business offline for 6 hours without the possibility to rollback!

1 Like

FYI: Bubble just reported to me that they fixed the issue!

Yeah, they did fix the issue, but this was causing problems with Calendar Grid Pro as well. (There are LOTS of color fields in CG Pro Setup and they do not – nor should – have predefined color values.)

Aside: I grow tired to Bubble changes breaking various aspects of the plugins, but we are at their mercy.

2 Likes

Similar issue fixed here

2 Likes

I love how you pointed out issues with this about a month ago, @jonah.deleseleuc and today of course it still broke when deployed (also how the color picker in plugin interfaces is apparently an “edge case”). :man_shrugging:

3 Likes

i would have less of a problem if it would not affect live version. this is a no go!

2 Likes

@emmanuel Bubble has repeatedly broken live apps with updates like this (another one I remember is an update to repeating group behavior which nuked many people’s repeating groups).

As an agency that recommends and implements Bubble for clients, it’s total chaos when an update like this takes down apps and there’s no way to roll it back.

You guys are generally pretty good about rolling back breaking changes, but in that gap between the problem being identified by the community and the official rollback, your customers are left making difficult choices like, “Should I spend 2 hours clicking around to fix this app, or wait for Bubble to notice it’s broken?”

Please consider a way for us to manually rollback updates :pray:

1 Like

I could have predicted this months ago.

I was working on a toast plug-in with many many color inputs. I already saw this was a blind spot for bubble because depending on the situation bubble gives a HEX or RGBA from color inputs. And it seems pretty random too, I can’t tell when it’s hex or RGBA so I programmed my plugins to understand both of them (and also what happens when it’s null)

I believe most plugins probably haven’t taken that into consideration. So beware of older plugins.

It would be cool if there was a standard set in place and that it was actually followed to the tee. That way, when someone on the team pushes an update, they are forced to take into consideration things they aren’t working on (I.e plug-in editor). This is probably due to a lack of communication in between both teams (if there are in fact two teams)

Anyways, prepare for more breaking changes if no standard is put in place

Edit: I just want to say that the bubble team does great work and I really appreciate it - but at the same time, it’s frustrating that plug-ins are seen as “edge case” from the perspective of the bubble team, which leads to hurtful situations like this one

1 Like

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