[quote name=‘johnbol1’]I know this is a little off topic but do you no longer get the problem regarding email already existing?
John[/quote]
This was fixed with the choose user functionality - Sno
With this new upcoming version are you guys finally going to make a cart that doesn’t “break” everybody’s custom or customized templates with every upgrade?
The amount of time and money wasted every time every customer upgrades is substantial; especially when you operate several sites. This needs to be addressed!
And “no” this is not always caused by poorly written code. All of our CS-Cart templates are coded to be 100% CS-Cart compliant and yet we still have issues with every upgrade and every template.
To my knowledge CS-Cart is the only cart that I’m aware of that breaks everyone’s custom or customized templates with every update which is something potential customers should know about.
[quote name=‘mayanetwork’]
To my knowledge CS-Cart is the only cart that I’m aware of that breaks everyone’s custom or customized templates with every update[/QUOTE]
In part because all software related (php, Jquery, apache,smarty, javascript, css, browsers, etc. ) evolve and simple there is no way to free cs-cart from them.
Separation between code and presentation could be also improved. Hooks could be improved.
[quote name=‘mayanetwork’]With this new upcoming version are you guys finally going to make a cart that doesn’t “break” everybody’s custom or customized templates with every upgrade?
The amount of time and money wasted every time every customer upgrades is substantial; especially when you operate several sites. This needs to be addressed!
And “no” this is not always caused by poorly written code. All of our CS-Cart templates are coded to be 100% CS-Cart compliant and yet we still have issues with every upgrade and every template.
To my knowledge CS-Cart is the only cart that I’m aware of that breaks everyone’s custom or customized templates with every update which is something potential customers should know about.[/QUOTE]
Paul, you should become the 1st template designer (as far as I know) that actually incorporates the “My_Changes” Addon (aka:hooks method) into your template offering. Beyond a shadow of a doubt, this would also easily justify paying an increased price for templates (at least for anyone with a drop of intuition)! 
I believe Paul’s primary issue is that even if someone creates a completely custom template (call it my_ugly_skin), when it contains a file of the same name as one that was part of the upgrade, the file will be overwritten and it will create an upgrade conflict.
An option for the developer would be to always prefix their filenames like us_product_data.tpl (ugly_skin product_data template). This would avoid the upgrade overwriting any of your files. But most “customizations” are really not new development. They are modifications to existing skins and I would think the developer would then want to see fixes/changes in the templates.
Developers could get a lot further by using their own uniquely named css files (included via hooks) that controlled the real styling elements. Since for the most part, the layouts are basically the same old multi-panel top-central-bottom style of layout.
It would not be too difficult for the upgrade process to verify that a skin is in the var/skins_repository directory structure before it applies any changes to the templates.
However, this is just going to cause more subtle problems like a missing variable that was added to a new template to support some new functionality or that fixes a bug in existing functionality.
The template system was a “good idea” to try and get separation between the business layer and the presentation layer. Unfortunately it was not implemented in that manner. There is more business logic in the templates than there is control of presentation (just try counting the if statements). Templates are used as logic subroutines that utilize global varaibles and then set ‘capture’ values which become global variables to the caller (since there’s no way for a template to return a value to be used)… It’s kind of a mess.
[quote name=‘tbirnseth’]I believe Paul’s primary issue is that even if someone creates a completely custom template (call it my_ugly_skin), when it contains a file of the same name as one that was part of the upgrade, the file will be overwritten and it will create an upgrade conflict.
An option for the developer would be to always prefix their filenames like us_product_data.tpl (ugly_skin product_data template). This would avoid the upgrade overwriting any of your files. But most “customizations” are really not new development. They are modifications to existing skins and I would think the developer would then want to see fixes/changes in the templates.
Developers could get a lot further by using their own uniquely named css files (included via hooks) that controlled the real styling elements. Since for the most part, the layouts are basically the same old multi-panel top-central-bottom style of layout.
It would not be too difficult for the upgrade process to verify that a skin is in the var/skins_repository directory structure before it applies any changes to the templates.
However, this is just going to cause more subtle problems like a missing variable that was added to a new template to support some new functionality or that fixes a bug in existing functionality.
The template system was a “good idea” to try and get separation between the business layer and the presentation layer. Unfortunately it was not implemented in that manner. There is more business logic in the templates than there is control of presentation (just try counting the if statements). Templates are used as logic subroutines that utilize global varaibles and then set ‘capture’ values which become global variables to the caller (since there’s no way for a template to return a value to be used)… It’s kind of a mess.[/QUOTE]
tbirnseth I agree with you…
Not sure if this helps but there is a software ( XsitePro2 ) that is able to change the template in a simpler manner. Would like to see cs cart template and update system much easier to update. Something like in XsitePro2. Cs Cart was able to change the blocks system to what is now which I like much better maybe they can do the same for updates and Templates. Less mess for Updates … 