EnCommerce Templates. Webmaster’s guide.
Main Principals and System Structure.
The process of design implementation into the enCommerce store is in editing templates (http://wikipedia.org/wiki/template_(programming) ), where standard html with operators and variable data in smarty template language are used (http://smarty.php.net/manual/en/) . enCommerce system work principal in simple is next: backend-part of the Internet store (php) processes data and sends them to the templates system, which in its turn gives data through its variables and operators in html. In other words in the structure there are php and tmpl files, and in the end there are html with results of processing.
Scheme:
On the scheme notice 3 main springs, templates are built from:
1. Page modules – these are modules of the store sections or pages. These modules are independent and loaded into the start index.tmpl depending on the section we go to. On the scheme this module is content.tmpl, which contains displaying products and their categories.
2. Block modules are the block type templates. Their property is that they are always on the store pages, doesn’t matter which category we are in. Such kinds of templates are menu, search, etc. An important point is that if in the name of a template there is the word “index”, then it is already of a block type (except the parent template index.tmpl). That is, basketindex.tmpl is a block module of the shopping cart always loaded to the page. basket.tmpl is a module of a section, the shopping cart is more detailed, and loaded only when we go to the section.
3. Data – this is data of the current store. These are products, prices, news, etc. The store is operated from the administrative part of the system (CMS). There can be done such operations as products adding/editing, all menu building, user administrating, etc. For building an able to work store you will have to work with building/editing the menu of the main store, products sections (adding and changing categories and products), and may be with administrating some parameters when setting some ordering properties (Checkout steps).
In addition to standard and already existed page modules there is a possibility to create new templates. They are named the static templates. However, it doesn’t mean there is only static data. There you can also use such constructions as are shown below, e.g.
{include file="`$data->store->tmplPath`menudefault.tmpl" menu_id="menu-top"}
An example – it is required to build a static page “Contact Us” where there are no variables, but the text info only, which won’t change through cms. For this create a file with the appropriate name contact_us.tmpl in the folder content_tmpls. What is needed to get to this template is to mention the parameter ?main_menu_show= content_tmpls/contact_us in the url.
Now this template can be edited from the admin part. (CMS)
Templates search.
So how to find out which template we are in? It is easy – just look at the url in the browser and find the name of the php-file there. This name will absolutely coincide with the section module in the store.
For example, we are in the news section: http://demo.envisionext.com.ua:81/enCommerce/news.php?store_app_state=ab67562182c40fd2 --------- find news.tmpl and edit it. The structure of the templates arrangement is simple. All *.tmpl files are in one folder, have the logical names. For instance, login.tmpl contains the login pages, user registration, password reminding, etc. basket.tmpl – is a template which contains the shopping cart sections (section, where saved products user wants to purchase)
All css and js files must be in own folders (css and js relatively) To index.tmpl the path to these files must be made through the smarty-variable data. For example:
{assign var=cssDir value="`$data->store->tmplPath`css"}
<link type="text/css" rel="stylesheet" href="{$cssDir}/main.css" />
Most store functionalities are accessible in the authorized state. E.g. Checkout Steps. These are so called steps for setting some ordering properties for products which were put in the shopping cart. All of the checkout steps are in templates: ordershipinfo.php ordershipcharge.php orderpaymenttype.php ordercascade.php
Working Steps
Work can be divided into three main stages:
1. Cutting the main page to the static html.
2. Implementation of the cut html into the initial store design.
Work on each template needs a necessary detailed checking and testing. There are some templates and their parts which are not so easy to find. Apart index.tmpl there are also templates which are quite big and contain many sublevels. For example, content.tmpl contains displaying both products categories and products themselves and each separately. A very powerful debugging tool of templates is a smarty-operator {debug} Putting it into any part of code we get the displaying of all smarty – variable data as well as their values.
An example of a template
Examine a detailed example of work on the main enCommerce menu. It is needed to edit template menudefault.tmpl
{if count($items->items)} <!-- Condition, that checks menu options presence -->
{foreach item=menu from=$items->items} <!-- Start of a cycle displaying all menu lists -->
<ul>
{foreach key=k item=r from=$menu->items->items} <!-- Start of a cycle displaying all elements of each menu -->
<li{if $r->selected} class="active"{/if}> <!-- Checking if the current element of menu is “active”, means whether we are in this section or not -->
<!-- Start displaying menu element -->
<a href="{strip}
{if $r->TYPE == $smarty.const.STORE_MENU_LINK_TYPE_PROGRAM}
{$r->classfilename}.php?{$r->prefix}_id={$r->ITEMID}
{if $r->TARGET!=''}&{$r->TARGET}{/if}
{elseif $r->TYPE == $smarty.const.STORE_MENU_LINK_TYPE_INTERNAL}
?{$r->prefix}_show={$r->TARGET}&{$r->prefix}_id={$r->ITEMID}
{elseif $r->TYPE == $smarty.const.STORE_MENU_LINK_TYPE_LS2INSTANCE}
?{$r->prefix}_index=mod_ls2&{$r->TARGET}&{$r->prefix}_id={$r->ITEMID}
{elseif $r->TYPE == $smarty.const.STORE_MENU_LINK_TYPE_EXTERNAL}
{$r->TARGET}
{else}
#
{/if}
{/strip}">{$r->TITLE}</a>
</li>
{/foreach}
</ul>
{/foreach}
{/if}
It is important to focus on such variable data:
{$menu->TITLE} – the name of the whole menu (set in the admin panel when building the menu and its items) {$r->TITLE} – a name of the current menu item.
<span class="{$menu->TITLE}_r">
Creating static templates
Besides standard templates, which are already in the system, there is a possibility to create new ones. For example, it is needed to build a static page Contact Us where there are no variable data, but only text information, which is static and doesn’t change. For this create a file with a needed name contact_us.tmpl. Now all you have to do to get to this template is to paste the parameter in url ?main_menu_show=contact_us.
Products / categories / subcategories
Have a closer look at content.tmpl with its categories, subcategories of products and products themselves. All products with their categories are added into the system through CMS in the following menu section:
It is possible to create a multileveled tree of products with categories, subcategories and products in any part of the tree. Example:
In the main section “Home” there are main products’ categories (Alfa Romeo, Bentley etc.) they have own subcategories (in this case this is a division into the cars’ models ) and in the subcategories there are products themselves. However, in the main category Gift Certificates there are subcategories, there is only the product. In each category there may be either subcategories or products. Adding a category can be done in the following way: mark the required category where a subcategory has to be created (on the screenshot it is Home) and use option +Add Category
In the template content.tmpl differentiate accurately so-called levels of categories. Examine template structure:
In the beginning after the condition{if $params->currentContentInfo.LEVELSTATE == L_LAST} there is a code of displaying one product in the detailed type. That means when we open the product we see all information about it
Only further after {else} there should be a code of displaying a list of products and then products categories. As a result we have 3 stages of work on content.tmpl: 1. Work on a code displaying information about product. 2. Work on a code displaying products. 3. Work on a code displaying products categories.
Some information about get_data and get_params
These structures are used when data or parameters from the other module (loaded) should be included in the template. $data and $params exist in each enCommerce module. There are saved date and tools for templates. Example:
{get_data module='discuss' to='discussVars'}
In this case there is data including discuss module and data passing into array of variable data discussVars (happen.) Now these data can be used in the current template
app state
app state – these is current data about session, which is put in to the link in enCommerce. It includes tools of a current user, cashing, etc. The idea of app state is to transfer these data on all pages which a user can use during one session. Cookies have something similar. For example, a current url looks like this http://demo.encommerce.com/content.php?Content_item=502&store_app_state=a6c5f456335a7929 It is obvious the app state in it is a6c5f456335a7929. It is important to know when editing templates app state mustn’t be put into the links value. It will be put automatically. If it is needed to make a link there app state wouldn’t be put – then try next. For example, it is required to enter a link to http://envisionext.com into the template, where app state shouldn’t exist. In such a case href-parameter of the link should be in the following way href = 'http://envisionext.com' ( with gaps before and after the sign '=')
Printing version
In a store there is a potential to display a site version for printing. During this process a specially created and existed template print_index.tmpl is loaded. Any store modules can be included into it, and also a different css can be included as well.
emails messages
Some store modules have a feature to send data through e-mail. For this in the folder e-mail there are corresponding templates. Having administrated them it is possible to achieve a unique kind of sent messages, depending on the module, which sends this message.