You are viewing this forum as a guest. Login to an existing account, or create a new account, to reply to topics and to create new topics.
We would like to modify the product detail display and maybe the price display to include some shipping cost info.
Also for different products it would be good to have different displays.
However, can't find anything on this anywhere in the menus - Have I missed this or have the options for tinkering with the detailed product display gone under the hood in K9?
Offline
The product detail display is now in one ecom/include file, prodshow.php. You no longer have the option to create different product detail displays and assign products to them.
The work around I use is to edit the includes/prodshow.php so different displays are created for different product groups.
Offline
Thanks.
Taken a quick look at prodshow.php and I think we can do what we need there - like the idea of creating different displays based on the product group.
Offline
I create a new include and upload to the includes folder - something like prodshow-frames
and then mod the prodshow.php with something like
if ($proddisp['manufacturer']=='frames'){$this->include_file('ecom','prodshow-frames.php');} else {LEAVE ALL THE NORMAL CODE HERE}
Offline
Thanks.
Very neat way of keeping the display files simple and separate.
Offline
I typically mod files in the same fashion, but a little differently. My preference is to put modded files in a scripts directory in the skin, so my mods generally are isolated to the very top of a file, returning output when that file is accessed from a file in my skin directory.
// Kryptronic: Override entire file with copy in skin scripts directory return @include($this->globals('core.path_public') . '/skins/CUSTOM/scripts/prodshow.php');
In your case, /skins/CUSTOM/scripts/prodshow.php might examine the proddisp global and fork to different files based on product type or something. Or you could handle that fork in the main file as Zanart suggested.
Offline
Thanks Nick,
I like the idea of keeping modified files somewhere separate - lots of plus points.
Looks like we can get what we need with a single modified prodshow.php, 2 at most so I will stick with Zanart's suggestion for the fork if needed.
Offline
I like to keep them with the skin for the simple fact that if I run an update, I know which files I need to go back in and touch. I also typically keep a MODLIST.txt file in the {private} directory to track changes as well.
Offline
Interesting topic...
Offline
webmaster wrote:
I typically mod files in the same fashion, but a little differently. My preference is to put modded files in a scripts directory in the skin, so my mods generally are isolated to the very top of a file, returning output when that file is accessed from a file in my skin directory.
I've been following this recommendation and up to this point did not have an issue. However, for some reason in modding CMS_DynForm.php and adding the return @include to point to the modded file I get a blank page. If I were to place the modded file in the actual CMS_DynForm folder, everything works. Although, this is the first non-include file I've modded.
Is there any reason for this to be happening and any alternative suggestions to keep things organized and consistent?
Offline
Including a file in your skin from the top of an include file (like in {private}/core/CORE/includes, {private}/apps/ecom/ECOM/includes, {private}/apps/cms/CMS/includes) was addressed here. You're looking to mod a function in a class file ({private}/apps/cms/CMS_DynForm/CMS_Dynform.php). To handle this cleanly, at the top of the function you're wanting to mod, you can globalize any $input then return a file while contains the modded function code (without the function() wrapper):
// Kryptronic: Override function with replacement in skin scripts directory return @include($this->globals('core.path_public') . '/skins/CUSTOM/scripts/CMS_Dynform_function.php');
Offline