So I started to implement my new design last night and my goal this time around is hooking in as many of the changes as possible. I quickly discovered that a lot of things dont have hooks so at some point you have to modify the original files (which means modifying them again if a patch makes changes to that file).
So Ive got 3 questions:
How many of you use hooks for design changes and whats your thoughts on them?
Is there a way to use a hook to remove a component that exists in the original file? (For example, cs-cart now has a search bar located in the footer but I do not see a hook for it in bottom.tpl. In order to remove it I am forced to modify bottom.tpl directly which means next patch I’ll have to modify it again).
Assuming Im correct, what seems to be the easiest way post patch to fix files that have changed? I know Jesse likes to just do a file comparison, but often times changed files do include changes we want to keep because of a new feature or bug fix in the original file, so you cant just do a simple compare.
2. Is there a way to use a hook to remove a component that exists in the original file? (For example, cs-cart now has a search bar located in the footer but I do not see a hook for it in bottom.tpl. In order to remove it I am forced to modify bottom.tpl directly which means next patch I’ll have to modify it again).[/QUOTE]
I thought you could make a bottom.override.tpl file and put it in the my_changes addon, have you gotten this to work?
[quote name=‘snorocket’]I thought you could make a bottom.override.tpl file and put it in the my_changes addon, have you gotten this to work?[/QUOTE]
Yes, I am using bottom.override.tpl for the footer changes now (you can see the footer here at test.livingcontemporary.com ) but it doesnt effect the quick links because they use another hook (index:bottom_links) and the search bar doesnt have a hook at all.
I had to remove/comment them out of bottom.tpl directly to get rid of them. I assume this is the only way but Im by no means an expert.
I use hooks as much as I can. By using hooks it makes it so you have less files to change when you upgrade.
Hooks do have advantages and disadvantages.
First, hooks aren’t everywhere so if you want to change something, like remove the search, the only way to do this is to edit the actual code.
Second, if you create a hook that basically replaces the whole file and there are updates to that file for new functionality than you won’t get that new funtionality because your hooks override the default file.
On the other hand, I have about 10 hook files for my site. For the most part upgrades have been pretty easy and painless. I still have a couple of admin files to edit since there aren’t any hooks there and I still have some checkout files to edit since there are also very few hooks for those files as well.
To me, I just want my upgrades to go as smooth as possible. I know that the more I change a store the more work it will be in the future, but if I can limit that amount of work by using hooks than I am that much better off.
@Sno
For some reason CS-Cart starts the hook for the bottom after the search bar so the only way to remove it is to actually go in to bottom.tpl and remove it. The first couple of 2.x series had the hook before the search, but for some reason they changed it. There have been complaints in the bug tracker, but as usual, they have been ignored.
Thanks Brandon that’s the exact type of response I was looking for and pretty much a confirmation of what I already expected.
I was hoping hooks would allow for a hassle free upgrade path, but even if it just makes it easier its worth it (a days worth of extra work now will save me a weeks worth later).
Here is a follow-up question for you… is there a hook for anything in top.tpl? Im not seeing one on the list but Im at the office so I cant look at the tpl directly from here.
I use hooks exclusively for ANY changes. If I need to add a change and there is no hook, I add a hook and use it instead of embeding the changes in standard files (templates or php).
There is one ‘gotcha’ related to hooks that most are not aware of.
Controllers are loaded by priority and then by name. Most have a priority of 1 so the ‘order’ comes from the name.
When an override hook is used, all other prior overrides are tossed as well as any previously set pre/post actions.
With this behavior, if you have two addons (say ‘local’ and ‘my_changes’ both with priority of 1) then any ‘override’ for local will be thrown away and the override for ‘my_changes’ will be used instead.
I don’t agree with this behavior, but it is what is implemented. So if you’ve added an ‘override’ such as bottom.override.tpl and find that it’s not showing, it is probably because a later (or higher priority) addon also has an override for the hook you are trying to use.
Note that for php hooks, you can add an “elevated” priority in the register_hooks() function in init.php of the addon. I.e.
retister_hooks(array('some_hook_name', 200));
This will cause your addon’s hook to run at priority 200 for the ‘some_hook_name’ hook only.
Hooks do make upgrades go faster, for the most part. When creating a hook, don’t automatically jump to the ‘override’ option - if you can use a ‘pre’ or ‘post’ hook, you will benefit from inheriting the changes made in an upgrade. I think the developers are still adding hooks to the code to improve the granularity of the process.
There is a feature request in the Bug Tracker asking that they move the hook in bottom.tpl; I really don’t understand why they have not just done this. Anyone interested could post a comment to “remind” them that we would like to see this addressed:
2. Is there a way to use a hook to remove a component that exists in the original file? (For example, cs-cart now has a search bar located in the footer but I do not see a hook for it in bottom.tpl. In order to remove it I am forced to modify bottom.tpl directly which means next patch I’ll have to modify it again).
[/quote]
Yes, but if you comment well and use your own name for a hook you can remove the potential for conflicts. So if you do:
{hook name="index:zap_search"}
THE STANDARD CODE HERE
{/hook}
And then have an empty file named skins//customer/addons/hooks/index/zap_search.overrride.tpl the the code will be effectively commented out.
3. Assuming Im correct, what seems to be the easiest way post patch to fix files that have changed? I know Jesse likes to just do a file comparison, but often times changed files do include changes we want to keep because of a new feature or bug fix in the original file, so you cant just do a simple compare.
[/quote]
Comment, comment comment… Come up with a standard scheme that is easily reconginzable. I use the following types of comments:
PHP
// EZms added hook 'foo'
TPL
{** EZms added hook 'foo' **}
Pretty easy to then see what I’ve changed versus what is distributed as new changes.
You are the man. I did not realize I could create my own hooks (why did I not know this??)
So the plan is to uncomment out the code I want to remove that doesnt have a hook (such as the footer search bar in this case) and wrap a hook around it (lets says index:zap_search) then create the zap_search override hook file.
So simple, now Im getting excited. I also appreciate your tip regarding comments in existing code that I might have to end up changing. This should be the best practice for anyone making template changes.
[quote name=‘tbirnseth’]Yes, but if you comment well and use your own name for a hook you can remove the potential for conflicts. So if you do:
{hook name="index:zap_search"}
THE STANDARD CODE HERE
{/hook}
And then have an empty file named skins//customer/addons/hooks/index/zap_search.overrride.tpl the the code will be effectively commented out.[/QUOTE]
No problem… I don’t like the behavior of ‘override’ hooks, but other than that, it is a reasonable architecture. If they could do just a couple of things related to templates it would help a lot.
remove any filename duplications. I.e. ‘details.tpl’ in a variety of directories.
Enclose all templates within a hook that would allow someone to replace the entire template with the ‘name’ based on the name of the template file in the appropriate ‘view’ directory.
This would make it very easy for people to cut/paste templates and modify to suit without having ANY upgrade conflicts.