Jump to content

  • You cannot start a new topic
  • You cannot reply to this topic

Your Add-On Needs A New Hook In Cs-Cart. Post It Here. Rate Topic   * * * * * 1 votes

 
  • fdo
  • Member
  • Members
  • Join Date: 12-Aug 15
  • 42 posts

Posted 23 June 2017 - 04:01 PM #121

We do not add extra hooks to update.tpl because all extra data should be placed to "Addons" tab, or at least at the end of the page.

From my experience if we do so - we should wrap each field in hook - and this is not a good style, which also will affect performance.

 

I gotta chime in here to explore a couple thoughts. The end of this is the kicker, i will put a dollar amount to this ;)

 

Its lesser performance indeed, but its far greater UX, there are less hooks there compared to catalog product side, and admin isnt really optimized/performant anyways like the front is. The UX for example -- if a customer is working with pricing fields from 3 addons it may require them to jump to 2 different spots in product edit then scroll around addon tab to find the 3+ extra fieldsets (since addon priority may not be the same for all 3)

 

So that means in theory an addon tab could have collapsible fieldsets ordered like this (depending on priorities):

 

some mod

some mod

some mod

pricing addon 2

some mod

some mod

pricing addon 3

some mod

some mod

some mod

some mod

some mod

pricing addon 1

some mod

 

When it could be like this in the initial wrapped price block, far greater usability, far cleaner, far less confusing to new OP's:
 

default price fields

pricing addon 1

pricing addon 2

pricing addon 3

 

 

So basically, just 4 hook wraps would help immensely:

price fieldset

options fieldset

inventory fieldset

availability fieldset

 

I would also suggest splitting out pricing and inventory fieldsets, as they are 2 different things. And moving price field into the price fieldset. Its slow to scroll up/down to enter price and list when you could just hit "tab" once to jump to the list field below. 4 solid areas.

 

BONUS: The reason im saying this, besides UX and clean integrate/design, is the time added up over a year for a staff to scroll around. Lets use an example 10 people adding/changing/touching products that must adjust price, list, and the 3 example pricing addons above. Lets say it takes them 3 seconds of scrolling/looking/etc for each product (just time looking for those scattered fields). Thats 30 seconds per 10 people, and they do, say 30 products a day each.

 

Thats 15 minutes of time a day that is wasted scrolling around. Multiply that by an average work year and you come out with 65 hours of time a year just scrolling for those example scattered price fields. Im sure that chunk of change is huge for any sort of business....$10 an hour comes out to $650 dollars. The price of scrolling is not cheap for a big OP team. Multiply that by every CS-Cart OP that has ever had to scroll for some kinda example pricing addon, and you get the idea. for that kinda money down the drain, its absolutely worth it to put in those trivial hooks IMO.

 

Thanks for bearing with me :)



 
  • tbirnseth
  • CS Cart Expert
  • Authorized Reseller
  • Join Date: 08-Nov 08
  • 11266 posts

Posted 23 June 2017 - 06:27 PM #122

Create an 'override' template and change it as you want (you could even just add whatever hooks you want there for even greater flexibility/readability).  Upon upgrade you will have to determine if changes occurred to the standard template and if so, merge those changes into your override template.

 

I don't think there are multiple pricing addons in 99% of installations and if you're doing this as a production addon, then you would have to verify your addon with each new version of cs-cart released.  Multiple product_codes also seems odd given that a product_code (SKU) is intended to be a unique identifier.  You might consider how you're managing your products/suppliers and switch the reference to a more standard object identifier like GTIN (UPC).


EZ Merchant Solutions: Custom (USA based) B2B Development, Consulting, Development and Special Projects (get a quote here).
Commercial addons, payment methods and modifications to meet your business and operations needs.


 
  • imac
  • Head of Product
  • CS-Cart Architects
  • Join Date: 22-Nov 05
  • 2047 posts

Posted 11 July 2017 - 01:18 PM #123

I gotta chime in here to explore a couple thoughts. The end of this is the kicker, i will put a dollar amount to this ;)

 

Its lesser performance indeed, but its far greater UX, there are less hooks there compared to catalog product side, and admin isnt really optimized/performant anyways like the front is. The UX for example -- if a customer is working with pricing fields from 3 addons it may require them to jump to 2 different spots in product edit then scroll around addon tab to find the 3+ extra fieldsets (since addon priority may not be the same for all 3)

 

So that means in theory an addon tab could have collapsible fieldsets ordered like this (depending on priorities):

 

some mod

some mod

some mod

pricing addon 2

some mod

some mod

pricing addon 3

some mod

some mod

some mod

some mod

some mod

pricing addon 1

some mod

 

When it could be like this in the initial wrapped price block, far greater usability, far cleaner, far less confusing to new OP's:
 

default price fields

pricing addon 1

pricing addon 2

pricing addon 3

 

 

So basically, just 4 hook wraps would help immensely:

price fieldset

options fieldset

inventory fieldset

availability fieldset

 

I would also suggest splitting out pricing and inventory fieldsets, as they are 2 different things. And moving price field into the price fieldset. Its slow to scroll up/down to enter price and list when you could just hit "tab" once to jump to the list field below. 4 solid areas.

 

BONUS: The reason im saying this, besides UX and clean integrate/design, is the time added up over a year for a staff to scroll around. Lets use an example 10 people adding/changing/touching products that must adjust price, list, and the 3 example pricing addons above. Lets say it takes them 3 seconds of scrolling/looking/etc for each product (just time looking for those scattered fields). Thats 30 seconds per 10 people, and they do, say 30 products a day each.

 

Thats 15 minutes of time a day that is wasted scrolling around. Multiply that by an average work year and you come out with 65 hours of time a year just scrolling for those example scattered price fields. Im sure that chunk of change is huge for any sort of business....$10 an hour comes out to $650 dollars. The price of scrolling is not cheap for a big OP team. Multiply that by every CS-Cart OP that has ever had to scroll for some kinda example pricing addon, and you get the idea. for that kinda money down the drain, its absolutely worth it to put in those trivial hooks IMO.

 

Thanks for bearing with me :)

You can always use in JS in case you need it so much. And this would be your responsibility the same as with override hook.

but CS-Cart position is that core properties should be the way the intended to be. In any CS-Cart installation. 

The more such injections we have the more problems with upgrade we get.


Ilya Makarov,
CS-Cart Architect Team
Suggest and vote for new features | Report a bug

 
  • fdo
  • Member
  • Members
  • Join Date: 12-Aug 15
  • 42 posts

Posted 18 July 2017 - 02:35 PM #124

You can always use in JS in case you need it so much. And this would be your responsibility the same as with override hook.

but CS-Cart position is that core properties should be the way the intended to be. In any CS-Cart installation. 

The more such injections we have the more problems with upgrade we get.

 

Hmm interestingly there are already hooks in the product update.tpl that go against your thoughts and apparently core properties ;) The `{hook name="products:update_seo"}` is doing exactly what we are suggesting, and its not using the addons tab, so i dont understand why its a big deal to do the same for availability and stuff. Also, how are 2-3 TPL hooks going to cause more problems with upgrades? Why are you guys even asking for more hooks if injections cause problems? Wouldnt JS and theme overriding cause more problems than a line in TPL defining a native/clean hook?

 

I do have another hook request though, for proceed to checkout button availability (/views/checkout/components/cart_content.tpl). There should be a hook here or some other var to control the state of checkout button at cart, rather than just relying on payment methods. Perhaps it could piggy with allow_place_order(). The reason this is a good thing is because some addons such as quoting systems must control checkout state. 

{if $payment_methods}
	{assign var="m_name" value="checkout"}
	{assign var="link_href" value="checkout.checkout"}
	{include file="buttons/proceed_to_checkout.tpl" but_href=$link_href}
{/if}

Thanks



 
  • tbirnseth
  • CS Cart Expert
  • Authorized Reseller
  • Join Date: 08-Nov 08
  • 11266 posts

Posted 18 July 2017 - 06:16 PM #125

Why not use a 'get_payments_post' hook (or probably a post controller) to simply set {$payment_methods} to array()?

That would localize the code and allow you to apply whatever logic you wanted and also give you backward/forward compatibility rather than having to wait for a release with your template hook supported.

 

There is always more than one way to skin a cat.


EZ Merchant Solutions: Custom (USA based) B2B Development, Consulting, Development and Special Projects (get a quote here).
Commercial addons, payment methods and modifications to meet your business and operations needs.


 
  • tbirnseth
  • CS Cart Expert
  • Authorized Reseller
  • Join Date: 08-Nov 08
  • 11266 posts

Posted 30 August 2017 - 06:38 PM #126

Please add the following hook to addons/vendor_plans/func.php to the function fn_calculate_commission_for_payout().

 

fn_set_hook('vendor_plans_calculate_commission_for_payout', $commission, $total, $shipping_cost, $surcharge, $order_info, $company_data, $payout_data);
$commission_amount = ($total - $shipping_cost) * $commission / 100;

 

I only plan to use the '$commission' parameter, but given it's a hook might as well support the other calculation parameters as well.

Please advise if you will not be implementing this exactly as above since I'll be modifying the core file until the hook is added by you.


EZ Merchant Solutions: Custom (USA based) B2B Development, Consulting, Development and Special Projects (get a quote here).
Commercial addons, payment methods and modifications to meet your business and operations needs.


 
  • imac
  • Head of Product
  • CS-Cart Architects
  • Join Date: 22-Nov 05
  • 2047 posts

Posted 14 September 2017 - 07:18 AM #127

Please add the following hook to addons/vendor_plans/func.php to the function fn_calculate_commission_for_payout().

fn_set_hook('vendor_plans_calculate_commission_for_payout', $commission, $total, $shipping_cost, $surcharge, $order_info, $company_data, $payout_data);
$commission_amount = ($total - $shipping_cost) * $commission / 100;

I only plan to use the '$commission' parameter, but given it's a hook might as well support the other calculation parameters as well.

Please advise if you will not be implementing this exactly as above since I'll be modifying the core file until the hook is added by you.

 

Please add the following hook to addons/vendor_plans/func.php to the function fn_calculate_commission_for_payout().

fn_set_hook('vendor_plans_calculate_commission_for_payout', $commission, $total, $shipping_cost, $surcharge, $order_info, $company_data, $payout_data);
$commission_amount = ($total - $shipping_cost) * $commission / 100;

I only plan to use the '$commission' parameter, but given it's a hook might as well support the other calculation parameters as well.

Please advise if you will not be implementing this exactly as above since I'll be modifying the core file until the hook is added by you.

To modify vendor plan data you should use 'vendor_plan_get_list' and 'vendor_plan_get_list_post' hooks in VendorPlan class.


Ilya Makarov,
CS-Cart Architect Team
Suggest and vote for new features | Report a bug

 
  • tbirnseth
  • CS Cart Expert
  • Authorized Reseller
  • Join Date: 08-Nov 08
  • 11266 posts

Posted 14 September 2017 - 06:12 PM #128

That doesn't allow me to modify the product commission portion of the commission amount only.

 

My need is to be able to optionally assign category and product specific commissions that will be applied to the total vendor commission.

 

I'd rather have this structured so that the various commission components can be set individually and then you can aggregate them before updating the vendor_payouts.  But given that you don't provide this capability, I would like to be able to make the appropriate "adjustments" to the commission BEFORE you save it to the DB.

 

Example: Vendor commission for their plan is set at 50%.  Merchant has a category where they want to override this and only payout 30% on products in that category.  I need a hook where I can can capture the commission on products (which you don't provide) and adjust it for the different rate for those products.

 

You calculate commission on 'total' which provides zero granularity and then optionally add in shipping and/or payment_surcharge.  Would like to see this done more granularity so different components can have different commission rates.

 

Not asking you to provide that functionality, only to provide data/hook in a form where it can be done.

 

I'm trying to avoid having to update the vendor_payout table directly since this will cause headaches down the road.


EZ Merchant Solutions: Custom (USA based) B2B Development, Consulting, Development and Special Projects (get a quote here).
Commercial addons, payment methods and modifications to meet your business and operations needs.


 
  • tbirnseth
  • CS Cart Expert
  • Authorized Reseller
  • Join Date: 08-Nov 08
  • 11266 posts

Posted 20 September 2017 - 06:21 PM #129

Actually, I'd like to alter this request to simplify it a little. I would like the hook to become:

  $payout_data['commission_type'] = 'P'; // Backward compatibility
  fn_set_hook('vendor_plans_calculate_commission_for_payout_post', $payout_data, $order_info, $company_data);
}

EZ Merchant Solutions: Custom (USA based) B2B Development, Consulting, Development and Special Projects (get a quote here).
Commercial addons, payment methods and modifications to meet your business and operations needs.


 
  • imac
  • Head of Product
  • CS-Cart Architects
  • Join Date: 22-Nov 05
  • 2047 posts

Posted 25 September 2017 - 05:51 AM #130

 

Actually, I'd like to alter this request to simplify it a little. I would like the hook to become:

  $payout_data['commission_type'] = 'P'; // Backward compatibility
  fn_set_hook('vendor_plans_calculate_commission_for_payout_post', $payout_data, $order_info, $company_data);
}

Tony,

 

In order to change commission value, which is stored in 'vendor_payouts' table you can use hook in `VendorPayouts::update`: 

`vendor_payouts_update_pre`

`vendor_payouts_update`

They are available since 4.5.1 in Multi-Vendor.


Ilya Makarov,
CS-Cart Architect Team
Suggest and vote for new features | Report a bug

 
  • tbirnseth
  • CS Cart Expert
  • Authorized Reseller
  • Join Date: 08-Nov 08
  • 11266 posts

Posted 25 September 2017 - 07:01 PM #131

Unfortunately, that hook does not provide access to the $order_info used in the calculation.

I realize you want to keep number of hooks to a minimum if the problems can be addressed in different ways, but I really need to recalculate the commission on the order and I don't think using a fn_get_order_info() on the order_id from the data will insure that I'm working with exactly the same order data this is used in the initial computation.

 

Please provide the hook I requested in #129 above or advise how I can accomplish my goals in another way.


EZ Merchant Solutions: Custom (USA based) B2B Development, Consulting, Development and Special Projects (get a quote here).
Commercial addons, payment methods and modifications to meet your business and operations needs.


 
  • tbirnseth
  • CS Cart Expert
  • Authorized Reseller
  • Join Date: 08-Nov 08
  • 11266 posts

Posted 29 September 2017 - 10:46 PM #132

Tony,

 

In order to change commission value, which is stored in 'vendor_payouts' table you can use hook in `VendorPayouts::update`: 

`vendor_payouts_update_pre`

`vendor_payouts_update`

They are available since 4.5.1 in Multi-Vendor.

Still awaiting response.  Not sure why the push back on adding a hook to the calculation routine when I need to alter the calculation.

As stated above, the vendor_payouts_update hook does not provide the order_info used for the calculation.....  In addition, I only need to update on calculation, not other things like status changes, etc.


EZ Merchant Solutions: Custom (USA based) B2B Development, Consulting, Development and Special Projects (get a quote here).
Commercial addons, payment methods and modifications to meet your business and operations needs.


 
  • mschekotov
  • Architect
  • CS-Cart Architects
  • Join Date: 06-Aug 15
  • 12 posts

Posted 06 October 2017 - 06:11 AM #133

Hello, tbirnseth.

 

The following hook will be added into the fn_calculate_commission_for_payout function in the next version of Multi-Vendor:

        ...
        $payout_data['commission_type'] = 'P'; // Backward compatibility
        
        fn_set_hook('vendor_plans_calculate_commission_for_payout_post', $order_info, $company_data, $payout_data);
    }

    return $payout_data;

Please, note that the hook will have the same arguments order as the function itself has.


Michael Schekotov,
CS-Cart Architect Team
Report a bug


 
  • tbirnseth
  • CS Cart Expert
  • Authorized Reseller
  • Join Date: 08-Nov 08
  • 11266 posts

Posted 06 October 2017 - 06:37 PM #134

Thank you


EZ Merchant Solutions: Custom (USA based) B2B Development, Consulting, Development and Special Projects (get a quote here).
Commercial addons, payment methods and modifications to meet your business and operations needs.


 
  • tbirnseth
  • CS Cart Expert
  • Authorized Reseller
  • Join Date: 08-Nov 08
  • 11266 posts

Posted 16 October 2017 - 10:18 PM #135

Can you please add a template hook that surrounds the order_info.shipping area of both the frontend and backend order invoices (old style mail templates)?  I.e. mail/templates/orders/invoice.tpl

 

[code=auto:0]

{hook name="orders:invoice_shipping"}

{if $order_info.shipping}

  <tr valign="top">

  ....

{/if}

{/hook}

 

Goal is to use pre/post to add data rows to this area of the template such as PO/customer numbers, etc.  And I'm sure others might want to override the shipping data presentation too.


EZ Merchant Solutions: Custom (USA based) B2B Development, Consulting, Development and Special Projects (get a quote here).
Commercial addons, payment methods and modifications to meet your business and operations needs.


 
  • eComLabs
  • CS-Cart Expert
  • Authorized Reseller
  • Join Date: 27-Jan 14
  • 19161 posts

Posted 17 October 2017 - 05:52 AM #136

Hooks to extend static data are required

 

- design/backend/templates/views/static_data/update.tpl

{hook name="static_data:update"}{/hook}

app/functions/fn.common.php

 

-- fn_delete_static_data

fn_set_hook('delete_static_data', $param_id);

-- fn_get_static_data

fn_set_hook('get_static_data_post', $s_data, $params,  $lang_code);

Thanks


GET A FREE QUOTE | CS-Cart Add-ons | CS-Cart Licenses | CS-Cart Development | CS-Cart Design | Server Configuration | UniTheme and YOUPI
CS-Cart                USD 345     Multi-Vendor              USD 1250    CS-Cart RU                         24500 руб.
CS-Cart Ultimate  USD 775     CS-Cart + YOUPI      USD 545      CS-Cart RU + UniTheme    36000 руб.


 
  • judoscott
  • Advanced Member
  • Members
  • Join Date: 19-Mar 16
  • 83 posts

Posted 18 October 2017 - 08:13 PM #137

A hook in fn_start_payment would be useful for me to add some business logic to payments.

 

I have a situation where I might need to make two payment requests.

 

Here's an example:

  • The customer adds a candy bar and a shirt to their cart.
  • We have a promo on the shirt that if you purchase it with a card ZZZ they get 0 interest.
  • In order to get that I have to send the processor a special code with the relevant amount.
  • Customer checks out and uses the card ZZ
  • Now I need to split that payment request up.


 
  • imac
  • Head of Product
  • CS-Cart Architects
  • Join Date: 22-Nov 05
  • 2047 posts

Posted 25 October 2017 - 01:11 PM #138

Can you please add a template hook that surrounds the order_info.shipping area of both the frontend and backend order invoices (old style mail templates)?  I.e. mail/templates/orders/invoice.tpl

 

[code=auto:0]
{hook name="orders:invoice_shipping"}
{if $order_info.shipping}

  <tr valign="top">

  ....

{/if}

{/hook}

 

Goal is to use pre/post to add data rows to this area of the template such as PO/customer numbers, etc.  And I'm sure others might want to override the shipping data presentation too.

Hi Tony,

 

I see there 

{hook name="orders:totals"}
{/hook}

Right after the shipping line. I suppose you need the hook you've described because you want to display a row before the shipping info?

I created a task for this hook. Also we will add hook for tax row. Will let you know when its finished.

 


Ilya Makarov,
CS-Cart Architect Team
Suggest and vote for new features | Report a bug

 
  • imac
  • Head of Product
  • CS-Cart Architects
  • Join Date: 22-Nov 05
  • 2047 posts

Posted 25 October 2017 - 01:17 PM #139


 

Hooks to extend static data are required

 

- design/backend/templates/views/static_data/update.tpl

{hook name="static_data:update"}{/hook}

app/functions/fn.common.php

 

-- fn_delete_static_data

fn_set_hook('delete_static_data', $param_id);

-- fn_get_static_data

fn_set_hook('get_static_data_post', $s_data, $params,  $lang_code);

Thanks

Hooks to functions will be added.

Regarding template hook. If you need to override all template why don't you use http://docs.cs-cart....hlight=override ?


Ilya Makarov,
CS-Cart Architect Team
Suggest and vote for new features | Report a bug

 
  • imac
  • Head of Product
  • CS-Cart Architects
  • Join Date: 22-Nov 05
  • 2047 posts

Posted 25 October 2017 - 01:21 PM #140

 

A hook in fn_start_payment would be useful for me to add some business logic to payments.

 

I have a situation where I might need to make two payment requests.

 

Here's an example:

  • The customer adds a candy bar and a shirt to their cart.
  • We have a promo on the shirt that if you purchase it with a card ZZZ they get 0 interest.
  • In order to get that I have to send the processor a special code with the relevant amount.
  • Customer checks out and uses the card ZZ
  • Now I need to split that payment request up.

 

I don't like the idea of hooks in fn_start_payment. This function is kind of business logic that should not be altered. 

Can you use "checkout_place_orders_pre_route" to add you second payment processing - where you will call fn_start_payment again.


Ilya Makarov,
CS-Cart Architect Team
Suggest and vote for new features | Report a bug