Specials....bug

[MyGamesShop]

Im not too sure if this is still a thing in the latest Phoenix.

If a product has a 'Special' price of 30% and later I increase the base price of the item for inflation by a dollar $1

The price of the item does not change as a 'Special', but the listing base price does on the site.

This is because the 30% is not stored as a % but as a price....

Its a small bug but worth addressing.

Maybe also in the list of specials express as a percentage:

Products Price Offer Price Percentage Status Action

Mark

[ecartz]

If we "fixed" this, we would have people complaining "We updated the base price on our product to match the MSRP, but the special price automatically changed. However, the price we pay for the item didn't change, just the MSRP. We don't want the special price to update. Please fix this bug immediately. It's causing all sorts of problems."

What you are describing isn't a special, as Phoenix describes it. What you are describing is a discount. There may be an add-on that works that way. But you shouldn't expect the core functionality to change to match this use case. It's to match the use case where someone wants to specify the price and have it stay the same.

[MyGamesShop]

Still a bug thou. And a little bit nasty little one that can cost retailers money.

Maybe going forward you could keep it in mind. and separate when a percentage is specified against when a price is specified.

Thanks for you time.

[14Steve14]

Still a bug thou. And a little bit nasty little one that can cost retailers money.

Maybe going forward you could keep it in mind. and separate when a percentage is specified against when a price is specified.

Thanks for you time.

May be worth speaking to one of the certified developers who may be able to create something that works as you want. You could then, with their agreement release it as an addon for others if you think it is that important and would be of benefit to others.

[MyGamesShop]

Sadly its a core issue. If its not fixed there its forever.

But thanks for chiming in, I'm sure others sit on the sidelines here. hiding.

[Kofod95]

Sadly its a core issue.

I disagree.
As Ecartz mentioned, it would be no less a bug, if it worked as you want. In Denmark, it may even be illegal to have it that way, as the regulations for specials are quite harsh.
Further, I don't think it would take too much to code something that adjust the special price with the actual price. This makes it less relevant for core to address it.

//Daniel

[14Steve14]

Sadly its a core issue. If its not fixed there its forever.

But thanks for chiming in, I'm sure others sit on the sidelines here. hiding.

Come up with a suitable fix and pass it on to the developers and they may consider it. Who knows.

If it was made to be an option that could be turned of or on then it may be worth while. If it works release it as an addon so others can use the feature.

[ecartz]

This is not a bug. The feature works as designed. It allows someone to specify a percentage to take off the base price to determine the current special price.

The issue here is that it is possible to misunderstand how the feature works and expect it to do something else. There are some concrete actions that could be taken to mitigate that.

1. Change the text of the page to make it more obvious how the feature works. Current text: "You can enter a percentage to deduct in the Specials Price field, for example: 20%". Note that since this is a translation, this is in fact something that a store owner could simply do. That said, I'm open to changes to the default text in core.
2. Remove the feature. This could be ported from core to an add-on. The add-on could provide more explanation about what it does and does not do.
3. Something larger, like moving the special price from the specials page to the add/edit product page. Then when someone edits the product price, they could see that the specials price was not changing. This could be done as an add-on.

While we might eventually do #3, it's not something that I want to start at this point in the development cycle. #1 is the most feasible now, although I would consider #2.

I'm not open to changing the behavior of the feature in core, as that would just create a new problem. People would then be able to misunderstand that version and expect it to do something else (what it used to do: the current behavior). Removing one feature and replacing it with a seemingly similar feature with different behavior is a really bad idea. Because people might reasonably expect the old behavior to persist. Better to just remove the feature and not to replace it. Then it could be implemented as an add-on.

[burt]

Sadly its a core issue. If its not fixed there its forever.

This isn't true anymore, and hasn't been for many years.
Over time, since the inception of the bootstrap edition in 2016, we've made it so that many (I'd guess over 90% of things) things in core can now be changed by without affecting core code..

I'm in agreement with the others here, this isn't a bug. If we change code to suit this circumstance, we would more than likely end up with other shopowners saying "you've introduced a bug" when their expectation of specials (after it's worked to their needs for a long time) comes as something totally unexpected.

I'm almost certain there used to be an addon that does store specials as %, but I could not find it in the old oscommerce addons. I may be misremembering.

The suggestion to tie down a developer to make what you need is a good one. I can't see any issues that would stop someone from making this, it seems fairly straightforward. In the whole of Phoenix the specials_new_products_price is referenced in just 10 files, so at the most it would be 10 files to change and I know that some of those would be overrideable, so those don't count in terms of "changing core code".

-

The other way would be to reference the specials table when you update a products price. EG;

Price: $10
Special: 20%
Therefore, the base price (stored in special table) is $8

EG If you need to update product price from $10 to $11, you know that's a 10% increase.
Therefore, if a record exists in the specials table for this product, increase that price by 10% also, meaning the specials price (what is stored in special table) increases from $8 to $8.80

This "other way" would definitely and definitively take no core code changes, this could be achieved by a hook.

This hook could also take care of price reductions as well, just takes a reversal of the code.

[raiwa]

I'm almost certain there used to be an addon that does store specials as %, but I could not find it in the old oscommerce addons. I may be misremembering.

https://phoenixcart.org/forum/app.php/ ... _specials/