Now, while it may have looked like a bug, made you jump like a bug, and most likely, pissed you off like a bug, it is actually far from one. It was more of a feature limitation, which we, to be honest, had expected, and had already started planning and working on the 2nd implementation, or limitless feature, but when this post appeared on the forum and after a few days of attempted "bug fixing" we came to realize it was this same limitation playing back on us. So after a lengthy discussion yesterday we have decided on how we are going to go forward. But before I get there, lets explain this "bug" to you, so you can better understand:

Each themelet has a themeletDetails.xml, and in this file we specify the options that are specific to a themelet concept. This can be colours, layout, logo options etc. With the current implementation, these are known as the themelet specific options. For this example lets assume that the Light Candy themelet has 20 options in its xml file and Vanilla has 5. Now when you activate Light Candy, the Configurator component sees those 20 options and stores them in the database with a source of themelet. Any changes that are made are saved in the database as usual.

Now you decide to change to the Vanilla themelet: what happens is Configurator backs up those 20 specific options for the Light Candy themelet (including any changes that you might have made to those 20 specific items), it then removes those 20 options from the database, fills them with the defaults in the morphDetails.xml and then checks the Vanilla themelet xml file. If there are any settings stored in this file, and for the purposes of our example there are 5, it then overwrites those 5 specific default values in the database with the values that are specified in the file

I hope that I am making sense here - it's not easy taking it from tech to normal :)

The same process above applies to the 5 options set in Vanilla. But, where the issue is coming in, is if you make changes to any of the options "outside" of those 5 or 20 options. Currently none of those settings would be saved as a themelet specific item. But this again is fine, if the options that you change are not in either of the themelet xml files. However the problem comes in when you have a setting that is "themelet specific" in one xml file and not in the other, and this is where you are seeing the "bug".

Now, we discussed this whole process at length and we have some ideas that we are going to implement in the next major release. You would think that this would be the stable release that is 99.9% ready, but lets be honest, due to the amount of testing that it would require to ensure that there are no bugs with adding this new feature, and the external testing required, would hold us back from going stable, so it will go in the next major release after stable. But never fear, we are able to implement part of this feature now in the upcoming stable release. What this addition will do, is make almost every setting within Configurator a "themelet specific" option as you would have expected it to.

Now, you will see I mentioned "almost every setting" above, but in all fairness, some settings are not really themelet specific, i.e. your logo, your tagline, footer text, etc and these options should remain "locked" when switching a themelet. So those setting will remain "user specific" and will not change based on the themelet. We will be adding an extra feature of this added feature in the major release I mentioned above, where you could specify what you want to remain locked/unlocked, as well as the ability to lock/unlock items that have been locked by default.

Basically how it works, is you will see a little lock, grayed out means that the item is not locked, and the colourful lock shows that the item is locked. Those options will not change regardless of the themelet, and can only be removed by unlocking, or resetting your Configurator settings.