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.