Hi there. I’ve created many online stores for clients, but I’m new to cs-cart. One of my pet peeves on a previous cart I used was that every time I did an upgrade, my design was shot to hell. If I kept all my old template files, some of the new features didn’t show up, and some of my old features stopped working. If I let the upgrade modify my templates, my design got messed up. I’d have to go in and resolve all the differences. So much for separation of presentation and logic.
So, I liked the idea of cs-cart hooks. Initially. However, my designs are extensive, and it’s becoming a lot of work trying to “overwrite” everything. There’s no really good base skeleton design to start with. Austere looked promising but every freakin’ class has colors and styles that need to be overwritten. More importantly, want to rewrite several .tpl files and some of the default sideboxes like product filters, etc where there doesn’t seem to be hooks. The more I work with it, the more design and layout limitations I’m running into with the hooks method.
Sooo, now I’m leaning towards creating a new skin (copying austere as a basis for the tpl files, unless there’s an even leaner alternative), but I wanted to ask the veterans here what this will mean in terms of upgrades. Will I have to re-tweak my template files? I see there are parties that provide skins, so I’m thinking it must be an acceptable alternative to using hooks???
Thanks for any wisdom you can provide!! 
Yep, that describes exactly the state of affairs with CS-Cart skin design. If you want a future-proof skin, you’re limited by the hook system and the few areas in which they appear. Even then, hooks have been known to “shift” among .tpl files between versions. This is probably the best approach if you are designing for a client and not your employer.
If you want full design control, create an entirely new skin and commit yourself to manual updates every few months.
A skeleton “starter” skin has been requested many times without response.
One approach I’ve been toying with is to create the skin as an add-on. The add-on “skin” would contain a set of hook overrides specifically written for a stock skin (ex. “basic”) and would include a number of preset themes configurable via the Add-on’s edit screen (changing background color, font, etc.). That would allow a user to quickly change the entire look of the skin without tweaking CSS or going through the skin install process for each variation. The skin add-on could also be packaged with custom functionality (menu systems, new block typs, etc).
good luck,
Glen
Or simply enclose all of main.tpl inside a
{hook name=“custom_skin:main”
all the old main.tpl code
{/hook}
Then just start from scratch if you want.