My first video aimed at other Bubble plugin developers where I discuss some issues I’ve had with the plugin builder when managing complex plugin development (e.g., List Shifter, Calendar Grid Pro). At the moment, these issues are resolved, and here I show how I develop complex elements in a “development” plugin and then copy them to the the “public” version of the plugin when it’s time to publish a new version.
Explains how the Bubble editor understands a plugin element’s unique ID and how to change that so that new versions of an element created in this way are seen as “the same” element. Using Synchronize with GitHub, we can reveal and change these IDs.
At the end, I explain a recent plugin editor change (“Fix plugin GitHub sync to not rely on case-sensitive folder names”) and the problem that it solves.
Fellow devs, let me know if there are other topics you’d like to see me cover in future.
Happy Valentines Day, lovers.
Oh thanks for that one! That video sprouted an idea. What if I had two plugins, one being the copy of the other? Would their actions collide or trigger each other somehow?
So I tested by cloning a plugin, modifying its code and running both in the same page.
This meant one plugin element’s action being:
And the other:
So they’re equal apart of the name. Guess what happened? They didn’t interfered with each other. Seems like they’re properly compartmentalized by the plugin (actual plugin) id. Running one’s action didn’t triggered another’s action
Gladly that’s the case…
Actually, @vini_brito, I think the solution (not well tested) IS to put the new plugin element INTO ITS OWN plugin environment. (The problem I experience is as follows: I desire to create Time Grid Pro – a variation on Calendar Grid Pro – that is contained WITHIN THE SAME plugin as CG Pro. In this way, subscribers to CG Pro will get TG Pro as a freebie. If I cannot do this, I can’t offer CG AND TG Pro as a bundle. The issue is commercial. If I don’t mind charging people twice – and, you might ask, why would I? – I do think the “problem” is solved by dropping TG Pro into its own plugin environment… And your own test points in this direction, of course.)
Eh, maybe I’ll just charge folks twice… But you know.
Yeah that makes total sense, making a bundle of commercial plugins when one is a derivative of the other.
In my case I actually created the derivative into another plugin that’s why I got that protective barrier. Thinking of it now I could’ve bundled them too, and would’ve ran into that issue…