My site is installed using version 3.2.3 Pro. What I need to do is customize the scripting to display a different price on the ordering (signup) page for product P, depending on whether prospective customer is a logged in member. For those who are logged in, I want to display a reduced price that is based on a member status code in the member table. Then if the customer places an order for the product, of course the script must put the offered price into the transmitted order. On the surface, it appears the place to do the customization is the class "product" function "get_price()" in product.inc.php. It looks to be relatively easy to do for a specific product without generalizing it to all products. Any advice welcome. Particularly what to look out for and whether I can count on the scripting to always use get_price() for the base price before coupon discounts.
Actually, it appears there is lots of code that simply uses $var['price']. However, that seems to always follow a get_product call. So, it looks like I need to change get_product to call get_price, and assign the result to the price field in the returned record.
I don't recommend to do this. Create separate product sets for different user's types(use price_group in order to hide these products on default signup/member's pages) Then customize member.php so user will be redirected to correct price_group reneweal form depends on his status.
With the approach I suggested, I have one product, having one database record. All of the pricing differential is limited to one small piece of php code, similar to coupon calculations. Once a sale is completed, all complications disappear. They do not continue to be a complication on into the future. What is the issue with this pricing approach that I don't see? If your approach is a preferred way to do discount pricing, then why not create a new product record every time a coupon is issed? I think the answer to that should be obvious. That approach has a ripple effect that makes a ton of unnecessary work. Not only now, but a continuing headache in the future. For example, my access control setup is a product-id-based (custom) mod-rewrite configuration file. That would be just the first impact. Then there is my accounting system to consider, which I don't even want to think about. Having multiple ids for the same product just has pervasive complications all over the place.
It now looks to me like it would be easier to modify the PriceCalculator to handle a discount other than coupons.
There is only one problem with your approach. User's invoices will never work correctly. All default functionality is included in invoice calculations such as coupons, taxes etc.. If you will change product price use will see incorrect invoices and will probably contact you to check what is wrong.
I don't understand what you are saying about invoices. My local hardware store may sell me widget "x" on Friday for $50, and next month raise the price for widget x to $60. Or, reduce the price to $40. What of it? Prices fluctuate.I see the price at the time I buy and either find it reasonable or not. After purchasing, if I go online to print an invoice of the transaction, I expect the invoice to match the price I paid, not the current quoted price. It appears that amember invoices are generated using the method "get_pdf_invoice". It appears this method gets its information from the relevant row of the amember_payments table. That is exactly as I would expect. I haven't memorized all of the php code, but I would expect the payments table record to be filled in at the time of the sale. If so, it should exactly agree with what was paid. All of this seems perfectly normal to me. I do not see how a member can see an "incorrect invoice". The invoice information is stored in a payment record at a moment in time. It is a historical record and should never change. How would this invoice subsequently turn out to be incorrect? What am I missing? In any event, my proposal was not to change the price in the product record in the database. My proposal was to set a lower price (for some favored members) into the in-memory array that represents the product record read from the database, in the function that reads the product record. That price would be seen only by that customer.