Is overriding priceCalculation method of Product.php the correct way to add custom price?

[Nietypowy Informatyk]

Hi! 

I am working on a module, where users can select parameters etc.
The main issue was to get the custom price (hence parameters can affect price of the product). After lots of trials and errors, here is what I did: 

- I have a class in my module, that is responsible for calculating price.
- When user adds something to the cart (in custom front) - the HTTP request is made, product is added to the cart, and additional data is being saved to my custom table in database, where unit price is stored, parameters info, configuration ID (using native PrestaShop system for that use case)
- Then I overwrote the priceCalculation method in Product.php class - this allows me, to get custom price if it's present in my module table, and return the default one, when product in not using module

What do you guys think about this solution? As I am moving to the end of work on this thing, I want to validate some things. 

Kind regards,
Bartek

[Daresh]

Some interesting technique that I saw in one module for building custom products was to add a new combination to the product with the custom price impact. This way no override is needed and I think that once the order is made, that combination can be deleted.

[Nietypowy Informatyk]

Hmmm, seems interesting... This way (as you said) no override is required, and you don't have to bother with creating customization fields etc. by yourself in order to allow multiple products with "same" id in the cart. 

But after order is placed you might need to get information about that combination in order to well customize it. So I think I wouldn't be able to delete it. Also, this shop has a lot of products, so I would probably be a little scared about performance if I wasn't able to delete it. 

Or am I wrong?

[Daresh]

I think you can safely delete it, as the final data and price gest stored in the order_detail table, so that combination is no longer needed in the product itself.

[Nietypowy Informatyk]

Hmm, that seems interesting! I think it could save myself some issues, if for example something changes in new version of presta or modules. I think I will give it a go. However, let's say for the time of rewrite/changes/adjusting front etc. would it be ok, to use a solution with override? 

Edited February 18, 2023 by Nietypowy Informatyk (see edit history)

[Daresh]

It's your solution so you decide. But override is always the last thing to consider if there are other options available.

[Nietypowy Informatyk]

Because if I understand correctly, combination is just like a copy of the product, but I would be able to set a different price on it, right? If so, would it be possible to somehow mark them as products created by a module, and don't show them in backoffice? As it could cause confusion

[Daresh]

Not exactly a copy and it's not possible to mark it. I think the product should be a special one, that is not much edited in the back office. Of course it all depends on your application. It's a best solution if you have only one product that you use for your customizations.

The case I am thinking about was in a module creating custom phone cases. If you need many products to be customizable this may not be the best pick.

[Nietypowy Informatyk]

My case is a printing house, where each product can have up to 10 parameters, that's why default combinations from presta were not enough - too many records in DB, and whole thing got slow really quickly. But they don't have high traffic, orders are not placed all the time. Can you think of any alternative that wouldn't require override?