When you click on books, you get the query_string:
index.php?dispatch=categories.view&category_id=93
[/QUOTE]
Unless of course you have the SEO addon enabled. But the logic is internally the same.
What you’re discussing at this point is in the system area related to acquiring and generating data content. The template area is within the skin.
[quote name=‘hykit’]
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
[/QUOTE]
Actually it becomes skin//customer/views/categories/view.tpl
[quote name=‘hykit’]
If dispatch=categories.catalog, then the following directory and file template must exist:
views/customers/categories/catalog.tpl
[/QUOTE]
skin//customer/views/categories/catalog.tpl
[quote name=‘hykit’]
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:
I’ll look into the addon part at a later time. I’m just modify the main controllers and views at this time.[/QUOTE]
Up to you… It’s much easier to look for the {hook name=“section:name”}possible content[/hook} tags (where ‘section’ might be ‘categories’ and name might be ‘view’). Though this isn’t a very good example since the “hook” in view.tpl is empty!
Then all you need to determine is:
Do I want to replace this content, prepend or append to it?
If I want to replace it than all I have to do is create a file of:
Then your changes are independent of any changes that might occur to the template ‘categories.tpl’ when a future upgrade comes your way.
Feel like I’m in “sales mode” for using addons! It’s really an easier approach unless you just want to do a one-off and leave whomever the client is at the version you make changes to (or want to secure future revenue as a contractor). If all the changes are in addons via hooks, then they are outside the upgrade process and simply get applied at run-time. Another benefit is that they are NOT cached. Hence there’s little chance of a change getting missed because the cache hasn’t been flushed.
This is a very interesting method of customization - I think I like it, but just to review…
If, for example, I run into an upgrade conflict somewhere - or say for example, a new feature is released and the default hooks are replaced by an override view that I have customized - it seems like with this system, I could simply turn off the addon that applies local customizations and see the plain vanilla version with updates - or another way of looking at it - I could compare the local changes I have made with the upgraded vanilla hooks and see if there is anything from the new feature set that I would like to incorporate.
My only question would be, what happens if a hook is deprecated? Would my override-pre-post files still apply if the original view is no longer utilized?
Seems like this could be worked into a versatile versioning engine as well… if it were possible to store local hook groups as ‘sets’ with particular folder names.
If, for example, I run into an upgrade conflict somewhere - or say for example, a new feature is released and the default hooks are replaced by an override view that I have customized - it seems like with this system, I could simply turn off the addon that applies local customizations and see the plain vanilla version with updates - or another way of looking at it - I could compare the local changes I have made with the upgraded vanilla hooks and see if there is anything from the new feature set that I would like to incorporate.
[/QUOTE]
Yes, that’s one approach. But remember that hooks are intended to be primarily UI only in the template area. Hence there should rarely be a functional change that impacted your hook. There are other aspects of an addon that can be applied to the functional pieces but I haven’t played with any of that in the customer area yet, only the system area.
[quote name=‘jagorny’]
My only question would be, what happens if a hook is deprecated? Would my override-pre-post files still apply if the original view is no longer utilized?
[/QUOTE]
That would be a really bad thing for them to do… I would not anticipate that.
[quote name=‘jagorny’]
Seems like this could be worked into a versatile versioning engine as well… if it were possible to store local hook groups as ‘sets’ with particular folder names.[/QUOTE]
I have tried to make this point to the cs-cart team. But I’m guessing their hands are rather full right now. A ‘version addon’ could have high possibilities. But if you’re wanting to do it for skins only, you can simply have the different skin directories. It would be really nice if the ‘common code’ was really common across the skin directories. But right now, it’s not, it’s duplicated for each skin.
Also note that for upgrades, only the standard (distributed) skins will be affected. Hence if you really want to separate yourself from the upgrades, just create it as a new skin. But then you have to merge the upgrade into your skin manually to account for functional, data or database changes. But it’s probably safer if you haven’t used addon/hooks for modifications. In reality, most developers will probably use both.
I think it’s the only way to do it portably. If you just go hack the *.tpl files then you’ll be resolving conflicts forever on each upgrade. If you create as a separate skin then you will never get upgraded.
Better/more tools could be provided. However, the walls around the development castle are pretty high and there doesn’t seem to be any interest in actual input or involvement. The castle seems to be soundproof too.
[quote name=‘tbirnseth’]However, the walls around the development castle are pretty high and there doesn’t seem to be any interest in actual input or involvement. The castle seems to be soundproof too.[/QUOTE]LOL, I Love it, no worries though, I’ve managed to knock a few bricks out of the castle walls, their is hope on the other side…
tbirnseth, I followed the mentioned example after installing the local.addon:
As an example, to replace the cart’s standard ‘bottom’ section (set of links and other formatting), you would create the file: skins//customer/addons/local/hooks/index/bottom.override.tpl.
and this worked great. Now I would now like to restore the reading of the original bottom.tpl. How is this possible. I tried removing the bottom.override.tpl file and am now getting an error at the bottom of my website:
Warning: Smarty error: unable to read resource: “addons/local/hooks/index/bottom.override.tpl” in C:\xampp\htdocs\lib\templater\Smarty.class.php on line 1095
Blocks and hooks seems to be for developers who want to write addons that add functionality to existing template blocks and components.
If you are just just skinning, there is nothing wrong with modifying the skins directly as long as you keep the “hook” tags as they are, so it won’t break the addons that rely on the hook tags to add additional functionality.
IF YOU ARE CREATING A NEW SKIN
-------------------------------------------------
Don’t worry about all the talk on creating hooks for existing templates.
So if you want to modify bottom.tpl, you can just modify “bottom.tpl” directly in the skins directory.
Don’t worry about:
bottom.override.tpl
bottom.pre.tpl
bottom.post.tpl
that was mentioned by others. Thats for developers who want to create addons and hook into existing templates.
If you are modifying “bottom.tpl”, just make sure the “hook” tag is intact so it won’t break addons that want to hook into bottom.tpl.
[quote name=‘jkj04270’]tbirnseth, I followed the mentioned example after installing the local.addon:
As an example, to replace the cart’s standard ‘bottom’ section (set of links and other formatting), you would create the file: skins//customer/addons/local/hooks/index/bottom.override.tpl.
and this worked great. Now I would now like to restore the reading of the original bottom.tpl. How is this possible. I tried removing the bottom.override.tpl file and am now getting an error at the bottom of my website:
Warning: Smarty error: unable to read resource: “addons/local/hooks/index/bottom.override.tpl” in C:\xampp\htdocs\lib\templater\Smarty.class.php on line 1095[/QUOTE]
Clear your cache. Within your cscart root directory, run the command:
[quote name=‘hykit’]Blocks and hooks seems to be for developers who want to write addons that add functionality to existing template blocks and components.
If you are just just skinning, there is nothing wrong with modifying the skins directly as long as you keep the “hook” tags as they are, so it won’t break the addons that rely on the hook tags to add additional functionality.
IF YOU ARE CREATING A NEW SKIN
-------------------------------------------------
Don’t worry about all the talk on creating hooks for existing templates.
So if you want to modify bottom.tpl, you can just modify “bottom.tpl” directly in the skins directory.
Don’t worry about:
bottom.override.tpl
bottom.pre.tpl
bottom.post.tpl
that was mentioned by others. Thats for developers who want to create addons and hook into existing templates.
If you are modifying “bottom.tpl”, just make sure the “hook” tag is intact so it won’t break addons that want to hook into bottom.tpl.
{hook name=“index:bottom”}
…
{/hook}[/QUOTE]
But based on the info in previous posts, if you modify the “bottom.tpl” (as opposed to making a bottom.overide.tpl) won’t that mean you get conflicts when trying to upgrade?
I thought if bottom.tpl was changed at all, conflicts would arise when upgrading.
[quote]But based on the info in previous posts, if you modify the “bottom.tpl” (as opposed to making a bottom.overide.tpl) won’t that mean you get conflicts when trying to upgrade?[/quote]
That is exactly why you don’t want to modify the templates directly. If you do you will be fighting the update process every time a new update is out.
The “hook” thing is something I am trying to figure out, but I like the thought of hopefully a seemless upgrade process. I could still just be dreaming though.
[quote name=‘spirt’]But based on the info in previous posts, if you modify the “bottom.tpl” (as opposed to making a bottom.overide.tpl) won’t that mean you get conflicts when trying to upgrade?
I thought if bottom.tpl was changed at all, conflicts would arise when upgrading.[/QUOTE]
The whole point of hooks and blocks is that updates or upgrades won’t break your skin changes, and addons can easily hook into your skin without having to modify your skin for each addon.
You are creating your own skin. There’s nothing wrong with modifying the templates directly if you are just theming or skining. Just create a new theme/skin folder.
Upgrades or updates to cs-cart doesn’t affect your skin. As long as you adhere to the standard hooks and blocks, you should be fine.
Unless the guys behind cs-card decides to go crazy and change the standard blocks and hooks, requiring everyone to redo their themes/skins.
The part I do not get is what is telling cs-cart to look in the local/hooks directory? I can not get this to work.
update:
I am curious if it is a cache thing? I got it to work once and then it stopped.
update 2:
OK I figured it out. You need to clear your cache if you change a hook (in 2.0 use &cc to clear your cache). This is quite annoying while developing a new template hook page. Everytime you make a change you need to clear the cache to see it. Anyway around this?
yes, you are correct. One of the disadvantages of the caching implemenation is that it does to determine if the source is newer than the cache. Given the hundreds of nested templates, this would almost be enough overhead to defeat the purpose of the cache.
So yes, when developing and you change any template (or hook), you need to flush the cache. Also there is no way to flush the cache from the Admin panel. Hence you need shell access to be able to remove /var/compiled and /var/cache (though cache probably isn’t necessary).
However, I do believe that if you use the built-in template editor that it will flush the cache for you upon save.