I just wanted to document a bit of jAlbum core behavior that can easily catch the unwary skin developer off-guard.
Let's say that, for whatever reason, you want to change the value of a skin variable while processing init.bsh. For example, the skin settings panel has a useBorder variable that is true by default. But because of some other choices that are possible, you want to force this to be false in some situation. So, in init.bsh, you might have:
This change is effective when you process your common.css file (or any other CSS templates). It is sometimes effective when you process your index.htt file (or any other htt templates, including any included files).
However, the change in the variable will be ignored in a predir.bsh, postdir.bsh, or finally.bsh file - these will pick up the original, unaltered skin variable, ignoring the change made in init.bsh.
And now for the really fun part. If your skin includes a predir.bsh at all, even if it does absolutely nothing, the variable change will not be honored in your index.htt file. I don't have a clue about why this is the case, but I can demonstrate it if forced to.
The moral of the story is that if you want to override the value of some skin setting chosen by the user, you can safely replace it if the only place it's going to be used is in a CSS template. Otherwise, create a new variable and use that everywhere else.
or if you prefer:
useBorderFinal = somecondition ? false : useBorder;
(then call useBorderFinal in all subsequent processing)
I am not suggesting that this should be fixed in the jAlbum core. I'm aware that it's a very messy problem to address, given the multi-threading that the core does. It's a rare situation, and easily avoided by a skin developer. But if you don't know what's happening, it can make you a little crazy.