I have been able to successfully rework the skin and hg issues without too much difficulty--at least to my satisfatcion. It was a difficult compromise between simplicity and flexibility, but I feel good about the end result.
First I created a much simplified BOLTgetlink function which takes a "$start, $last" parameter (as well as less often used $myArray and $path) and use this for skins, styles, and zones. The process it looks for is this: page: alpha,beta,gamma start.alpha.beta.gamma.last.skinname start.alpha.beta.last.skinname start.alpha.last.skinname start.last.skinname start.alpha.beta.gamma.last start.alpha.beta.last start.alpha.last start.last For a skin, start and last would be code and skin. On a style code and style. On a zone, like side it would be '' and side. This allows you to set up custom skin zones this way: alpha.beta.gamma.side.skinname This may not seem quite so logical (I very much appreciated Marcos for helping me to think this through, even if it ended up a different conclusion), but it should be consistent as virtually everything hierarchical runs this routine. To get a list of skin pages available, just do: [(search type=skinname)] and it should pull everything up, whether skin,style,zone, or template. If someone wanted to modify how the getlink function works, there is also now a hook in the core for a myBOLTgetlink() function which can be fairly easily modified from the core to some different order of search. Templates remain unchange. Just for the documentation here is how templates are currently searched (and fmt's by the way): 1) if an action page, it looks on the action paqe for #template 2) it looks on the current page for #template 3) it looks for template.templatename.skinname 4) it looks for template.templatename There is no hierarchical activity in templates/fmts. And currenty there is no hook in the core for an alternate template selection routine, but the latter could be easily added if desired. Just make the request. Simultaneously, I changed how skins are installed. When your skin is set to say "black", BoltWire checks to make sure code.skin.black exists in the wiki. If not found it goes to farm/skins/black and copies over every page in the folder automatically, except those ending in extensions: html, css, jpg, gif, png, db, htaccess, & txt. This list is hardcoded currently, but could be made configurable. You do not need any install list. To upgrade a skin, you simply delete code.skin.black, and all skin pages are overwritten. Existing files are overwritten without warning, so be careful with this upgrade process. And you definitely want to check out your skins first to see if it might overwrite any existing files you are concerned about. Well, it's simple, fast, and the code is clean and much improved. Marcos, if you want me to customize the getlink script for you, let me know and I can do it. I think for most of the rest of us (unless you are using zone.skin* pages) we should not notice any change with this release. And you now have the advantage of hierarchical custom skin and style pages, which is new. And best of all, everything is consistent. Another big step on the road to 3.xx. Cheers, Dan P.S. I decided against changing the skin installation routine because this current approach makes it very easy to work with skins. Just one zip and you're done. And it keeps all your graphics, html, css, etc, all together. Let me know if you notice any problems with the new changes... --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "BoltWire" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/boltwire?hl=en -~----------~----~----~----~------~----~------~--~---
