Magento2: Configurabel products special price bug

[andidhouse]

Preconditions

1. Magento version 2.1.7 via download
2. Nginx, PHP7, varnish, redis

Steps to reproduce

1. Create one configurable product with 3 size articles (simple products) under this article
2. Give the simple products /and or the configurable products a special price and also fill "special price from/to"

Expected result

1. If you choose one of the size articles over the dropdown in the frontend of course the special price is set for each product.

Actual result

1. If you choose a size product over the dropdown in the frontend not the special price is shown but the normal price AND the normal price crossed out

See screen 1 for backend configuration
See screen 2 for article in frontend without choosing a size
See screen 3 for choosing a size over the dropdown in the frontend.

I really hope this is a misconfiguration on our side (but where?) - because if this is a bug special prices are not usable for configurable products.

Thanks for a feedback!

[andidhouse]

@veloraven thanks for flagging this.

Is this really a bug? I hoped it is a misconfiguration at our side so we can fix this quick.
If it is a bug is there a workaround?

Thanks for pointing this out!

[1408sheva]

Hi, @andidhouse. I cannot reproduce this issue. Please add more details to your description of the steps you followed when identifying this issue. Screenshots or logs would be helpful, too.

[andidhouse]

hi @1408sheva thanks for the feedback.

Could you pls change the Virtual products into simple products - lets see if it works then.

Log files do not report anything here.

[1408sheva]

@andidhouse okay))

[andidhouse]

@1408sheva can you pls set the price of the configurable product to 100 and not to 77 - this is the normal price not the special price ;-).

I am not shure what screenshots i should post here? Let me know which ones you need and i will post them.

[1408sheva]

You can not change the price of the Configurable Product! It depends on children's (simple) products

[andidhouse]

Hi there,
first - we tested now on 3 brand new installed 2.1.7 systems - all with the same results.

Pls see screen attached - the price of the configurable product should be grayed out and not not be visible like in you screenshot right? And you can change the price - over attribute mass actions.
But what should be in the normal price of the configurable product?
a) nothing (like in your screenshot)
b) a greyed out price
c) the normal price or like in your case the special price in the normal price field?
Pls see screen 1 attached for the greyed out price

At another new system the "old price is by default set to a "display none" class - why is that and is that reproducible in you system? I think this is a bug too right?
See screen 2

Screen 3 shows that the data-price-amount of the special price is 50 (the right special price) but the outputted special price is 100 - the normal price - when a dropdown is chosen.

Are you really using a normal 2.1.7 system or is this adapted somehow? We reproduced this now on 3 systems - all work exactly like the same wrong behavior.

[1408sheva]

@andidhouse. Unfortunately, I could not reproduce the issue as you described it.
Try to reproduce it on fresh Magento)

[andidhouse]

Maybe anyone else could test it as well?

@1408sheva But i see you run into another bug. If your do not choose a value in the dropdown only the price 77 $ is displayed? There should be also the former price and the 77 as a special price? This is the "display none" bug i talked before.

Or what explanation is for that to just present the 77?

Can you also pls post a screen from your grid list of the product and price - i suggest here is also a wrong special price shown.

[jordanbrauer]

@andidhouse I don't have this _exact_ problem - however I do have a configurable product issue with pricing in regards to multi-currency stores. Perhaps it is related and can aid in figuring out this bug with configurable product prices? The issue is as follows,

The exchange rate is applied twice to a product on the catalog pages & product pages unless one of the following conditions are met:

• The configurable product is added to the cart. The price will properly display in the cart.
• The configurable product has a configuration selected and is not "unconfigured". The price will then properly display on the product page.

---

@korostii Totally inappropriate and unrelated. You're obviously having a bad day. This is not the forum to vent your frustrations on others. If you don't have anything to add to the current discussion, don't comment at all - doing so will benefit you well in your future endeavours. This is just embarrassing.

[Boyiko777]

@korostii Is this a solution to a problem.
About all I can tell you is that, just like the female of the species, cattle love to yammer and gossip or sulk.
You're probably one of them

[korostii]

Totally inappropriate and unrelated. You're obviously having a bad day.
Yes, you're totally right. Sorry for that, not even sure myself why I snapped like that. Will think twice before posting next time.

Maybe I just overreacted when saw the good old boilerplate "are you able to reproduce the bug on a clean instance" response used for 1000th time in order to avoid investigating a bug.

By the way, I think the issue might actually be caused by a conflict of core JS functionality with theme's styles. (Like, for example, the no-display class not having a display: none; counterpart in CSS).

[andidhouse]

This is also shown wrong on the luma theme here - so i think this should be no template bug.

I suggested the magento team several times to setup test server for exact this cases. So we can login in these and have a exact look if this is also happening here.

This was declined every time by the magento team and now we have the "ping pong" going on again in every reported issue. What system do you use, which magento version, what configuration etc. etc.

It would be so easy just to setup 20 test server which reset themselves after a while - but i think the magento team has no interest in a easy bug flow reporting. You can see bugs reported and confirmed here which are one year old or even older - and internal tickets are created by magento but i just think the developers have no priority to fix these - for whatever reason. How can you you release a last version with only a security update and the update before this may have fixed about 10 bugs... if it is going on like this magento2 will be bug free in 2027 i think - maybe ;-)

[Boyiko777]

@andidhouse Make a contribution to Magento (financial (magento enterprise edition)), and get round-the-clock support (24/7)!)

[jordanbrauer]

Agreed @andidhouse. I have a couple of ideas/thoughts as to why the bug reporting and resolving is so horrible for Magento.

Process

Their bug flow reporting method is definitely less than optimal. I recall the Magento team saying awhile back that they had revamped their bug flow reporting process - which seems to me that the they've opted to reinvent the wheel instead of using a well documented process that already exists.

Demographic

The development team appear to be a majority of Europeans whilst the users (us) are majority Americans. In my eyes, this could potentially lead to many issues, such as;

• poorly named, organized and optimized code (see Craft 2/3 vs Magento 1/2 codebases)
• different priorities based on the business needs of a given region - whether this is due to technology or business practices, it doesn't matter, countries do business differently than others.
• language barriers could cause bugs that are unique to be tagged as duplicates.

Roadmap

Why is Magento Cloud a thing when there are so many problems in CE and EE? Spreading themselves too thin.

In summary, it seems the Magento team is too small/unorganized to manage a project of this size.

---

@Boyiko777 A sister branch at my company uses EE. After discussing with them a few months ago about the benefits it offers, they confirmed that the bug resolution and issue reporting is the exact same as CE. It's not the edition, it's the dev team.

[andidhouse]

@jordanbrauer i suggested also al lot of to speed up the process for all sites and also Allen Kent from the @magento-team promised that they improve the process - but for me it got worse and not better.

https://community.magento.com/t5/Just-Ask-Alan/Alan-When-will-there-be-a-really-stable-version-of-Magento2/td-p/56617

[jordanbrauer]

@andidhouse Haha wow. You just got brushed off with some PR bull shit right there.

Maybe it's time to jump ship then ... ¯_(ツ)_/¯ Shitty thing is that there are not any good ecommerce systems. I'd argue that Shopify is your closest thing to "perfect".

[1408sheva]

@andidhouse. Please provide detailed steps with all actions you do during product creation and specifying all values used in the product.
As I can see from screenshots your configurable product has another configurable attribute (swatches) but you did not mentioned it. So some information seems to be missed.
Did you create a configurable product at once or converted it from existing simple product? Did you create configurable attributes separately, or during product creation?

[korostii]

@1408sheva, I just had a wildest idea: would a screen-cast (video) recorded by @andidhouse, showing him reproduce the issue on a clean installation be enough for you to acknowledge the bug?

internal tickets are created by magento but i just think the developers have no priority to fix these - for whatever reason

Yes, I'd guess most of these have the lowest priority in their internal JIRA unlese there's like a few dozens of users complaining about it - which might still be not enough (see the the duplicate URL key threads). Their managers probably don't see value in bugfixing because it doesn't attract new customers directly.

It's not the edition, it's the dev team

Well yes, I agree that both CE and EE are slow on the bugfixing front. But I'd like to comment on the other part.
If you take a look at the PRs getting processed, there's obviously some quality work being done, but there's just 4 or 5 devs in their "community engineering team. And even those aren't full-time bugfixing, they're also developing this "multi-source inventory" thing in parallel.

I'd say it's mostly a matter of management priorities: Magento, Inc.'s management decided to put most of its resource (which is hundreds of developers, presumably) on the release of 2.2 in general, and some new B2B modules and BIE in particular. They're obviously hoping to score some new higher-tier paying customers ASAP and deal with customer support later (as in: force everyone to switch to 2.2 and drop 2.1 support completely).

I mean, the move to "close those old 2.1.x issue reports for good, at any cost" attitude is quite obvious, really.

[magento-engcom-team]

@andidhouse, thank you for your report.
We were not able to reproduce this issue by following the steps you provided. If you'd like to update it, please reopen the issue.
We tested the issue on 2.2.0, 2.1.9

[andidhouse]

I think testing on 2.2 or 2.1.9 is not really useful.
Imagine this is really a bug in 2.1.7 - and for some reason this is not valid any more in 2.2. - so far so good but we have seen so many bugs appearing again and again here after closing reports here that i think the far better way would really test the bugs reported on the versions reported. Then make a clear investigation why this is happening and also check if this is fixed in the current version.

So you can be shure to get rid the root of the problem. In your way of solving bugreports you can never be shure this bug is not introduced in a future version again... and we have seen this so many times.

[korostii]

@andidhouse Well yes, that makes sense.
Except for the fact that the resources assigned to investigate older issues are limited to the level where they don't really care if the issue is present on older versions - as long as it's not reproducible on 2.2 anymore.
Magento 2.2 bugs come first, everyone else using 2.1.x has to either wait. or upgrade to 2.2 (at their own risk) or mitigate the issues themselves (again, at their own risk)

It might sound harsh, but that just seems to be the current workflow in regard to processing bug reports.

[magento-engcom-team]

Hi @nadeefit6. Thank you for working on this issue.
In order to make sure that issue has enough information and ready for development, please read and check the following instruction: :point_down:

• [ ] 1. Verify that issue has all the required information. (Preconditions, Steps to reproduce, Expected result, Actual result).
  Details

  If the issue has a valid description, the label Issue: Format is valid will be added to the issue automatically. Please, edit issue description if needed, until label Issue: Format is valid appears.

• [ ] 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue. If the report is valid, add Issue: Clear Description label to the issue by yourself.

• [ ] 3. Add Component: XXXXX label(s) to the ticket, indicating the components it may be related to.

• [ ] 4. Verify that the issue is reproducible on 2.3-develop branch

  Details

  - Add the comment @magento-engcom-team give me 2.3-develop instance to deploy test instance on Magento infrastructure.
  - If the issue is reproducible on 2.3-develop branch, please, add the label Reproduced on 2.3.x.
  - If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and _stop verification process here_!
  

• [ ] 5. Verify that the issue is reproducible on 2.2-develop branch.

  Details

  - Add the comment @magento-engcom-team give me 2.2-develop instance to deploy test instance on Magento infrastructure.
  - If the issue is reproducible on 2.2-develop branch, please add the label Reproduced on 2.2.x

• _Next steps are available in case you are a member of Community Maintainers._

• [ ] 6. Add label Issue: Confirmed once verification is complete.

• [ ] 7. Make sure that automatic system confirms that report has been added to the backlog.

[nadeefit6]

The issue could be reproduced in 2.2.7

[m2-assistant[bot]]

Hi @engcom-backlog-nazar. Thank you for working on this issue.
In order to make sure that issue has enough information and ready for development, please read and check the following instruction: :point_down:

• [ ] 1. Verify that issue has all the required information. (Preconditions, Steps to reproduce, Expected result, Actual result).
  Details

  If the issue has a valid description, the label Issue: Format is valid will be added to the issue automatically. Please, edit issue description if needed, until label Issue: Format is valid appears.

• [ ] 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue. If the report is valid, add Issue: Clear Description label to the issue by yourself.

• [ ] 3. Add Component: XXXXX label(s) to the ticket, indicating the components it may be related to.

• [ ] 4. Verify that the issue is reproducible on 2.3-develop branch

  Details

  - Add the comment @magento-engcom-team give me 2.3-develop instance to deploy test instance on Magento infrastructure.
  - If the issue is reproducible on 2.3-develop branch, please, add the label Reproduced on 2.3.x.
  - If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and _stop verification process here_!
  

• [ ] 5. Verify that the issue is reproducible on 2.2-develop branch.

  Details

  - Add the comment @magento-engcom-team give me 2.2-develop instance to deploy test instance on Magento infrastructure.
  - If the issue is reproducible on 2.2-develop branch, please add the label Reproduced on 2.2.x

• [ ] 6. Add label Issue: Confirmed once verification is complete.

• [ ] 7. Make sure that automatic system confirms that report has been added to the backlog.

[ghost]

Hi @orlangur this actualy duplicate to this -> https://github.com/magento/magento2/issues/22257 wich have more information isn't it ?

[orlangur]

@engcom-backlog-nazar yep, seems so, thanks. Closing as per @kandy resolution.