copy_to_confirm.php path override fails

I'm creating my own product type and have used /admin/product.php as the base of my own /admin/product_type.php.

I got to overriding copy_to_confirm.php in my /admin/includes/modules/product_type/, but was banging my head on why my code had no effect.

Finally, I made a compare between /admin/product.php and /admin/product_music.php and saw that there was an extra "&product_type=" parameter that seems to correctly get the right path for my product_type module.

The other overrides worked without any problems: collect_info.php, preview_info.php, update_product.php, delete_product_confirm.php.

Is this a bug?

Thanks.

For consistencies sake (and not to stumble future newbies), I propose that line 244 of /ADMIN/product.php be changed from:

$contents = array('form' => zen_draw_form('copy_to', $type_admin_handler, 'action=copy_to_confirm&cPath=' . $cPath . (isset($_GET['page']) ? '&page=' . $_GET['page'] : '')) . zen_draw_hidden_field('products_id', $pInfo->products_id));

to

$contents = array('form' => zen_draw_form('copy_to', $type_admin_handler, 'action=copy_to_confirm&product_type=' . $product_type . '&cPath=' . $cPath . (isset($_GET['page']) ? '&page=' . $_GET['page'] : '')) . zen_draw_hidden_field('products_id', $pInfo->products_id));

It is likely it is a bug. See the comment under heading "/admin/{type_handler}.php" in

smallbusinessconsultingexperts.com/blog/files/zen_cart_new_product_types.php

I think the version in product_music.php can be used safely. I'm creating a new product_type based on product_music.

Ric

I have just spent all day banging my head against the wall with this one <sigh>

So what's the best way to work around this? I have five custom product types all work perfectly except for the copy functionality - which my client is keen to use.

I tried setting

$product_type="product_my_type"; 

as well as

$product_type = zen_get_products_type($_POST['products_id']);

in the product_my_type handler

but that then introduces the following PHP error at the line (somewhere around the 138 - 140 editing probably means the line number is not accurate compared to the base product handler)

require(DIR_WS_MODULES . $zc_products->get_handler($product_type) . '/collect_info.php');

Failed opening required 'includes/modules//collect_info.php'

As you can see $product_type is empty again.

I think this seems to indicate that $product_type is sometimes set and sometimes not set depending on where the handler was called from.

For the moment I am going to tell my client they can't copy custom product types.

If someone knows of a way to fix this (within the custom product code rather than a core file) please let me know.

Hi rebelIT,

If you're having the same problem as me, then edit your /admin/product<your_type>.php file and find the line below that looks like:

$contents = array('form' => zen_draw_form('copy_to', $type_admin_handler, 'action=copy_to_confirm&cPath=' . $cPath . (isset($_GET['page']) ? '&page=' . $_GET['page'] : '')) . zen_draw_hidden_field('products_id', $pInfo->products_id));

and change it to:

$contents = array('form' => zen_draw_form('copy_to', $type_admin_handler, 'action=copy_to_confirm&product_type=' . $product_type . '&cPath=' . $cPath . (isset($_GET['page']) ? '&page=' . $_GET['page'] : '')) . zen_draw_hidden_field('products_id', $pInfo->products_id));

Hi Mate,
I'll check if that works, but the problem I see is if there is some security update in the future for example, that file could be overwritten by the install.

A fix in my custom code would be insulated from future core updates.

Believe me it gets quite complicated to remember any edits to 'core' code of frameworks once you are maintaining a large number of sites. :(

rebelIT, the file you should edit is your own <product_type>.php file. It's not the standard product.php. Therefore, it will not get overwritten by an update.

ah ok, sorry I misunderstood.

Thanks,

That works.

Thanks Kamion

:thumbsup: :cheers: