Functions and modules

Hostedshop has a lot of different functions and modules to assist you in developing your online shop.
Here, you'll find the documentation on some of these modules and functions.

The function getTranslation

Hostedshop has a function that provides access to all language specific texts on your website. The function is accessible via ’getTranslation’. This is a global feature that exists on all controllers and is used to get information, such as product title, blog text and contact form information. This feature can retrieve data in all language translations, but defaults to the current user's selected language.

The 'getTranslation' function should not be confused with the $text variable, which also contains translations. The difference is which data you receive. GetTranslation gets data entry into the database, meaning all the products, blog or news posts you have created. While the $text variable is a list of generic system texts, such as postcode, username, buy button text, etc.

getTranslation() reference tabel

The function handles four parameters. The table below describes the function and order of parameters.

Function controller->getTranslation(id, title, module, language)

Parameter	Required	Definition	Example
id	x	Element id.	10
title	x	See examples below.	seo_title
module		(Optional) See examples below.	product
language		(Optional) ISO language code e.g. for Danish (DK), English(UK), Norwegian (NO) etc. For more information: See ‘Languages and domains’ in the Hostedshop Administration.	UK

When calling the function, there are a few things you should be aware of:

1) The function knows about the module, but it can get texts from all modules in the system.
2) The function knows about the selected language, but it can get texts from any language in the system.

This example shows how the function and the parameters are used to call user defined information through the help of controllers from the form.tpl filen:

 {$formController->getTranslation($formEntity->Id, "form-element", "button")}

An important aspect to have in mind is that controllers in Hostedshop are "self-aware" - which means that controllers can use the required parameters: ’id’ and ’title’ and still have access to the correct information, because the controller knows all the other relevant information. Here is an example from the product-list.tpl file:

product-list.tpl filen:

{$descriptionBottom = $userController->getTranslation($brand->Id, "text_two")}

Of course, you can also use all four parameters, which is useful if you want to be more specific. For example to display the language name of a product in English (UK).

NOTE
Some controllers, productController and blogController, among others, have short-hands that make it possible to access specific information more easily. As this example:

productController->getDescription productController->getDescriptionShort blogController->getDescription

JSON module

Besides the regular page-types in Hostedshop, we also have modules/json, which is a special type of page. It does not load the rest of the template system as the other pages do - it only loads the individual files defined in the files inside it. All files here is loaded with the ”Content-Type: application/json” document header. This means that it is ideal for reading and generating JSON data.

In Hostedshop designs, we utilize this page type to generate JSON-data (asynchronous data) for things such as the product list and product-variants.

In the folder, you can modify existing files to add data to your website, such as the product list or product page. Just remember that these files are necessary for the templates to work and editing them may result in loss of functionality.

Besides editing or adding data to existing files, you can also create your own JSON-resources that your customers/visitors can use. For example, you can create your own blog or news ticker by creating your own JSON-files and output data using Controllers, Collections and Entities. Remember, when creating new JSON-files: You need to write the corresponding JavaScript for your page that can handle the new data.

Within JSON templates you will find a modifier called "jsonify". This is usually called at the bottom of a template. Jsonify takes an array of Smarty data created inside a template file and formats it as JSON, so that the data can be used by JavaScript.

Example 1

Go to the [template_name]/modules/json folder. Here, you can create or edit JSON files using Smarty. In this example, we are editing the products.tpl file, as well as adding user defined data to it. Products.tpl are the files that generate all the JSON data, which together with AngularJS is what is used to generate the product list.

{controller assign=controller type=product}

{collection assign=products controller=$controller productId=$value}

{$product['CustomDescription'] = 'Duis vel semper orci, quis vehicula elit...'} {$output|jsonify}

WARNING: if you don't include jsonfiy at the bottom of the file, you will need to add the entire formatting manually.

1. Assign a product controller (as we are editing, this is already done for us).
2. Assign a product collection (as we are editing, this is already done for us).
3. Add a custom description for the product variable with the following format.
4. The custom description is formatted and delivered as JSON to the browser (this can be viewed via the DOM Inspector in your browser, see the image below).
5. You can now continue to use this data on your productlist by using the AngularJS-templates. Mainly 'modules/products/partials/list-js-col.tpl' and 'modules/products/partials/list-js-row.tpl'. These are the templates that represent the product in the productlist in row and column view.

Functions for caching

Smarty caching allows developers to increase the speed of heavy webshops or websites. With smarty caching, the elements you want cache in a file are saved. Instead of making a request to the system about which menu to display, it is retrieved via a static file. The file is updated whenever you want - with smarty you set a time period, e.g. 1 hour.

Read about the 3 functions below that can be used to cache smarty elements, such as a menu.

CacheIntent

The CacheIntent function is for extracting and creating cache items. In other words, an initialization of the cache that can be used for retrieval via the cache function.
CacheIntent accepts the following parameters:
 

Navn	Default	Description	Påkrævet
name	''	Name for recognizing cache	Yes
cache_site	true	Cache is unique for every page	No
cache_iso	true	Cache is unique for every language layer	No
cache_uri	true	Cache is unique for every REQUEST_URI	No
cache_currency	true	Cache is unique for every currency, if available	Yes
ttl	3600	The Cache's Time To Live (TTL) in seconds	No
assign	''	Name for new variable that contains object instance Name	Yes

Cache

The cache function is used to save caching data. Data is stored via cache in a cache instance, which is created via cacheIntent.
Cache accepterer følgende parametre:

Navn	Default	Description	Required
content	''	The content to be cached	Yes
cacheIntent	''	Name of the cacheIntent to be used	Yes

ClearCache

The ClearCache function is used to delete or empty a certain cache. For example, if a user logs out or if you need to delete the content for other reasons. For example, in the footer, where you remove the newsletter subscription for a user once they have signed up. There can be many different reasons for deleting a cache.

ClearCache accepts the following parameters:

Navn	Default	Decription	Required
name	''	Title of cacheIntent that need to be deleted	Yes

About the use of caching

Caching is ideal for components or template files that are very resource-intensive. Or to cache components and templates that are repeated in many places across your solution, e.g. a menu or footer.

It is important that the title of the cache is unique, as the title is used to retrieve the cache in question at every load. The name can therefore also be used to make the cache unique for more levels than is possible with the caching parameters. In the menu example below, we make the name unique for each page ID by combining a recognizable name, in our case "menu_", with the page ID of the page you are on in the navigation. This way, together with the caching parameters for cacheIntent, you can overwrite or remove levels where the cache should be unique.

Smarty caching is file-based and saves cache files in the time periode you specify (TTL as mentioned above). This also means that, with smarty caching, a menu, for example, will not always automatically update, as long as it is in the cache. It is always possible to delete the cache via the clearCache function.

The example below shows how you can use the caching features to cache a menu. So that even though the menu is cached, it works for language switching, navigation (displaying active/selecting active page) and site switching in case you use templates across different sites.

Note: When using caching, cache files are created on the solution, which are calculated into the space usage.

Example 1: caching of a menu, a template file

This example has been developed on the Rooty template, in the file partials/top.tpl.

We form the cache from several levels, described here:

• Language layer - Menu items change with the language, therefore we need to save one menu per language layer.
• Site - Different sites may have different menu items, and therefore one cache per site.
• Page id - to cache the menu per page, so we can show if the selected page is active. You can also cache by URL, but this will save far more cache files.
• User log in - the menu changes when logged in, e.g. under the My Account menu item.

{* We create a unique name for the cache, so we have a cache for each case *}
{$menuCacheName = "menu_"}
{$menuCacheName = $menuCacheName|cat:"{($user) ? '1' : '0'}_"}
{$menuCacheName = $menuCacheName|cat:$page.id}
{* Notify framework that you intent to cache a piece of code *}
{cacheIntent name=$menuCacheName cache_uri=false assign=cache}
{* Check intent object for existing cache *}
{if $cache.content}
    {$cache.content}
{* If empty the cache has not been set or has expired, so prepare a new cache *}
{else}
    {menu assign=primaryMenu static=$static}
    {* Assign the included file to a variable *}
    {include
        file='modules/widgets/menu/menu.tpl'
        items=$primaryMenu
        classes='nav nav-default'
        assign=menuContent
    }
    {* Save the captured file with the cache intent object, and echo the file content itself to the page *}
    {cache content=$menuContent cacheIntent=$cache}
{/if}

Example 2: caching of footer, a section or a part of template

The example has been developed on the Rooty template, in the file partials/bottom.tpl.

We remove some of the caching levels, as the section is not unique for e.g. currency or user - the levels we cache er therefore:

• Language layers - menu items change with the language, so we need to save one menu per language layer.
• Site - different sites may have different menu items, and therefore one cache per site.

To save template data, we use {capture}, a feature built into Smarty to store content into a variable. {capture} is used because we want to store parts of a template in a variable. {capture} takes the output from Smarty, i.e. pure HTML, and saves it as a string. In this case, in the variable called $footerCache.

{* Notify framework that you intent to cache a piece of code *}
{cacheIntent name=footer assign=cache cache_uri=false cache_currency=false cache_user=false}
{* Check intent object for existing cache *}
{if $cache.content}
    {$cache.content}
{else}
    {* First capture (equal to ob_start) the region that is to be cached *}
    {capture assign=footerCache}
    

{if $settings.social_plugin_likebox_pageurl}  
{$text.SOCIAL_BOX_FACEBOOK} 
{/if} 
{if $settings.social_twitter_pageurl}  
{$text.SOCIAL_BOX_TWITTER} 
{/if} 
{if $settings.social_google_pageurl}  
{$text.SOCIAL_BOX_GOOGLE} 
{/if} 
{if $settings.social_instagram_pageurl}  
{$text.SOCIAL_BOX_INSTAGRAM} 
{/if}