Whenever I remove a custom block input (this might happen with other stuff too, this is just mainly what has been noticable) it shifts all of the inputs below it down in the actual block instance. E.g. this:
1: A
2: B
3: C
4: D
Delete 2 and add 5 and now it’s
1: A
3: B
4: C
5: D
This has messed stuff up without my knowledge before and has been really tricky to track down
I’ll look into feasibility of switching to storing this by the name of the input. I’ve also been wanting to switch to use column names for databases. I think 8bit has reported the DB problems before. Both currently use systems where the underlying input name is “Input 1”, “Input 2”, etc.
This was a trade-off made when every block with semi-complex inputs had its own hand-written frontend templates. These templates supporting anything other than a predefined input set would drastically increase development time. These days, dynamic custom block inputs are directly supported (as part of the new site/frontend). The static name/value trade-off doesn’t make a ton of sense anymore.
Just doing a switch over will be backwards incompatible, so this change would very likely require a general migration system that is able to map the positions to names and retroactively update things that way. It’s feasible but isn’t the simplest thing to do (especially in a safe way that won’t result in any data loss).
I think this old system/strategy is used across at least a half-dozen blocks (including the CB stub block), so a generalized migration to fix this issue with any and all of them, rather than dealing with it one at a time, would be ideal.