Hi Guys,
Due to a new responsive theme that is going to be default in v4.2.1 we have created instructions on how to modify your add-ons so that they can support both Basic & Responsive themes.
Here are the instructions: http://docs.cs-cart…responsive.html
Please take a look at them and try to update your add-ons for the responsive theme.
If you have any questions, please feel free to post them here. Your feedback is greatly appreciated.
After a short testing we will e-mail these instructions to all CS-Cart Marketplace developers.
Thanks for the update. It's really useful information.
So css properties for the admin templates will not be changing? I.e. no more changes for 'class=fieldset' to 'class=control-group', etc. I.e. class=“control-group” remains that and will NOT become class=“ty-control-group__label”.
Is this a temporary situation? I.e. will responsive methods become the norm?
Should we assume that skins_repository/responsive will become skins_repository/basic in the future?
Are there any thoughts about enabling the built-in template editor to be able to edit admin templates? I.e. mail/templates/addon/[MYADDON] templates?
This advance notification is greatly appreciated.
Hi Tony,
[quote name='tbirnseth' timestamp='1400097076' post='183547']
So css properties for the admin templates will not be changing? I.e. no more changes for 'class=fieldset' to 'class=control-group', etc. I.e. class=“control-group” remains that and will NOT become class=“ty-control-group__label”.
[/quote]
That's right we do not plan any changes in Backend styles & templates.
[quote name='tbirnseth' timestamp='1400097076' post='183547']
Is this a temporary situation? I.e. will responsive methods become the norm?
[/quote]
I'm not sure that I understood you correctly.
If you are talking about instructions - No, this is a permanent solution because in future we are going to support only responsive theme. The basic will be deprecated sooner or later. So all the add-ons should be updated to support Responsive theme.
[quote name='tbirnseth' timestamp='1400097076' post='183547']
Should we assume that skins_repository/responsive will become skins_repository/basic in the future?
[/quote]
The Resposnive theme will become the default one in 4.2.1. But we won't rename “responsive” to “basic” - because add-on templates for storefront basic theme could be broken in Responsive theme.
So we will maintain both themes “basic” and “responsive” in 4.2.x.
[quote name='tbirnseth' timestamp='1400097076' post='183547']
Are there any thoughts about enabling the built-in template editor to be able to edit admin templates? I.e. mail/templates/addon/[MYADDON] templates?
[/quote]
I do not see any reason why admin should modify admin templates.
[quote name=‘imac’ timestamp=‘1400165554’ post=‘183607’]
I do not see any reason why admin should modify admin templates.
[/quote]
The Dashboard: It required editing in v3 and it requires editing in v4. The at-a-glance reporting on inventory was lacking in v3 and it’s worse in v4. There is more to be displayed than “Total Inventory” or “Total In Stock” or “Total Out of Stock”. In fact there is all of this:
In Stock Active, In Stock Hidden, In Stock Disabled, Out of Stock Active, Out of Stock Hidden, Out of Stock Disabled, Total Active, Total Hidden, Total Disabled.
Adding those values require template changes to skins/basic/admin/views/index.tpl in v3
Formatting the required changes for v4 would be easier with an Admin Template editor.
v3:
[quote]
So we will maintain both themes “basic” and “responsive” in 4.2.x.
[/quote]
So the answer is that for some undetermined period of time, 'basic' will remain along side 'responsive'. Then, magically in the future (no date/version set), 'basic' is going to go away. But for all of 4.2, basic/responsive will co-exist.
[quote]
I do not see any reason why admin should modify admin templates.
[/quote]
Well, one reason is that addon developers provide things like email templates that are in the 'backend' directory (our auto_mail addon for example). I've had requests for a built-in editor for these templates. We provide samples as examples but those don't meet the needs of everyone and for some reason unbeknownst to me, they seem to want an internal editor.
Not all of us believe that the backend should be static and that the UI or functionality serves the needs of everyone as it's distributed. I.e. my company does mostly backend addons/customizations because it tends to be more stable and I don't have to jump every time your developers sneeze. I think it was a big mistake to make the back-end static from an addon developer point of view. Previously, when it was “installable”, one could customize something that an addon provided and NOT have it be overwritten in a future update of that addon that only fixed a php bug. Now that the templates are all static, this is no longer possible (without splitting source for distributed archives). It doubled my support costs.
[quote name=‘tbirnseth’ timestamp=‘1400178195’ post=‘183621’]
So the answer is that for some undetermined period of time, ‘basic’ will remain along side ‘responsive’. Then, magically in the future (no date/version set), ‘basic’ is going to go away. But for all of 4.2, basic/responsive will co-exist.
[/quote]
Correct.
“magically in the future” means 4.3.x 
[quote name=‘tbirnseth’ timestamp=‘1400178195’ post=‘183621’]
Well, one reason is that addon developers provide things like email templates that are in the ‘backend’ directory (our auto_mail addon for example). I’ve had requests for a built-in editor for these templates. We provide samples as examples but those don’t meet the needs of everyone and for some reason unbeknownst to me, they seem to want an internal editor.
Not all of us believe that the backend should be static and that the UI or functionality serves the needs of everyone as it’s distributed. I.e. my company does mostly backend addons/customizations because it tends to be more stable and I don’t have to jump every time your developers sneeze. I think it was a big mistake to make the back-end static from an addon developer point of view. Previously, when it was “installable”, one could customize something that an addon provided and NOT have it be overwritten in a future update of that addon that only fixed a php bug. Now that the templates are all static, this is no longer possible (without splitting source for distributed archives). It doubled my support costs.
[/quote]
[quote name=‘Magpie Don’ timestamp=‘1400168058’ post=‘183610’]
The Dashboard: It required editing in v3 and it requires editing in v4. The at-a-glance reporting on inventory was lacking in v3 and it’s worse in v4. There is more to be displayed than “Total Inventory” or “Total In Stock” or “Total Out of Stock”. In fact there is all of this:
In Stock Active, In Stock Hidden, In Stock Disabled, Out of Stock Active, Out of Stock Hidden, Out of Stock Disabled, Total Active, Total Hidden, Total Disabled.
Adding those values require template changes to skins/basic/admin/views/index.tpl in v3
Formatting the required changes for v4 would be easier with an Admin Template editor.
v3:
[/quote]
Guys, I am sure that such a feature should not be built in the default functionality of e-commerce software. We have add-ons - and this request is the perfect case to be implemented as an add-on.
Tony, as for upgrading add-ons, that is not a good example. If one is going to reinstall an add-on, it does not matter whether the templates are stored in the “var” or “design” folders, because after the installation all the files will be overwritten anyway.
[quote]
Tony, as for upgrading add-ons, that is not a good example. If one is going to reinstall an add-on, it does not matter whether the templates are stored in the “var” or “design” folders, because after the installation all the files will be overwritten anyway.
[/quote]
Extracting a new archive does NOT uninstall/install an addon (if it is installed and the customer uses the '+' UI button to extract a new archive, the 'install' process is skipped if the addon is already installed). Many addon versions are released with only changes to php files. For updates that have mandatory template changes, then I have the ability during the upgrade process to re-install a template from the var area if needed.
The point being that with admin templates no longer being “installed” they can never be removed by the software and an update to an addon will overwrite the static location. It is much less flexible.
My two-cents… Make addons for admin area (for all areas) be installable just like the client side and the way they used to work. If you want to keep the standard cs-cart templates as static, that's fine (but I think your addons should conform to the same methods as 3rd party). But the addons should have their templates/css/images removed at an uninstall and an install should overwrite anything that exists.
I can tell customers all day long and document my tail off that they should copy distributed templates to new names before making changes. But this seems to go on deaf ears and resorting to the install/uninstall model again for addons seems to be in the best interest of both customers and developers since it offers the greatest flexibility.
So just have var contain:
themes_repository/basic
themes_repository/responsive
admin_repository/basic
Only addons would use the admin_repository/basic area. Then we would only have css files, images and templates for installed addons, not everything under the planet in the design/backend directory. Or, (preferred in V5) as has been suggested before, have ALL addon content under a single addon directory structure.
Hmm, so now you're exporting newsletter subscriptions to mailchimp. Can you clarify whether you have an option for whether it should be a double-opt-in or not?
I guess this means I can take the subscription block out of my mailchimp addon.
Have you also added “segmentation information”? Or just the email address from a subscription block? Please provide more details since I have to figure out what to remove from my addon that's been around since V2 to avoid duplication and customer confusion.
Hi Tony,
First of all - this add-on is an alternative to newsletters add-on. i.e. they can not be used along with each other.
Email marketing add-on has a separate subscription block & store email in its own table in DB.
As for the double opt-in, yes it is implemented. Take a look at fn_em_subscribe_email function in func.php of the email_marketing add-on.
No segmentation information, just the plain list of subscribers.
[quote name='tbirnseth' timestamp='1404327511' post='186847']
Hmm, so now you're exporting newsletter subscriptions to mailchimp. Can you clarify whether you have an option for whether it should be a double-opt-in or not?
I guess this means I can take the subscription block out of my mailchimp addon.
Have you also added “segmentation information”? Or just the email address from a subscription block? Please provide more details since I have to figure out what to remove from my addon that's been around since V2 to avoid duplication and customer confusion.
[/quote]