Well, I’ve kind of gotten it sorted a bit: The integration with GitHub that was introduced a while ago helps a bit. I think, going forward from the current version, I’ll be able to prevent the plugin from breaking.
(For any other plugin devs who might be listening: All of the parts of a plugin are stored in a folder hierarchy where each folder has a 3-character ID. So, for example, under “elements” you’ll find a folder for each plugin Element. The name of those folders are the identifiers for the Elements.
So, if you manage your plugin development like I do, where you have one plugin for your private development version and then your public (either open source or commercial licensed) version in another plugin, you run into the following problem:
When it comes time to copy your private element, action or whatever to the public version, pasting the new element into the public version results in a NEAR-clone of that item. While all sub-folders of the copied element are the same and will have their “old” IDs (their folder names remain unchanged), the top-level folder gets a new name.
And so, this new copy of the plugin has a different top-level ID from the old one. If you then delete the old plugin and publish, apps that use that element cannot make the connection between the old version and the new version, resulting in “missing element”.
Of course, users can fix this by right clicking on those missing elements and “replace with another element”, but this is a real pain.
The solution seems to be to – before publishing – sync the updated plugin package to GitHub and change that top-level directory name back to the old identifier and commit the change. Back in the plugin package, synchronize from GitHub. Now the “new” version of the element can be seen by Bubble apps as the same one it was previously.
Bubble’s method of handling the identity of various plugin components makes certain things impossible (or at least very difficult to achieve) without breaking things. (One example of this is you can’t - in the same plugin package - copy and paste an element to create two variations on that plugin element. The new element will have a unique top-level ID, but all of its actions retain the original action IDs, causing them to be confused with the actions of the original plugin and leading to unexpected behavior. This would also seem to be the explanation for why the plugin editor doesn’t have copy-paste for individual actions of action fields. It’s all kind of poorly implemented.)