Theme Functioning In Cs-Cart 4.4.1: New Upgrade, Installation, And Cloning Logic

Hello!

The alpha version of CS-Cart 4.4.1 is coming in the nearest time, and the production release—this fall. Two main changes in the new version are the built-in invoice and email template editor and the new logic of theme functioning. In this post, we’d like to tell you about the new logic of themes from the developer point of view.

In CS-CS-Cart 4.4.1, the logic of theme functioning will be more convenient for theme developers. It will do good for store admins as well: an upgrade to a newer CS-Cart version will not break custom themes.

<br><span><span style="font-size:26.6667px;font-family:Arial;color:rgb(0,0,0);font-weight:400;background-color:transparent;">Theme Dependencies</span></span>


All themes in CS-Cart are installed to the design/themes directory. In that directory, every theme has its own folder containing the manifest.json file. This file contains general parameters of a theme including the parent_theme parameter, which defines on what theme the current one depends. The dependent theme only has those files that differ from those of the parent theme.

Here’s a new theme dependency logic, which will be useful to know for theme developers:

  • The css, media, and templates folders will be merged for the dependent theme and the parent theme in runtime. If the dependent theme is missing some file, it will use that file of the parent theme. If the dependent theme has a file missing in the parent theme, they will be listed together (for example, product and product list templates, block wrappers, and static templates). If some file is present in both dependent and parent themes, the file of the dependent theme will be preferred.

  • The layouts and styles folders of a theme won't be merged. If the dependent theme has layouts or styles, they will be used. Otherwise, the dependent theme will inherit layouts and styles of the parent theme.

  • Operate the content of a theme via these two methods: 1) \Tygh\Themes\Themes::getDirContents() provides the contents of the specified theme directory with the exact location of each file or directory and 2) \Tygh\Themes\Themes::getContentPath() provides the information about the location of a file in the theme.

<span><span style="font-size:26.6667px;font-family:Arial;color:rgb(0,0,0);font-weight:400;background-color:transparent;">Upgrading Theme Files, Installing, and Cloning Themes</span></span>


Inner mechanisms of upgrading, installing, and cloning themes are also changed. Here’s how all of this will work In CS-Cart 4.4.1:

  • Before, when a store admin upgraded the store to a newer CS-Cart version, a custom theme could be broken. That happened because the Upgrade center changed files of custom themes. Starting from CS-Cart 4.4.1, the Upgrade center will only upgrade default themes—Responsive and Basic (the latter is deprecated—we recommend to use Responsive). Custom themes won’t be affected at all.

  • During a theme installation, files of the parent theme won’t be merged with those of the installed theme. It means that only the custom theme files will be copied from var/themes_repository to design/themes.

  • When a store admin clones a theme, only manifest.json, logos, and the default style will be copied to the clone theme directory. The clone theme will only contain the manifest.json file, theme logos, and the default style. The name of the source theme will be specified in the parent_theme parameter of the clone theme’s manifest.json file. The clone theme won't be activated after creation.

Installing Third-Party Add-Ons

Add-ons cannot work without theme-related files such as templates. Before, when a store admin installed an add-on, the add-on copied its theme-related files made for the Responsive theme to all the Responsive-dependent themes. In CS-Cart 4.4.1, an add-on copies its theme-related files for the Responsive theme only (not for all its dependent themes).

In CS-Cart runtime, add-ons will search for necessary files in this order:

  • Current theme

  • Parent theme specified in the manifest.json file

  • Base theme specified in the local.config.php file

Please ask any questions about new theme logic in this topic, our developers will kindly answer them.

Hi there,

How many levels deep does the inheritance go? For example, if I download a theme called "custom_theme" which has "responsive" as its parent, am I able to create another theme which uses "custom_theme" as its parent. And all 3 levels would have the new logic applied? I hope so :)

BTW, sounds great and good to see the positive changes in CS-CART.

Nathan

Hi there,

How many levels deep does the inheritance go? For example, if I download a theme called "custom_theme" which has "responsive" as its parent, am I able to create another theme which uses "custom_theme" as its parent. And all 3 levels would have the new logic applied? I hope so :)

BTW, sounds great and good to see the positive changes in CS-CART.

Nathan

Hi nateallis,

Good question, thank you. But the answer is no.

When you clone "custom_theme" which has responsive as a parent, all custom_theme files will be copied to your new theme and its parent theme will also be responsive.

This is done in order to make the process clearer and easily to maintance. You know it will be a mess when you have to track templates in 3 different themes.

Hi gentlemen's,

Why reinvent the wheel?

Why not to use the similar scheme thats use CMS like Wordpress in order to create updates on themes?

Hi nateallis,

Good question, thank you. But the answer is no.

When you clone "custom_theme" which has responsive as a parent, all custom_theme files will be copied to your new theme and its parent theme will also be responsive.

This is done in order to make the process clearer and easily to maintance. You know it will be a mess when you have to track templates in 3 different themes.

Possibly, it could be a mess... but depends on the developer I guess.

I was just thinking that it might be a nice way to customise a purchased theme with minor tweaks for a different storefront. I guess we will do it via layouts.

@Nick2474:

Not sure about the wordpress idea or how that would work... do they use a third party solution that does the merging of templates which could be used by CS-CART?

Hi gentlemen's,

Why reinvent the wheel?

Why not to use the similar scheme thats use CMS like Wordpress in order to create updates on themes?

Actually the new logic is primary based on Wordpress child themes: https://codex.wordpress.org/Child_Themes

So no, we use the wordpress wheel:)

  • The css, media, and templates folders will be merged for the dependent theme and the parent theme in runtime. If the dependent theme is missing some file, it will use that file of the parent theme. If the dependent theme has a file missing in the parent theme, they will be listed together (for example, product and product list templates, block wrappers, and static templates). If some file is present in both dependent and parent themes, the file of the dependent theme will be preferred.

How does this merger of media work in templates and css / less? I see in templates {images_dir} refers to the parent theme and {self_images_dir} refers to the selected theme. That's not merging at all as it forces the designer to know what is in what theme. Is there a better way to refer to images in templates that doesn't require knowing what theme the image is in? What about referring to images in css & less?

How does this merger of media work in templates and css / less? I see in templates {images_dir} refers to the parent theme and {self_images_dir} refers to the selected theme. That's not merging at all as it forces the designer to know what is in what theme. Is there a better way to refer to images in templates that doesn't require knowing what theme the image is in? What about referring to images in css & less?

Unfortunately we could not find a better solution for images.

However I do not see a big problem here, if your designer uses existing image than it should be taken from parent theme, otherwise if hi creates a new one than it is in {self_images_dir}

Or you can store all images in child theme, if this is will make designer live easier.