123
Senior Member
This post is a response to etc6849's question in another thread (that has gone waaaay off topic).
FACT: If you create a backup (manually) and restore it, all custom Selectors and Controls are lost.
SOLUTION: If you modify or add stuff like Themes, Selectors, or Controls to the Plugins Module, export the Plugins module! Afterwards, you can import it to restore everything correctly.
NOTE:
What's curious is that the backup file does contain all customizations in the Plugins Module. You can confirm this by opening the backup file with an editor. However, Premise only restores the 'standard-issue' Selectors and Controls and ignores the customizations.
Why does it do that? Here's my theory:
Premise loads the Modules in the order they are listed in Builder's Explorer window (that's a fact). The order is significant. If Module A defines a new class called Widget, it must come before any other Modules (B, C, D, etc) that attempt to use Widgets. Premise must see a class's definition before it can use it.
What if you reversed the order? What if a Module A comes after Module B? Module B attempts to use Widgets but they haven't been defined yet. Premise can't reconcile the orphaned class so it ignores it or, in the case of restoring a backup, discards it.
The AutomationBrowser and Plugins Modules work hand-in-hand. These Modules tend to come first. When restoring Plugins, Premise finds custom Controls and Selectors that point to classes that are defined yet (i.e. in Modules that come later) ... and discards them.
Or it's just a big fat bug ...
FACT: If you create a backup (manually) and restore it, all custom Selectors and Controls are lost.
SOLUTION: If you modify or add stuff like Themes, Selectors, or Controls to the Plugins Module, export the Plugins module! Afterwards, you can import it to restore everything correctly.
NOTE:
What's curious is that the backup file does contain all customizations in the Plugins Module. You can confirm this by opening the backup file with an editor. However, Premise only restores the 'standard-issue' Selectors and Controls and ignores the customizations.
Why does it do that? Here's my theory:
Premise loads the Modules in the order they are listed in Builder's Explorer window (that's a fact). The order is significant. If Module A defines a new class called Widget, it must come before any other Modules (B, C, D, etc) that attempt to use Widgets. Premise must see a class's definition before it can use it.
What if you reversed the order? What if a Module A comes after Module B? Module B attempts to use Widgets but they haven't been defined yet. Premise can't reconcile the orphaned class so it ignores it or, in the case of restoring a backup, discards it.
The AutomationBrowser and Plugins Modules work hand-in-hand. These Modules tend to come first. When restoring Plugins, Premise finds custom Controls and Selectors that point to classes that are defined yet (i.e. in Modules that come later) ... and discards them.
Or it's just a big fat bug ...