Adapt Your Add-Ons To Cs-Cart 4.1.4

Hello everybody!



We continue to inform our developers about the core changes that can affect custom add-ons.

This time we observe changes from 4.1.3 to 4.1.4 versions.



[size=5]CORE

===============================================[/size]



[color=#000000][font=Arial][size=4]The new setting that restricts using API through HTTP was added (only HTTPS connection allowed).[/size][/font][/color]

[color=#000000][font=Arial][size=4]Check the [/size][/font][/color][color=#000000][font=Arial][size=4]config.tweaks.api_https_only[/size][/font][/color][color=#000000][font=Arial][size=4] setting if API is used in the add-on.[/size][/font][/color]

[color=#000000][font=Arial][size=4]
$https_flag = Registry::get('config.tweaks.api_https_only');
if ($https_flag) {
......
}
[/size][/font][/color]



[HR]

[color=#000000][font=Arial][size=4]The new setting that restricts using API in the customer area was added.[/size][/font][/color][color=#000000][font=Arial][size=4]So, check the [/size][/font][/color][color=#000000][font=Arial][size=4]config.tweaks.api_allow_customer[/size][/font][/color][color=#000000][font=Arial][size=4] setting.[/size][/font][/color]



[HR]

The getOnline($area) function was added to the Sessions class:


$sessions = Session::getOnline('C');




[HR]

[color=#000000][font=Arial][size=4]Now the [/size][/font][/color][color=#000000][font=Arial][size=4]delivery_time[/size][/font][/color][color=#000000][font=Arial][size=4] parameter can be used for the real-time shipping methods.[/size][/font][/color]

[color=#000000][font=Arial][size=4]It is not used in the CS-Cart core by default. But it is possible to use this functionality in the add-on that will extend the checkout page, so that the delivery time will be displayed on it.[/size][/font][/color]



[HR]

[color=#000000][font=Arial][size=4]The '[/size][/font][/color][color=#000000][font=Arial][size=4]basic'[/size][/font][/color][color=#000000][font=Arial][size=4] theme name must [/size][/font][/color][color=#000000][font=Arial][size=4]not [/size][/font][/color][color=#000000][font=Arial][size=4]be used in the code for getting or using templates.[/size][/font][/color]

[color=#000000][font=Arial][size=4]Use the following structure instead: [/size][/font][/color][color=#000000][font=Arial][size=4]Registry::get('config.base_theme');[/size][/font][/color]

[color=#000000][font=Arial][size=4]Example:[/size][/font][/color]


NO: $path = 'basic' + $file_path;
YES: $path = Registry::get('config.base_theme') + $file_path;




[HR]

[color=#000000][font=Arial][size=4]The [/size][/font][/color][color=#000000][font=Arial][size=4]theme_editor.php[/size][/font][/color][color=#000000][font=Arial][size=4] controller was renamed to the [/size][/font][/color][color=#000000][font=Arial][size=4]file_editor.ph[/size][/font][/color][color=#000000][font=Arial][size=4]p[/size][/font][/color]

Appropriate permissions and TPL files were renamed too.



[HR]

[color=#000000][font=Arial][size=4]The[/size][/font][/color][color=#000000][font=Arial][size=4] manifest.ini[/size][/font][/color][color=#000000][font=Arial][size=4] support was returned to the themes. When installing a theme from the [/size][/font][/color][color=#000000][font=Arial][size=4]var/themes_repository [/size][/font][/color][color=#000000][font=Arial][size=4]directory[/size][/font][/color][color=#000000][font=Arial][size=4], [/size][/font][/color][color=#000000][font=Arial][size=4]the [/size][/font][/color][color=#000000][font=Arial][size=4]manifest.json[/size][/font][/color][color=#000000][font=Arial][size=4] file is created automatically.[/size][/font][/color]

[color=#000000][font=Arial][size=4]And if a theme is installed directly to the[/size][/font][/color][color=#000000][font=Arial][size=4] design/themes [/size][/font][/color][color=#000000][font=Arial][size=4]directory, it will work correctly with [/size][/font][/color][color=#000000][font=Arial][size=4]manifest.ini. [/size][/font][/color][color=#000000][font=Arial][size=4]Note that when cloning this theme, the new one will contain the [/size][/font][/color][color=#000000][font=Arial][size=4]manifest.json[/size][/font][/color][color=#000000][font=Arial][size=4] file.[/size][/font][/color]



[HR]

[color=#000000][font=Arial][size=4]Another one change concerning the themes: the new [/size][/font][/color][color=#000000][font=Arial][size=4]parent_theme[/size][/font][/color][color=#000000][font=Arial][size=4] parameter was added to the [/size][/font][/color][color=#000000][font=Arial][size=4]manifest.json[/size][/font][/color][color=#000000][font=Arial][size=4] (or [/size][/font][/color][color=#000000][font=Arial][size=4].ini[/size][/font][/color][color=#000000][font=Arial][size=4]) file.[/size][/font][/color]

[color=#000000][font=Arial][size=4]This parameter defines the existing theme which files will be taken as basic when installing the new theme.[/size][/font][/color]



[color=#000000][font=Arial][size=4]Earlier files were copied in the following order during the theme installation process:[/size][/font][/color][list]

[][color=#000000][font=Arial][size=4]Files from the [/size][/font][/color][color=#000000][font=Arial][size=4]var/themes_repository/basic [/size][/font][/color][color=#000000][font=Arial][size=4]directory.[/size][/font][/color]

[][color=#000000][font=Arial][size=4]Files from the [/size][/font][/color][color=#000000][font=Arial][size=4]var/themes_repository/my_custom_theme[/size][/font][/color][color=#000000][font=Arial][size=4]. Where [/size][/font][/color][color=#000000][font=Arial][size=4]my_custom_theme[/size][/font][/color][color=#000000][font=Arial][size=4] is the newly installed theme.[/size][/font][/color]

[/list]

[color=#000000][font=Arial][size=4]Now the order will be as follows:[/size][/font][/color][list]

[][color=#000000][font=Arial][size=4]Files from the [/size][/font][/color][color=#000000][font=Arial][size=4]parent_theme[/size][/font][/color][color=#000000][font=Arial][size=4] directory.[/size][/font][/color]

[][color=#000000][font=Arial][size=4]Files from the [/size][/font][/color][color=#000000][font=Arial][size=4]var/themes_repository/my_custom_theme[/size][/font][/color][color=#000000][font=Arial][size=4]. Where [/size][/font][/color][color=#000000][font=Arial][size=4]my_custom_theme[/size][/font][/color][color=#000000][font=Arial][size=4] is the newly installed theme.[/size][/font][/color]

[/list]

[color=#000000][font=Arial][size=4]If the [/size][/font][/color][color=#000000][font=Arial][size=4]parent_theme [/size][/font][/color][color=#000000][font=Arial][size=4]parameter is not defined, files will be copied from the [/size][/font][/color][color=#000000][font=Arial][size=4]var/themes_repository/basic [/size][/font][/color][color=#000000][font=Arial][size=4]directory as before. If it is defined but empty, basic files will not be copied. In this case only the files from the newly installed theme will be copied.[/size][/font][/color]





[size=5]HOOKS AND FUNCTIONS

===============================================[/size]



[color=#000000][font=Arial][size=4]The following hook was extended:[/size][/font][/color]

[color=#b22222][font=Arial][size=4]- fn_set_hook('sitemap_link', $link);[/size][/font][/color]

[color=#006400][font=Arial][size=4]+ fn_set_hook('sitemap_link', $link, $object, $value, $languages, $links);[/size][/font][/color]



[HR]

[color=#000000][font=Arial][size=4]Parameters of the following function were changed:[/size][/font][/color]

[color=#b22222][font=Arial][size=4]- function fn_merge_styles($files, $styles=[/size][/font][font=Arial][size=4], $prepend_prefix = [/size][/font][font=Arial][size=4], $params = array())[/size][/font][/color]

[color=#006400][font=Arial][size=4]+ function fn_merge_styles($files, $styles=[/size][/font][font=Arial][size=4], $prepend_prefix = [/size][/font][font=Arial][size=4], $params = array(), $area = AREA)[/size][/font][/color]



[HR]

[color=#000000][font=Arial][size=4]Parameters of the following function were changed: [/size][/font][/color]

[color=#b22222][font=Arial][size=4]- [/size][/font][font=Arial][size=4]function fn_get_file($filepath, $filename = )[/size][/font][/color]

[color=#006400][font=Arial][size=4]+ function fn_get_file($filepath, $filename = [/size][/font][font=Arial][size=4], $delete = false)[/size][/font][/color]



[color=#000000][font=Arial][size=4]Now it is possible to delete a file after receiving it.[/size][/font][/color]



[HR]

[color=#000000][font=Arial][size=4]Parameters of the following function were changed:[/size][/font][/color]

[color=#b22222][font=Arial][size=4]- function fn_get_dir_contents($dir, $get_dirs = true, $get_files = false, $extension = [/size][/font][font=Arial][size=4], $prefix = [/size][/font][font=Arial][size=4], $recursive = false)[/size][/font][/color]

[color=#006400][font=Arial][size=4]+ function fn_get_dir_contents($dir, $get_dirs = true, $get_files = false, $extension = [/size][/font][font=Arial][size=4], $prefix = [/size][/font][font=Arial][size=4], $recursive = false, $exclude = array())[/size][/font][/color]





[color=#282828][font=arial, verdana, tahoma, sans-serif]The newly added hooks are not described here as before, only the ones that changed. Refer to our [/font][/color]Hook Base[color=#282828][font=arial, verdana, tahoma, sans-serif] to see all the hooks in all CS-Cart and Multi-Vendor versions. [/font][/color]

Thanks for the update. Look forward to the release of CS-Cart 4.1.4.

Thanks. alexions rocks too! )

Can you expand upon this please?

[quote]

[color=#000000][font=Arial][size=4]The '[/size][/font][/color][color=#000000][font=Arial][size=4]basic'[/size][/font][/color][color=#000000][font=Arial][size=4] theme name must [/size][/font][/color][color=#000000][font=Arial][size=4]not [/size][/font][/color][color=#000000][font=Arial][size=4]be used in the code for getting or using templates.[/size][/font][/color]

[color=#000000][font=Arial][size=4]Use the following structure instead: [/size][/font][/color][color=#000000][font=Arial][size=4]Registry::get('config.base_theme');[/size][/font][/color]

[color=#000000][font=Arial][size=4]Example:[/size][/font][/color]

NO: $path = 'basic' + $file_path;

YES: $path = Registry::get('config.base_theme')' + $file_path;

[/quote]

Does this mean that the themes_repository might contain themes other than 'basic'?

My guess is this is because there is a 2nd, responsive basic theme coming

[quote name='tbirnseth' timestamp='1397512850' post='181714']

Can you expand upon this please?



Does this mean that the themes_repository might contain themes other than 'basic'?

[/quote]



You are right. It seems that these changes are made due to responsive theme which will replace the basic theme in the future.

Thank you for sharing this!

[quote name='tbirnseth' timestamp='1397512850' post='181714']

Can you expand upon this please?



Does this mean that the themes_repository might contain themes other than 'basic'?

[/quote]



Yes. You can use any theme as “basic” now.

Huh? So as a developer, I have to account for any number of (non-standard and unique) themes in the themes_repository? Again, please expand with an example of what you are saying?

@Flo - When an addon developer has front-end templates, we have traditionally installed them in the 'basic' skins_repository theme (names have changed over time, but this is an example). When a new theme is “installed”, the 'basic' theme is laid down first, then the other 'themes' are added over the top of it to create the new theme (the other themes were removed in V3). This allows common things to only have to exist once. A new theme might just consist of new blocks and css given that there is tons of logic now in the presentation layer.



I was asking Alex for clarity on what he meant by the brief comment and to expand on it as it relates to addon developers (since this is a thread for developer heads-up).



And related to responsive design, seems to me the whole point of responsive “design” is to enable one-size-fits-all layout/presentation which is based on device characteristics. So there shouldn't need to be a responsive and non-responsive 'basic' theme.



So to clarify, what I'm looking for in my question is what an addon developer who has front-end components needs to do for archiving and distributing their addons. I'm assuming that the installation process takes care of any configuration specific details that are outside the addon developer's control. In addition, is there any changes to the backend area related to templates? They are all hard-wired to the 'basic' theme and are no longer “installed” when an addon is installed but always exist.



If the whole model is changing, then we need a lot more info than a 5 word statement on what exactly is changing and an example of how we are to adjust.

Although I don't typically develop apps, this new api direction is cool.



Just a thought…



Something I would like see come out of this new adoption to standards is package installer required for all addons, for both full install and complete uninstall, especially with the market place live now.



As someone whom has used & tried several addons in the past, the norm has been to manually copy over the files, then install… but then for whatever reason if I wanted to remove completely or maybe due to new cscart release, there is no way easy way to do this without knowing all the modifications, DB and file locations for it. Fortunately I used to develop in the past, so I'm somewhat familiar with coding, but for many inexperienced users, especially with the SAAS solution, these unused files will take up space or in some cases cause issues with cart updates.

[quote name='tbirnseth' timestamp='1397587031' post='181768']

@Flo - When an addon developer has front-end templates, we have traditionally installed them in the 'basic' skins_repository theme (names have changed over time, but this is an example). When a new theme is “installed”, the 'basic' theme is laid down first, then the other 'themes' are added over the top of it to create the new theme (the other themes were removed in V3). This allows common things to only have to exist once. A new theme might just consist of new blocks and css given that there is tons of logic now in the presentation layer.



I was asking Alex for clarity on what he meant by the brief comment and to expand on it as it relates to addon developers (since this is a thread for developer heads-up).



And related to responsive design, seems to me the whole point of responsive “design” is to enable one-size-fits-all layout/presentation which is based on device characteristics. So there shouldn't need to be a responsive and non-responsive 'basic' theme.



So to clarify, what I'm looking for in my question is what an addon developer who has front-end components needs to do for archiving and distributing their addons. I'm assuming that the installation process takes care of any configuration specific details that are outside the addon developer's control. In addition, is there any changes to the backend area related to templates? They are all hard-wired to the 'basic' theme and are no longer “installed” when an addon is installed but always exist.



If the whole model is changing, then we need a lot more info than a 5 word statement on what exactly is changing and an example of how we are to adjust.

[/quote]



Tony, thank you for the feedback.



At the moment we are working on the strategy of replacing “basic” theme with responsive in 4.2. The main point is to avoid extra actions required from our developers to update their themes & add-ons. Add-ons & themes for 4.1.x should be compatible with 4.2.



All add-ons that work in 4.1.3 should work fine in 4.1.4 with basic skin. Responsive theme will be in beta in 4.1.x branch, so we can not guarantee that add-on will work with this theme, probably there will be some issues because responsive has a lot of styles changes.



I will get back to this post as soon as we find some solutions.

I'm going to enable CS-Cart v4.1.4 for test purposes for our developers tomorrow, so you can check your add-ons. The final release is planned for the next week.

@imac,

Thanks for the response. Mostly just confusing to have a one line update and then ask a question and get a one line response that didn't really add any information.



Still think you should revisit requirement to spread addon files all over the place. With {style} hook and other stuff, can easily specify the locations. Everything for an addon should be under one addon directory (addons/X, skins/[theme]/frontend/addons/X, skins/[theme]/backend/addons/X). You could then derive an “remove” function that would remove all files in the distributed addon that exist in these locations. Right now, uninstall instructions look like:

[quote]

For V2.x:

+ addons/

+ var/skins_repository/base/admin/addons/

+ var/skins_repository/base/customer/addons/

+ var/skins_repository/base/mail/addons/

For V3.x:

+ addons/

+ var/skins_repository/basic/admin/addons/

+ var/skins_repository/basic/customer/addons/

+ var/skins_repository/basic/mail/addons/

For V4.x:

+ app/addons/

+ var/themes_repository/basic/templates/addons/

+ var/themes_repository/basic/css/addons/

+ var/themes_repository/basic/mail/templates/addons/

+ var/themes_repository/basic/media/images/addons/

+ design/backend/css/addons/

+ design/backend/mail/templates/addons/

+ design/backend/media/images/addons/

+ design/backend/templates/addons/

[/quote]

Tony,



Do you think storing all add-ons files in one folder really worth another one mess with compatibility?

May be we can solve this problem simply by adding a feature “Remove add-on” that will work the same was as installation (if there are no permissions on files admin will be asked to provide FTP access)?

Probably not worth it now. Just wish that change had come as a “proposal” BEFORE it was done to get feedback on the change. I think you would have found a resounding “leave it” since there's really no architectural advantage to the change.



But it would be nice if there was an option for a customer to remove an addon (only if it's uninstalled). As above, I think you're going to have to be careful since addon developers still include changes to standard files (I don't, but some do) so you'll have to validate each element in the archive before removing it if you use the archive contents as the basis. Or you can just remove all “defined standard addon locations” if there are any files/directories for the addon in that location (I.e. the list above). But then that assumes that everyone has things in the right places. I know I have a mistake in my world related to backend mail templates being in mail/addons versus mail/templates/addons. I believe the 'templates' directory was added after 4.0.1 or that there was no directory originally distributed. And for me to change would be a really big deal so I've left it (the compatibility that you mention).

I am sorry for off-topic (probably) but I can not to miss the opportunity to say about new structure of folders. As a developer with big experience of customizing the CS-Cart I feel hurt every time I develop the massive addon. I have to keep in mind not only the common structure of default folders, but the addon holders as well. As the result the addon should have its own includes in each resource (php, templates, media, css, mail). For example if you need to copy the addon to another store you should check all the folders where this addon may be placed. Isn't it better to have all addon's files in one folder with keeping the common structure of engine? For example do it in the following way: move the 'addons' folder (I mean app/addons/) one level up and remain the common structure for each addon separately. It means the 'age_verification' (for example) addon will contain the following folders in it: 'app', 'design', 'schema', etc.



I think it would more “addon” than it looks now.

@ecomlabs - we agree totally. Each addon should have a common root. This is the type of issue that should have been discussed with addon developers before the design was solidified and implemented.



However, at this point, I certainly don't want to have to change yet again my build environment for addons.

@tbirnseth,



Don’t worry about it. Usually the changes in structure of files/folders do not take a place within one branch. But I think that we must put this idea to their mind now in order it took a place in v5 .

I don't want it to change in V5. It should have been done correctly the first time in V3/V4 and it should have been based upon collaboration between cs-cart developers and addon developers. Many of the changes have no real value (I.e. customer/admin becoming frontend/backend or skins becoming themes). I suggested in V2 that everything (including templates) be located within a single addon directory but as usual, since it didn't come from within cs-cart, it was ignored (assumed since there was no dialog).



I have to maintain 3 separate build environments as well as 3 separate source bases now. I certainly don't want to have to add more.

Hi to everyone!



Please take a look at this post. Adapting Add-Ons To The Responsive Theme - Developers' Corner - CS-Cart Community Forums

It is about updating your add-ons to be compatible with responsive theme.