tpl hooks not catching?

I followed this exactly:

[url]http://forum.cs-cart.com/showpost.php?p=59049&postcount=6[/url]



Yet it doesn’t seem to be kicking in.

I added /public_html/skins/new_skin/customer/addons/my_changes/index/bottom.post.tpl



And absolutely nothing happens to the page…



What am I missing? My Changes addon is added and active.





EDIT:

Ok, so I put the hooks folder in and still nothing

/public_html/skins/new_skin/customer/addons/my_changes/hooks/index/bottom.post.tpl



But then I tried switching the skin to another and then back again, and wahlah, it worked.



So I guess it’s caching the page on first view. How can I make it so I can view changes right away while making mods here and there?

The path to your hook is not quite right. Try /skins/YOURSKIN/customer/addons/my_changes/[COLOR=“Red”]hooks/[/COLOR]index/bottom.post.tpl



Bob

Yup, I had fixed that, it seems to be a caching issue. Is there a way to disable caching temporarily?



EDIT:

A few observations.

If I’m in customization mode, and I click the tpl file and edit it, it shows the proper content, but when I click save, there are no changes. If I edit any other tpl files the changes show up right away.

OTOH, if I edit the file via the ftp and refresh, it shows up right away so I guess it doesn’t cache in that mode.

In /lib/templater/Smarty.class.php, change:

/**
* This forces templates to compile every time. Useful for development
* or debugging.
*
* @var boolean
*/
var $force_compile = [B][COLOR="Red"]true[/COLOR][/B];




Bob

Nice :smiley:



Many thanks.

[quote name=‘jobosales’]In /lib/templater/Smarty.class.php, change:

/**
* This forces templates to compile every time. Useful for development
* or debugging.
*
* @var boolean
*/
var $force_compile = [B][COLOR="Red"]true[/COLOR][/B];




Bob[/QUOTE]

Why not just add a ‘cc’ parameter to the end of any URL (prefixed by ‘?’ if the first parameter or ‘&’ otherwise). This will clear the compiled and cache directories and cause them to be rebuilt on next access (the current page).

[quote name=‘tbirnseth’]Why not just add a ‘cc’ parameter to the end of any URL (prefixed by ‘?’ if the first parameter or ‘&’ otherwise). This will clear the compiled and cache directories and cause them to be rebuilt on next access (the current page).[/QUOTE]

He was looking for a way to disable template caching while developing; this forces compilation so your pages are always based based on your most current changes but it does slow things down so is not good for a live store.



Bob

Okay, seemed to have missed that subtle point! :slight_smile:

I guess I’d ask “why”? The caching seems to be partial at best (though it really does speed things up a lot). But it is mostly language related. I can modify a hook or even a main view and I almost always (but not always) see those changes without flushing the cache. Sure be nice to know what’s really cached and what isn’t.

I was using my_changes folder with hooks. The thing is, it wasn’t updating the changes. When I changed it, nothing happened. I thought the hooks just weren’t working the first time. Then I tried switching the skin and switching back again; then the changes showed up. So I knew it was a caching issue. Even when in design mode, if I edit the modified bottom.post.tpl that I was originally working on, it doesn’t save or update the edits. I have to edit it via ftp.

[quote name=‘phazei’]I was using my_changes folder with hooks. The thing is, it wasn’t updating the changes. When I changed it, nothing happened. I thought the hooks just weren’t working the first time. Then I tried switching the skin and switching back again; then the changes showed up. So I knew it was a caching issue. Even when in design mode, if I edit the modified bottom.post.tpl that I was originally working on, it doesn’t save or update the edits. I have to edit it via ftp.[/QUOTE]



when adding a new hook, you almost always have to flush the cache by adding a ?cc or &cc parameter to a URL in your store. After the hook is in place and the cache is flushed, changes within the hooked file should not require a cache flush since they are read dynamically.



Note that if another addon has an override hook it will throw away any pre, post or override hooks you have set if your addon is of lesser priority the the other override. This is a design flaw in the implementation and they are unwilling to change it because it will break too many things.

tbirnseth-



He simply does not want to rely on having to remember to flush the cache while in development where he is possibly making incremental changes to the same code. It is, in fact, the reason it is possible to set the ‘force_compile’ variable in Smarty.



It is not likely that you forget to unset it afterwards as it makes the cart substantially slower.



Bob

Substantially slower. I used it for a while but then my boss complained since he was trying to enter in a lot of products while I was working on the front end. So at certain times of the day I use ?cc and other periods i force compile when he’s not on it.



So it’s nice to have both :slight_smile: