How to customize 2.0

[COLOR=“Red”]Update[/COLOR] (7/9/09)



I did some work for a client that lent itself very nicely to this addon. So, in the spirt of community I created a new version that is free for use. It is located at: [url]http://www.ez-ms.com/local_addon_v2.tgz[/url]



New features are:


  1. Can now specify a CSS directory within the addon directory structure so all your css is in one nice neat place. By default, it is set to ‘css’ which would look for css files in skins/customer/addons/local/css The default stylesheet that will be loaded after the system styles.css is called local_styles.css. It is present with some comments but otherwise empty.


  2. You can now have the system load a stylesheet that is specific to the controller being viewed. I.e. if you want to customize the checkout page then you’d have a stylesheet present called:

    skins/customer/addons/local/css/checkout.css

    If you want to override the categories styles then you’d have:

    skins/customer/addons/local/css/categories.css

    Note that these “controller specific stylesheets” are loaded AFTER both the system stylesheets and the local_styles.css files. Hence they can be VERY specific to a page.



    These extensions were pretty quick and easy to do and I think they add a lot of flexibility to the addon enabling you to make local modifications and a custom look & feel without modifying standard template files. Hence, when you upgrade to 2.0.whatever you won’t have any conflicts.



    Have fun!



    [COLOR=“Red”]End of Update[/COLOR]



    After asking the help-desk (response: “sorry, 2.0 is not supported by the help-desk”) and posing questions here on the forum (response from developers: nothing), I decided to just spend the time to read the code and figure it out.



    Maybe many of you know how to do this already. I didn’t. I have added my own addons to the system that operate in the background, but had not looked at how to extend/modify the standard skins without creating tons of upgrade conflicts.



    3/19/09: Found one small but where I was missing a ‘php’ after a ‘


    Below is the README file from the addon I’m offering. I have requested that this be embedded into the standard cart so that it is available to anyone, but no one ever hears back so will just assume it will not be.



    I’m happy to try and answer questions you might have, but I think the README I’ve put together is pretty self-explanatory. It is not complicated at all once you get the hang of how it is intended to work. And the good news is that it actually works! Yipee!



    Hope this helps someone save some time. Sure doesn’t seem like customers should be having to describe how the system works so it can be used as intended!!! But I guess if someone else is willing to do my job for me, I’d probably just let them do it.



    tony



    README.txt file located in [doc_root]/skins/[active_skin]/customer/addons/local directory.

    ---------------------

    This information is intended to describe how you can create local customizations

    to your user-interface through the use of ‘addons’.



    A zip file of the ‘local’ addon can be acquired at [url]http://www.ez-ms.com/local.addon.zip[/url]. Unzip

    this on your server or into your ftp environment, change the ownerships and permissions to match your

    systems needs and then move the

    [doc_root]/addons/local and [doc_root]/var/skins_repository/base/customer/addons/local

    path into your cart document root. New skins will automatically get the new addon.



    For existing skins, copy

    [doc_root]/var/skins_repository/base/customer/addons/local

    to your

    [doc_root]/skins/[active_skin]/customer/addons

    directory.



    Next, go to the Administration/addons page and “install” the “Local Configuration” addon. This will

    enable the cart to pick up your changes.



    I have only done the ‘customer’ skins area. The ‘admin’ area works the same and once the “Local Configuration” addon is installed, you can add your local addons there too.



    Description of how it works:

    ----------------------------



    Most templates for main pages have custom template functions named ‘hook’ embedded within

    the standard cart pages. I.e. you will see things in the template files like either:

    {hook name=“page:type”}{/hook}

    OR

    {hook name=“page:type”}

    Some standard content

    {/hook}



    where ‘page’ is usually the name of the page (or context) without suffix (like ‘index’) and the ‘type’

    is an identifier to tell the system what hook to look for related to that page. Html within

    the tag will either be “overridden”, “prepended” or “appended” based on the name of the

    ‘hook’ template.



    As a convenience, EZ Merchant Solutions (http://www.ez-ms.com) has created a freely distributable addon

    called ‘local’. Adding hook templates to the ‘local’ addon will allow you to customize your site

    without generating conflicts during an upgrade. This is the recommended way to extend or replace

    the cart’s look and feel.



    In addition to the hook ‘name’ (I.e. index:bottom), hooks can be specified to either

    prepend the “hook template” (bottom.pre.tpl), append the “hood template” (bottom.post.tpl) or to replace

    the standard content (bottom.override.tpl) with the contents of the “hook template”.



    Hence you specify your template (or calls to other templates) in the filename that matches the

    action you want the system to perform on your behalf.



    As an example, to replace the cart’s standard ‘bottom’ section (set of links and other formatting), you

    would create the file:

    skins/[active_skin]/customer/addons/local/hooks/index/bottom.override.tpl.

    This will tell the system to replace the content inside of the ‘hook’ template tag

    {hook name=“index:bottom”}

    Standard content

    {/hook}

    with the content contained within the bottom.override.tpl file.



    If you wanted to leave the standard content and simply prepend some graphics for your suppliers, partners,

    etc. You would name the file

    bottom.pre.tpl



    There are a few places where the standard cart is broken. I.e. the hook for index:styles is above the standard styles.css and vmenu.css links. This prevents one from simply redefining elements like color and background-color to new values to change the colors only of the standard templates. A bug report requesting it be moved has been submitted.



    You will have to experiment to determine what works best for you. A list of all the template hooks

    follows. Use the ones that best meet your needs.



    For your information, “basic” skin templates with 'hooks" are listed below.



    Hope this helps someone else not have to dig through the code to find out basic architecture information.



    Customer Templates with ‘hooks’:

    --------------------------------



./customer/index.tpl:{hook name="index:styles"}{/hook}
./customer/index.tpl:{hook name="index:footer"}{/hook}
./customer/main.tpl:{hook name="index:main_content"}
./customer/bottom.tpl:{hook name="index:bottom"}
./customer/views/orders/details.tpl:{hook name="orders:details_bullets"}
./customer/views/orders/details.tpl: {hook name="orders:info"}
./customer/views/orders/details.tpl:{hook name="orders:items_list_row"}
./customer/views/orders/details.tpl: {hook name="orders:product_info"}
./customer/views/orders/details.tpl:{hook name="orders:extra_list"}
./customer/views/orders/details.tpl:{hook name="orders:totals"}
./customer/views/orders/details.tpl: {hook name="orders:details"}
./customer/views/orders/details.tpl:{hook name="orders:confirmation"}
./customer/views/checkout/checkout.tpl: {hook name="checkout:form_data"}
./customer/views/checkout/checkout.tpl: {hook name="checkout:items_list_row"}
./customer/views/checkout/checkout.tpl: {hook name="checkout:product_info"}
./customer/views/checkout/checkout.tpl: {hook name="checkout:cart_content"}
./customer/views/checkout/checkout.tpl: {hook name="checkout:cart_item"}
./customer/views/checkout/components/checkout_totals.tpl: {hook name="checkout:payment_extra"}
./customer/views/checkout/components/checkout_totals.tpl: {hook name="checkout:payment_options"}
./customer/views/checkout/components/checkout_totals.tpl: {hook name="checkout:checkout_totals"}
./customer/views/checkout/components/shipping_rates.tpl: {hook name="checkout:shipping_rates"}
./customer/views/checkout/components/checkout_steps.tpl: {hook name="checkout:checkout_st
eps"}{/hook}
./customer/views/checkout/components/checkout_steps.tpl: {hook name="checkout:checkout_st
eps"}{/hook}
./customer/views/checkout/components/checkout_steps.tpl: {hook name="checkout:che
ckout_steps"}
./customer/views/checkout/components/shipping_estimation.tpl: {hook name="checkout:shipping_estimation
"}
./customer/views/checkout/components/cart_items.tpl: {hook name="checkout:form_data"}
./customer/views/checkout/components/cart_items.tpl:{hook name="checkout:items_list"}
./customer/views/checkout/components/cart_items.tpl: {hook name="checkout:product_info"}
./customer/views/checkout/components/cart_items.tpl:{hook name="checkout:extra_list"}
./customer/views/checkout/components/payment_methods.tpl: {hook name="checkout:payment_methods"}
./customer/views/checkout/components/cart_status.tpl: {hook name="index:cart_status"}
./customer/views/products/view.tpl: {hook name="products:view_details"}
./customer/views/products/view.tpl:{hook name="products:view_main_info"}{/hook}
./customer/views/products/view.tpl: {hook name="products:tabs_block"}{/hook}
./customer/views/products/components/buy_now.tpl:{hook name="products:prices_block"}
./customer/views/products/components/buy_now.tpl:{hook name="products:options_advanced"}
./customer/views/products/components/buy_now.tpl: {hook name="products:buttons_block"}
./customer/views/products/components/buy_now.tpl: {hook name="products:buy_now"}
./customer/views/products/components/products_small_list.tpl: {hook name="products:product_small_list"}
./customer/views/products/components/product_options.tpl:
./customer/views/products/components/product_options.tpl: {$vr.variant_name} {if $settings.General.display_options_modif
iers == "Y"}{hook name="products:options_modifiers"}{if $vr.modifier|floatval}({include file="common_templates/modifier.
tpl" mod_type=$vr.modifier_type mod_value=$vr.modifier display_sign=true}){/if}{/hook}{/if}

./customer/views/products/components/product_options.tpl: {if $settings.General.di
splay_options_modifiers == "Y"}{hook name="products:options_modifiers"}{if $vr.modifier|floatval}({include file="common_
templates/modifier.tpl" mod_type=$vr.modifier_type mod_value=$vr.modifier display_sign=true}){/if}{/hook}{/if}
./customer/views/products/components/product_options.tpl: pr_o[{$id}][{$po.option_id}]['v'][{$var.variant_
id}] = jQuery.entityDecode('{$var.variant_name|escape:javascript}'{if $settings.General.display_options_modifiers == 'Y'
}{hook name="products:options_modifiers_js"}{if $var.modifier|floatval}+' ({include file="common_templates/modifier.tpl"
mod_type=$var.modifier_type mod_value=$var.modifier display_sign=true})'{/if}{/hook}{/if});
./customer/views/products/components/product_options.tpl:{hook name="products:options_js"}{/hook}
./customer/views/products/components/one_product.tpl:{hook name="products:product_block"}
./customer/views/products/components/products_multicolumns.tpl: {hook name="products:product_multicolumns_list"}
./customer/views/products/components/products.tpl:{hook name="products:product_block"}
./customer/views/products/components/products_list.tpl: {hook name="products:product_list"}
./customer/views/search/results.tpl:{hook name="search::search_results"}
./customer/views/categories/view.tpl:{hook name="categories:view"}
./customer/views/profiles/update.tpl:{hook name="profiles:account_update"}
./customer/views/profiles/components/profiles_account.tpl:{hook name="profiles:account_info"}
./customer/views/pages/view.tpl: {hook name="pages:page_content"}
./customer/views/pages/view.tpl:{hook name="pages:page_extra"}
./customer/addons/news_and_emails/views/news/list.tpl: {hook name="news:list"}
./customer/addons/news_and_emails/views/news/view.tpl:{hook name="news:view"}
./customer/addons/gift_registry/views/events/update.tpl:{hook name="events:fields"}
./customer/addons/gift_registry/views/events/update.tpl: {hook name="events:update"}
./customer/addons/gift_registry/views/events/view.tpl:{hook name="events:view"}
./customer/addons/rma/views/rma/details.tpl: {hook name="orders:return_info"}
./customer/addons/rma/hooks/orders/details.post.tpl: {hook name="orders:product_details"}
./customer/addons/reward_points/views/reward_points/userlog.tpl: {hook name="reward_points:userlo
g"}
./customer/addons/required_products/hooks/products/buttons_block.override.tpl: {hook name="products:buy_now"}
./customer/addons/product_configurator/hooks/orders/items_list_row.override.tpl: {hook name="orde
rs:product_info"}
./customer/addons/product_configurator/hooks/orders/items_list_row.override.tpl:
{hook name="orders:product_info"}
./customer/addons/product_configurator/hooks/checkout/items_list.override.tpl: {hook name="products:options_mul
ticolumns"}
./customer/addons/product_configurator/hooks/checkout/items_list_row.override.tpl: {hook name="chec
kout:product_info"}
./customer/addons/form_builder/hooks/pages/page_content.override.tpl: {hook name="pages:page_content"}{/hook}
./customer/addons/tags/views/tags/summary.tpl: {hook name="tags:view"}
./customer/addons/wishlist/views/wishlist/view.tpl: {hook name="wishlist:items_list"}
./customer/addons/wishlist/views/wishlist/view.tpl: {hook name="wishlist:view"}
./customer/addons/gift_certificates/views/gift_certificates/update.tpl:
./customer/addons/gift_certificates/views/gift_certificates/update.tpl: {hook name="gift_certificates:buttons"}
./customer/addons/gift_certificates/hooks/orders/extra_list.pre.tpl: {hook name="orders:produ
ct_info"}
./customer/addons/gift_certificates/hooks/checkout/extra_list.post.tpl: {hook name="chec
kout:product_info"}{/hook}
./customer/addons/gift_certificates/hooks/checkout/cart_content.pre.tpl: {hook na
me="checkout:product_info"}
./customer/meta.tpl:{hook name="index:meta"}
./customer/blocks/my_account_bottombox.tpl:{hook name="profiles:my_account_menu"}
./customer/blocks/quick_help_bottombox.tpl: {hook name="index:quick_box"}
./customer/blocks/my_account.tpl:{hook name="profiles:my_account_menu"}
./customer/scripts/form_scripts.tpl:{hook name="index:scripts"}

Great addon. Thank you very much.



I have one question: How to make each page or a class of pages like a certain category pages a different theme? Like what Magento can do now. You can have different theme for different category or different product page in the same category.

I don’t know… Given that the CSS is fully customizable you could have a different header, colors, content, etc. based on which ‘hook’ is being applied. I’m sure there are hooks for category pages but you might have to do the ‘conditions’ in your own templates. But it would probably have to be well thought out and a pretty sizeable job.



Maybe a CS developer could better answer how to solve that particular problem. I’m sure there will be lots of requests for new or additional ‘hooks’. Kind of like unleashing the monster.



I’m not familiar with Magneto.

Yes, if the architecture is well designed, greatly increasing flexibility, then cs-cart will beat other carts for sure!

I find it very hard to customize

[quote name=‘Darius’]I find it very hard to customize[/QUOTE]



In what way? The changes you would normally make are simply kept in a place where they are out of the way of the upgrades.

[quote name=‘tbirnseth’]In what way? The changes you would normally make are simply kept in a place where they are out of the way of the upgrades.[/QUOTE]



I mean building custom design.



Previous shopping cart I was using (shop-script.com) also released new cart that I was unable to modify (still cant), transition from beta to real stable version was such long that I ran away to cs-cart.

[quote name=‘Darius’]I mean building custom design.



Previous shopping cart I was using (shop-script.com) also released new cart that I was unable to modify (still cant), transition from beta to real stable version was such long that I ran away to cs-cart.[/QUOTE]



If you can pose specific questions, be happy to try and help. The easiest way is to start with a template and then determine what you want to change. Then, make your changes in the local.addon area rather than the templates themselves. In this way, you keep out of the way of the upgrade.



For instance, my site (http://www.ez-ms.com) has all the changes within the local.addon. When I get an upgrade, I don’t have to resolve conflicts because there are none. That’s the point of using the ‘addon’ method.

tbirnseth



Could you explain a little more about the addon method. I was planning on making my changes to the template files just like in the 1.3.x templates. The modifications I am planning on making are pretty simple, but if there is a better method I would love to hear it.



Thank you,



Brandon

anyone out there willing to produce a nice template design based on version 2.0 ?

or is it too early to ask for ver 2.0 designers ?

In 2.0, there is a concept of “hooks”. These hooks allow information to be read from the hooks subdirectory within the customer template area (I.e. skins/basic/customer/addons/local/hooks).



So for instance, to replace the entire header area of the basic template you would have the file named:

skins/basic/customer/addons/local/hooks/index/main_content.override.tpl



This file will “override” what is in the standard template for that area. The code in the template itself (skins/basic/customer/main.tpl) looks like:

{hook name=“index:main_content”}

{include file="top.tpl"}

{/hook}

Note that the "name" in the hook is "index:main_content". This tells you the subdirectory and the filename base to use.

So essentially you are "overwriting" the contents of top.tpl (and the div that contains it) with your customized version.

Each hook has 3 different "modes" of operation. These are:
pre - Put the content ahead of the 'hook' content
post - Put the content after the 'hook' content
override - Replace the content of the 'hook'

This is represented by the filename used. I.e for the above:
main_content.pre.tpl would put it before
main_content.post.tpl would put it after
main_content.override.tpl would replace it.

Unfortunately right now, there's no way to identify where all the hooks are and which content is controlled via hooks (other than looking at the template code itself). I have suggested that the "Design Mode" be extended to highlight where on a page a hook is available (maybe green) and if an addon hook exists and to highlight each in a different color for pre, post or override. But this doesn't exist today. This would make it pretty clear as to which content can be changed without modifying the core templates and which can't.

Hope this helps clarify a bit further. The addon I provided simply enables the file structure to support the addition of local hooks. It does not alter anything as installed. But it does make it clearer how to enable local customizations.

tony

Hi tbirnseth



thanks for this very useful info you have posted - I am just getting into customising V2 and any help with this is much appreciated.



When you talk about making changes in the local.addon area, I take it you are referring to changes you might otherwise make to the .tpl files - thus avoiding issues when it comes to upgrading - right?



Is it right that this is how you manage significant changes to the content of pages - specifically adding new features/content that do not exist within the cart? I will be doing that, but currently I am looking at just changing the design/style of the default V2 template by editing the css files. It appears that the design can be substantially changed and improved simply by editing the css. Am I right in thinking that changes to the css will not affect future upgrades? or should css be modified using local.addon/hooks too?



Also, I see that certain changes to the content/layout of the pages can be made within the design section of the admin panel itself - choosing which built in blocks go on which pages, and where they go etc - these admin based changes will not affect upgrading either - is that correct?



As a newbie to customising a cart, but with a reasonable knowledge of html & css, it would be good to get some confirmation that I am thinking about this in the right way… particularly as there is no documentation on the subject.



thanks for your help

[quote name=‘spirt’]

When you talk about making changes in the local.addon area, I take it you are referring to changes you might otherwise make to the .tpl files - thus avoiding issues when it comes to upgrading - right?

[/QUOTE]



Correct


[quote name=‘spirt’]

Is it right that this is how you manage significant changes to the content of pages - specifically adding new features/content that do not exist within the cart? I will be doing that, but currently I am looking at just changing the design/style of the default V2 template by editing the css files. It appears that the design can be substantially changed and improved simply by editing the css. Am I right in thinking that changes to the css will not affect future upgrades?

[/QUOTE]



Yes, but rather than changing the actuall css files, you can use the hook:

index/styles.post.tpl.



I use this to change the coloring, add some border/background changes, etc. I.e. since this is a “cascading style sheet”, it’s easy to redefine things that are previously defined in the standard CS-cart stylesheets. However, I do this via a tag. I.e. my index/styles.post.tpl simply contains:






This allows me to have my own stylesheet that both overrides classes/properties in styles.css as well as includes my own javascript files.

[quote name='spirt']
Also, I see that certain changes to the content/layout of the pages can be made within the design section of the admin panel itself - choosing which built in blocks go on which pages, and where they go etc - these admin based changes will not affect upgrading either - is that correct?
[/QUOTE]

Well, I have two experiences there:
1) Theoretically, block changes are held in the database and they should therefore be independent of any upgrades.
2) But my actual experience (but this has been beta) is that my blocks have been destroyed on each upgrade. Right now, I can't upgrade from 2.0.1 to 2.0.2. It works great for the "out of the box" cart but seems to have problems with any degree of customization. But fully expect upgrade issues to get resolved. However, the current upgrade sql script (uc.sql) has blatent errors in it related to creating schemas with default values which are miss-typed. I wish there was better QA on this stuff. I spent many hours trying to resolve the errors.

[quote name='spirt']
As a newbie to customising a cart, but with a reasonable knowledge of html & css, it would be good to get some confirmation that I am thinking about this in the right way... particularly as there is no documentation on the subject.

thanks for your help[/QUOTE]

You're certainly on the right track. The goal of 2.0 is to be able to enable the main cart functionality and to have any customization (UI, feature/funcition, etc.) be customizable via the 'addon' methodology. One thing to keep in mind is that 'addons' have a priority associated with them. I.e. they are 'cascading' as well. So it's entirely possible that your changes to content could be overridden by an addon with higher priority. But this would usually occur within the checkout pages or other areas where the system 'addons' are more prevalent.

tony

Tony,



Thanks a lot for your quick and helpful reply!



RE what you said about overiding the main css with my own css file using index/styles.post.tpl. - please can you clarify for me whether editing the main css file is likely to generate upgrade problems or not.



You have given very clear instructions on how I can redefine styles which are in the main stylesheet using my own stylesheet, but if editing the main stylesheet does not cause upgrade problems, what would the advantage be in using the override method.



I only ask because I can see a disadvantage with the override method, and that is repetition of code which could slow things down (and from what I have read, anything that can be done to make the cart run as fast as possible is desirable).



By repetition of code, what I mean is that a given style is defined in the main stylesheet, and then the style is redined in my stylesheet which overrides the main one because of the cascading nature of css and the fact that the new stylesheet has the .post hook. - but both stylesheets are having to be downloaded and processed by the browser.



thanks again - your help is really appreciated.

My understanding is that ANY FILE IN THE STANDARD DISTRIBUTION is evaluated for conflicts. If conflicts occur, the standard file always wins unless it is updated AFTER THE UPGRADE COMPLETES and BEFORE the store is opened. Of course this is assuming you do not go through each conflict and resolve as part of the upgrade process.



But who has time for all of that? I certainly wouldn’t want my store closed while I’m fiddling around with trying to resolve conflicts or understand how changes in the standard cs-cart will affect my changes!



As far as repititon and performance goes… I doubt you can generate a css file that will show any degradation of browser performance. Remember that the CSS is:

  1. Cached in the broswer so it’s downloaded once unless it’s modified
  2. This is a DOM table update only (very fast)



    Performance issues are going to be directly related to the number of categories and items on a page and their associated graphics.



    Note also that pages are “cached” in the filesystem so the “first read” is always the slowest, but subsequent reads are loaded directly like a static page. The read time is usually related to:
  3. retrieving and sending uncached images to the browser (the browser will also cache them).
  4. creating (if necessary) the cached page in the filesystem.



    Take a look at var/compiled on your store system. That’s where the cached pages reside. There is one for each language that you support.



    Note also that if you edit *.tpl files directly and they are not ‘top level templates’ that the changes will NOT be picked up until the var/compiled directory is removed or the page is flushed from there. But this is not usually a problem in a production store but can drive you nuts when developing and forgetting that your changes are in, just not visible until you do “rm -r var/{cache,compiled}” which essentially causes the store to be re-cached on the next access. This can be changed via a setting in config.local.php (or maybe just config.php). But this will also introduce a performance issue if all templates are cached individually but is a good setting during development.



    As a rule, it woulld be “best” to visit every page within your site after doing an update of data (especially images). This will get all the pages in the var/compiled cache and offer the best performance to your customers.

Wow this is great it definitely eliminates the conflicts that are always there if you do any mods on the templets. Will this work with any skin automatically?



Thank you very much.

Thank you tbirnseth for this information. I am still trying to figure this out, but I am slowly getting it. So far I have only changed my header and my styles, but it’s getting there.



I do have a question though. I made up my own styles sheet and used a hook like you said to do and everything seems to be working. I used the “post” hook for the style sheet. This seems to change any style that is in the standard styles.css to my new style. My question is, does having it this way override any style? I guess what I mean is if I have:


#logo-image { margin-left: 10px; }



In my standard styles.css and in my custom styles I put:


#logo-image { margin-left: 20px; }



Which one will actually be shown? Also will IE or FF show this differently or will this work just like any other style sheet?



I apologize if my question is confusing, I just didn’t know how to ask what I mean.



Brandon

[quote name=‘brandonvd’]Thank you tbirnseth for this information. I am still trying to figure this out, but I am slowly getting it. So far I have only changed my header and my styles, but it’s getting there.



I do have a question though. I made up my own styles sheet and used a hook like you said to do and everything seems to be working. I used the “post” hook for the style sheet. This seems to change any style that is in the standard styles.css to my new style. My question is, does having it this way override any style? I guess what I mean is if I have:


#logo-image { margin-left: 10px; }



In my standard styles.css and in my custom styles I put:


#logo-image { margin-left: 20px; }



Which one will actually be shown? Also will IE or FF show this differently or will this work just like any other style sheet?



I apologize if my question is confusing, I just didn’t know how to ask what I mean.



Brandon[/QUOTE]



Hi Brandon



Hopefully I can help here and take some of the weight off Tony!



With CSS styles, if the same style selector appears twice, the 2nd instance overrides the first.



In the example you give above, the selector #logo-image appears twice - in the standard styles and in your custom stylesheet. Because you used the “post” hook for your custom stylesheet, your custom style will be the 2nd instance and will override the standard style.



ie. #logo-image { margin-left: 20px; }

is the one that will be shown



With regards to IE & FF - it will work the same as any other stylesheet - by this I mean that if a css hack is required to get the particular thing you are doing to work in (most likely) IE you will need to provide a custom override IE hack also.

Okay, I only took about an hour to look through the code, but here is what I got.







MVC design pattern: Model-View-Controller



Pay attention to the “views” folder and “controllers” folder.



There are 3 main areas:


  1. common
  2. admin
  3. customer



    When you are in the store, you are in the customers area. When you are in the administration panel, you are in the admin area.







    With the demo data installed.



    When you click on books, you get the query_string:



    index.php?dispatch=categories.view&category_id=93





    Pay attention to the variable “dispatch”. It is set to “categories.view”



    categories.view gets split into controller=“categories” and mode=“view”





    Since you are in the customer area, the controller that gets called is in the path:



    controllers/customer/categories.php



    The mode is set to “view” and in categories.php, you can define the functions and actions the script should take.



    The odd thing about cs-cart is that you are required to have a corresponding view with the same name, which means the following directory and file template must exist:



    views/customers/categories/view.tpl



    If dispatch=categories.catalog, then the following directory and file template must exist:



    views/customers/categories/catalog.tpl





    If you don’t have the template file, you’ll get the 404 page.



    Oh, the “views” directory you need to look at depends on which skin are you are using, so if you are using the basic skin, the path would be:



    skins/basic/views/customers/categories/catalog.tpl





    I’ll look into the addon part at a later time. I’m just modify the main controllers and views at this time.

If you guys need to customize the design and layout, you guys can use the awesome “design mode”.



In the Administration panel, go to “Design->Design mode”. Then click on "Enable customization mode.



Then click on “View STOREFRONT in customization mode”.



It’s pretty cool, cause you can edit the template in place and it tells you which template you need to modify.