[BUG] Something strange in Material Design UI Components Plugin

Hi @emmanuel …or who wants to help me,
in my plugin Material Design UI Components, there is a bug that, in MDUI Text field element shows actions in workflows that are owned by other element (MDUI Date field).

below the real element actions

It’s a commercial plugin and I’m very grateful if you resolve it immediately for my customers and for me.

Thank you.

Did you try to republish the plugin?

Let me guess:

One plugin started as a copy of the other plugin, didn’t it?

1 Like

Yes …

republish don’t works …in fact I try in test app and then publishing is irrelevant

Have you got a solution !?

What happens when you do this is that Bubble creates a near-clone of the element.

By near, I mean that only its top-level ID changes.

All of the “copy”’s actions still have the same IDs as the actions in the original. So, a Bubble app will only see one set of actions.

This is — sort of — a bug.

But consider:

What if (like me) you manage your development in one plugin, but publish to the public in another? (By copy element from plugin private to plugin public.)

IF action ids were regenerated, now EVERYTHING has a new ID, not just the top level. So you’re super-hosed in that case. (More time the point I would be super-hosed as I just figured out how to work around this.)

Basically, the way Bubble implemented plugin element/action uniqueness is kind of dumb. But we seem stuck with it.

BTW, the only way you can see these IDs is to sync to GitHub. Now go look at your project. See those folder names? Those three-letter names are the UIDs for the various pieces of your plugin…

4 Likes

What we need is a right-click command for “regenerate action IDs” to allow us to take 1 element, copy/paste it, make it truly unique, and then modify that new element to be something truly new.

Another thing we need is for the top-level ID to be exposed so that one might take some version of an element, paste another version of it, reset that new one’s ID to be the old one and then remove the old one.

Now, you can work around this second part (my problem) in GitHub. Because you can do the copy/paste, sync to github, go edit the ID(s) of your elements locally or directly in GitHub, commit the changes, and sync back in Bubble plugin editor.

But there is no easy workaround for the first problem. We don’t know how the IDs are generated (can we just change the folder names to anything?) and to manually update all of those folder names is a chore (even if we did know what identifiers might be valid). It’s all very wonky.

[EDIT: I have bolded the top part because this would (1) fix OP @studio.purracchio’s problem without (2) eff-ing up those of us who manage development of our plugin elements/actions and deployment of those plugin elements/actions in different plugins. If Bubble just “fixes” plugin element Copy/Paste the way @studio.purracchio suggests, Bubble will break development for others.]

EDIT 2: Why would one manage plugin element/action development in one plugin but then publish by copying elements/actions to another plugin?

First, sometimes you HAVE to do this. For example, there is some code (specifically various asynchronous things like async/await) that cause Bubble’s minification (which uses Google’s closure-compiler) to fail.

To work around that, you have to turn minification off (by setting window.do_not_minify_plugin = true in the console).

But now, your plugin code is completely in-the-clear and isn’t compressed.

So, not wanting to publish your source code, you do your dev in one plugin, manually minify your code, test that it works and then copy that to your deployment plugin.

Second, it’s just better/safer: Before I embark on some new feature, I use Settings > Submit a New Version to create a backup of my plugin that I can always get back to. If I do something stupid (like delete an entire element or action inadvertently, screw up the code entirely, etc., etc.), I can always get back to where I was. As development proceeds, I might make some changes that I later decide were bad and want to just abandon that.

One can and should to this frequently. HOWEVER, one wouldn’t want one’s PUBLISHED version of a plugin to be full of weird versions. And you certainly wouldn’t want to have a version out there where someone is using some feature that you later go and destroy.

Yadda, yadda, yadda. And yes, one could do change management entirely via GitHub, but the integration here is pretty basic and it’s much easier to edit code locally and paste it where it needs to go in the plugin editor. And not all features can be done locally – e.g., you cannot create a new action for an element plugin entirely on your local machine because you must build its interface in the plugin editor.

Speaking of the action builder: I want to say, “Why oh why can’t we copy and paste an element action?” Some of my action interfaces are very large and – just like we want to take an entire sophisticated plugin element and make something new from it – I often find I want to take a sophisticated element action, copy it, and start from there. (I’m not talking about the code for it – I’m talking about the interface definition.) … But no, we can’t do that. So, we have to build the damn thing over. This may take HOURS.

(Same goes for FIELDS: why can’t I just copy and paste a field? I get that I’ll need to change the field’s name, but man copy/paste would be SO much easier than recreating this manually OVER AND OVER AND OVER again:

We might be tempted to try and do it locally, but we do not know what is safe to do. (e.g., we do not know what to name our action’s folder… we could (1) create a new action (2) sync to GitHub (3) copy the contents of the source action to the new “stub” folder and (4) commit and resync… but it’s not clear to me that this is entirely safe to do. Basically we keep coming back to this issue of the unique IDs of the plugin components – where they come from, where they must be unique, where they might appear in other parts of our plugin.

As I’ve experimented with all of this, I’ve found it very easy to either break a plugin or

All of this is a very long way of saying: It is no surprise that we see precious few plugins that actually DO anything, because the tools for creating such software are rather limited.

3 Likes

BTW, most of the preceding is also true of plugin Actions (not to be confused with the “actions” on a plugin Element) but Actions only have the “top-level ID” problem as they don’t have subcomponents.

I think I’ve just resolve the problem. Your help was very fundamental !
I’ve just change IDs copied by element cloning in github repo.
TYSM !

I’m interested to know what you did exactly… ?

  1. Clone git repo in my computer
  2. Remembering which element I had copied, I’ve search duplicated IDs of element’s actions.
  3. Found it, I’ve simply change the 3 chars IDs with other 3 chars without some logic

Perfectly works

1 Like

Well, you might find if you build on it more that new element actions may show up in strange places (same might go for fields), but doing this doesn’t seem to break anything as long as the “customized” IDs remain unique. :man_shrugging:

@studio.purracchio i think there is a bug. When loading the page, i show “group A”, with MD-text inputs. i show the group (show “group A”, pause before next action, set the selection menu options, and the set input value… clicking the input displays my options for the selection menu… i Then Hide “group A” and show “group B” which also contain MD-Text inputs for step 2 of the Form. I then Hide “group B” and show “Group A” (same wf as before… show Group A, pause before next action, Set selection menu options, set input value value. Click on the input doesnt display the options of the menu this time around… it either displays and disappears within milliseconds, or doesnt display at all… if i reload the page and try again… everything above repeats… so basically can only display the dropdown once… after that i need to reload the page to display dropdown options.

@studio.purracchio https://www.loom.com/share/bf3378307983405ea382f5dbd80bf0ac

@3brotherssupply
Next time choose right topic …Material Design UI Components - [Ver. 2.0.2] - Purracchio Andrea