Meta Keywords
Meta Title
Meta Description
URL Key
Price
Cost
Display Product Options In
New Theme
Tax Class
Short Description
Description
A check of the database shows that the product attributes has been duplicated in the database with the store_id of Store 2.
It would appear that the "Use Default Value" field is being selectively ignored on a product save.
Possibly related, and slightly different. It is not possible to use "Use Default Value" for Price when the pricing scope is set to "Website"
Regardless of whether there is a value in the database for price for any particular store, the "Use Default Value" checkbox is ALWAYS unticked.
If there is no value in the database for price for any particular store, "Use default value" should be ticked. i.e even though pricing scope is set to "Website" it should still be possible to use the default price within a website.
Same issue here. Just noticed that our Japanese Yen Store has now 170 Yen showing up instead of the currency rate (Default price is 170 Euro).
This was already working before update to 2.1.7.
@gwharton answer seems that this was intended.
Pretty crucial point for us. We are glad no one ordered anything there yet.
This is still present in 2.1.8. even though the release notes say they fixed the url_key attribute.
@gwharton, thank you for your report.
We were not able to reproduce this issue by following the steps you provided.
Please provide more details in steps to reproduce, or try to reproduce this issue on a clean installation.
- Ubuntu 16.04.3 LTS - With all latest updates
- Brand new deployment from zip 2.1.9
- Install using British Pound, GMT (Europe/London), English (UK) Language
- login to admin panel
- Stores -> All Stores -> Create Website -> test, testwebsite, 0 -> Save Website
- Stores -> All Stores -> Create Store -> test, test, Default Category -> Save Store
- Stores -> All Stores -> Create Store View -> test, test, test, Enables, 0 -> Save Store View
- Products -> Catalog -> Add Product ->
- Product Name -> test
- Price -> 1.00
- Quantity -> 1
- Category -> Default Category
- Product in Websites -> Main Website + Test
- Save (and Continue Edit)
- Change Store View -> Default Store View
- Verify that all product options show "Use Default Value" as checked
- Save (and Continue Edit)
- Verify that all product options show "Use Default Value" as checked
- In this case,
- "URL Key" has "Use default value" unchecked
- "Special Price From" has "Use default value" unchecked
- "Special Price To" has "Use default value" unchecked
- Save (and Continue Edit)
- Check catalog_product_entity tables, the above attributes have been added to database with store_id non zero
- Change Store View -> Test
- In this case,
- "Enable Product" has "Use default value" unchecked
- "Product Name" has "Use default value" unchecked
- "Tax Class" has "Use default value" unchecked
- "Visibility" has "Use default value" unchecked
- "URL Key" has "Use default value" unchecked
- "META Title" has "Use default value" unchecked
- "META Keywords" has "Use default value" unchecked
- "META Description" has "Use default value" unchecked
- "Display Product Options In" has "Use default value" unchecked
- Save (and Continue Edit)
- Check catalog_product_entity tables, the above attributes have been added to database with store_id non zero
It's not always consistent as to which attributes have the "Use default value" unchecked.
I can provide dev access to the test store i deployed if that will help.
Cheers
@gwharton, thank you for your clarifying.
We were not able to reproduce this issue on the 2.1-develop branch.
OK, well I don't know where to go from here. Would it help to take a look at my test store?
I've been able to reproduce it without an problems straight away on three different clean test deployments of Magento 2.1 (two of 2.1.8 and one of 2.1.9) and one production deployment of Magento 2.1.8.
I can reproduce it using both Microsoft Edge and Mozilla Firefox.
I have decided to drop the multi store setup of my store and will go forward with a single store as that does not have any issues. Therefore, this issue is no longer a priority to me......but I guess it will be for others.
We see this issue also on both the test and production system but our setup is complicated by a plugin which updates product information so it is not a clean test case (even though I think it is unrelated). Thanks @gwharton for following it up.
Here's a short video if it helps.
@gwharton thank you for update. we will try one more time
hi there!
we've got a similar issue in 2.1.8 and 2.1.9
when DUPLICATING A PRODUCT (in "All store views") and trying to set "Use default value" on "URL key" of the "default store view" (in the "Search Engine Optimization" section) after hitting "save" the Use-default-value's checkbox of the Url_Key gets deselected and the related Url_key field gets blank.
we've experienced it since upgrading to 2.1.8 and further upgrading to 2.1.9 doesn't solve the issue.
cheers,
romeo
Found no solution so far - the bug is still valid in our shop.
The same problem is when we uncheck a website to take out the product there, and recheck it.
It will ask for "use Default VALUES" and copy them.
But I will not be able to set the checkmark then to "use default values" - instead it has the price copied from the default.
But I am sure it is already fixed in 2.3.0.
Sorry for the sarcasm. Take it as motivation for a better backport philosopy.
This is behavior I am still experiencing on 2.1.9, in a clean install:
Expected Result:
catalog_product_entity_varchar
will exhibit a single record for the URL key attribute for this product, one with store_id 0 and value "attr-value-test". On the product edit page for this product with the specific store scope selected, "attr-value-test" will show in the greyed-out field and "Use Default Value" will be checked.
Actual Result:
catalog_product_entity_varchar
exhibits two records for the URL key attribute for this product, one with store_id 0 and value "attr-value-test" and the other with a specific store_id and a NULL value. On the product edit page for this product with the specific store scope selected, the URL key field is blank and not greyed out, and "Use Default Value" is not checked.
This seems to be the same basic issue originally reported here, but please indicate if a new issue needs to be opened, because this is a pretty concrete reproducible bug.
Same issue as @CNanninga after 2.1.2 > 2.1.9 update.
Same issue on 2.2.0!
I see it also in various other fields (ie. Category Image)
For the record, Enterprise support acknowledged this issue and sent a patch: MDVA-6475.
So is this fix going to be folded into the core?
You may find this useful:
https://github.com/magento/magento2/issues/12159#issuecomment-343528601
I worked on same issue for Category
@georgios-2317 I'm sure thats present in the product code base too, but this problem seems subtly different. See the below debug session where I just repeatedly save the same product over and over again, dumping the database at each save. On each save, more attributes are being added to the entity tables for store id=1 even though I'm not actually changing anything on the admin pages.
MariaDB [dev_magento]> select * from catalog_product_entity_datetime where store_id = 1;
Empty set (0.00 sec)
MariaDB [dev_magento]> select * from catalog_product_entity_int where store_id = 1;
Empty set (0.00 sec)
MariaDB [dev_magento]> select * from catalog_product_entity_decimal where store_id = 1;
Empty set (0.00 sec)
MariaDB [dev_magento]> select * from catalog_product_entity_text where store_id = 1;
Empty set (0.00 sec)
MariaDB [dev_magento]> select * from catalog_product_entity_varchar where store_id = 1;
Empty set (0.00 sec)
**** - Catalog->Product->ID=8
**** - Ensure scope to "All Store Views", ID = 0;
MariaDB [dev_magento]> select * from catalog_product_entity_datetime where store_id = 1;
Empty set (0.00 sec)
MariaDB [dev_magento]> select * from catalog_product_entity_int where store_id = 1;
Empty set (0.00 sec)
MariaDB [dev_magento]> select * from catalog_product_entity_decimal where store_id = 1;
Empty set (0.00 sec)
MariaDB [dev_magento]> select * from catalog_product_entity_text where store_id = 1;
Empty set (0.00 sec)
MariaDB [dev_magento]> select * from catalog_product_entity_varchar where store_id = 1;
Empty set (0.00 sec)
**** - SAVE
MariaDB [dev_magento]> select * from catalog_product_entity_datetime where store_id = 1;
Empty set (0.00 sec)
MariaDB [dev_magento]> select * from catalog_product_entity_int where store_id = 1;
Empty set (0.00 sec)
MariaDB [dev_magento]> select * from catalog_product_entity_decimal where store_id = 1;
Empty set (0.00 sec)
MariaDB [dev_magento]> select * from catalog_product_entity_text where store_id = 1;
Empty set (0.00 sec)
MariaDB [dev_magento]> select * from catalog_product_entity_varchar where store_id = 1;
Empty set (0.00 sec)
**** - Change scope to "Default Store View", ID = 1;
**** - Admin page for product shows all "Use Default Value" as checked
MariaDB [dev_magento]> select * from catalog_product_entity_datetime where store_id = 1;
Empty set (0.00 sec)
MariaDB [dev_magento]> select * from catalog_product_entity_int where store_id = 1;
Empty set (0.00 sec)
MariaDB [dev_magento]> select * from catalog_product_entity_decimal where store_id = 1;
Empty set (0.00 sec)
MariaDB [dev_magento]> select * from catalog_product_entity_text where store_id = 1;
Empty set (0.00 sec)
MariaDB [dev_magento]> select * from catalog_product_entity_varchar where store_id = 1;
Empty set (0.00 sec)
**** - Dont modify any fields
**** - SAVE
MariaDB [dev_magento]> select * from catalog_product_entity_datetime where store_id = 1;
Empty set (0.00 sec)
MariaDB [dev_magento]> select * from catalog_product_entity_int where store_id = 1;
+----------+--------------+----------+-----------+-------+
| value_id | attribute_id | store_id | entity_id | value |
+----------+--------------+----------+-----------+-------+
| 232 | 148 | 1 | 8 | 0 |
| 234 | 164 | 1 | 8 | 1 |
+----------+--------------+----------+-----------+-------+
2 rows in set (0.01 sec)
MariaDB [dev_magento]> select * from catalog_product_entity_decimal where store_id = 1;
Empty set (0.00 sec)
MariaDB [dev_magento]> select * from catalog_product_entity_text where store_id = 1;
Empty set (0.00 sec)
MariaDB [dev_magento]> select * from catalog_product_entity_varchar where store_id = 1;
+----------+--------------+----------+-----------+-------+
| value_id | attribute_id | store_id | entity_id | value |
+----------+--------------+----------+-----------+-------+
| 888 | 119 | 1 | 8 | NULL |
| 889 | 122 | 1 | 8 | 0 |
+----------+--------------+----------+-----------+-------+
2 rows in set (0.00 sec)
**** - Dont modify any fields
**** - SAVE
MariaDB [dev_magento]> select * from catalog_product_entity_datetime where store_id = 1;
Empty set (0.00 sec)
MariaDB [dev_magento]> select * from catalog_product_entity_int where store_id = 1;
+----------+--------------+----------+-----------+-------+
| value_id | attribute_id | store_id | entity_id | value |
+----------+--------------+----------+-----------+-------+
| 247 | 164 | 1 | 8 | 1 |
+----------+--------------+----------+-----------+-------+
MariaDB [dev_magento]> select * from catalog_product_entity_decimal where store_id = 1;
Empty set (0.00 sec)
MariaDB [dev_magento]> select * from catalog_product_entity_text where store_id = 1;
+----------+--------------+----------+-----------+-------+
| value_id | attribute_id | store_id | entity_id | value |
+----------+--------------+----------+-----------+-------+
| 106 | 75 | 1 | 8 | desciption |
| 107 | 76 | 1 | 8 | short desciption |
+----------+--------------+----------+-----------+-------+
MariaDB [dev_magento]> select * from catalog_product_entity_varchar where store_id = 1;
+----------+--------------+----------+-----------+-------+
| value_id | attribute_id | store_id | entity_id | value |
+----------+--------------+----------+-----------+-------+
| 888 | 119 | 1 | 8 | NULL |
| 889 | 122 | 1 | 8 | 0 |
+----------+--------------+----------+-----------+-------+
2 rows in set (0.00 sec)
**** - Dont modify any fields
**** - SAVE
MariaDB [dev_magento]> select * from catalog_product_entity_datetime where store_id = 1;
Empty set (0.00 sec)
MariaDB [dev_magento]> select * from catalog_product_entity_int where store_id = 1;
+----------+--------------+----------+-----------+-------+
| value_id | attribute_id | store_id | entity_id | value |
+----------+--------------+----------+-----------+-------+
| 247 | 164 | 1 | 8 | 1 |
| 250 | 133 | 1 | 8 | 0 |
| 252 | 148 | 1 | 8 | 0 |
+----------+--------------+----------+-----------+-------+
MariaDB [dev_magento]> select * from catalog_product_entity_decimal where store_id = 1;
Empty set (0.00 sec)
MariaDB [dev_magento]> select * from catalog_product_entity_text where store_id = 1;
+----------+--------------+----------+-----------+-------+
| value_id | attribute_id | store_id | entity_id | value |
+----------+--------------+----------+-----------+-------+
| 106 | 75 | 1 | 8 | desciption |
| 107 | 76 | 1 | 8 | short desciption |
+----------+--------------+----------+-----------+-------+
MariaDB [dev_magento]> select * from catalog_product_entity_varchar where store_id = 1;
+----------+--------------+----------+-----------+-------+
| value_id | attribute_id | store_id | entity_id | value |
+----------+--------------+----------+-----------+-------+
| 888 | 119 | 1 | 8 | NULL |
| 889 | 122 | 1 | 8 | 0 |
| 889 | 100 | 1 | 8 | 0 |
+----------+--------------+----------+-----------+-------+
2 rows in set (0.00 sec)
@gwharton I think your case of increasing attribute saves may be due to Admin page receiving mixed results when loading the data from db. I too had it for some attributes it couldnt detect status due to the mess and then the client (js) was sending them as changed each time. You dont need to change something on the client for a change to be caused on the back-end. Though I could be talking total bull*t.
Sounds completely plausible. I never rule anything out with Magento! 馃憤
@johnny-longneck For your info this bug is 100% reproducable within 1 minute of a fresh install of 2.3-develop. :)
@gwharton, thank you for your report.
We've created internal ticket(s) MAGETWO-83988 to track progress on the issue.
We're having a slightly different problem.
On a storeview, even when the value is filled in for a certain attribute, it still uses the default value BUT the checkbox to use default value is not checked. If I remove the default value, the value of the specific storeview is shown.
see more information #12982
There seems to be a difference in behavior when you leave the section "Search Engine Optimization" closed or when you have opened it.
For instance, url key:
I have the same problem on 2.2.2. If I save a product in any storeview, it applys default values to the store view which is very critical since I can not maintain any attributes on All Store Views anymore. For more than 50 store views this means a lot of work.
My workaround is to delete the entrys from the DB every time I save a product.
See here for a patch: https://www.cadence-labs.com/2018/03/magento-2-use-default-value-store-view-scope-fix/
The associated module should fix the issue which comes from the url_key autogenerator (for url_key attribute) and then the general issue of attributes in non-opened tabs not having their "use_default_value" flag sent to the server
Thanks @cadencelabs-master, but I think this isn't the most "correct" fix.
Since the same bug can be triggered by sending data using the REST api to a certain storeview for a product or category or something else EAV based. When updating a single attribute using the API, Magento copies data from the default values to the store view values for all the other attributes of that particular entity.
So it's the same problem as mentioned above when saving a product in the backend of Magento for a specific storeviw, but triggered in a different way and most likely not fixed by your workaround. I feel like the problem is deeper and more close to the database level, probably somewhere in the EAV model I'm guessing.
@magento-engcom-team: I really hope you guys realize what a serious bug this is and I would hope you can communicate this to the core devs so they take this a bit more serious, thanks! :)
It may be a similar issue @hostep , however this issue is definitely related to the knockout implementation in admin - I have a feeling rest is different, you can see in my article that it's related to the use_defautl_value[] array not including attributes from tabs that aren't opened.
Well, if you don't send values for fields you don't want to touch, why is Magento copying the default values over to the storeview for those fields? Magento should just only process what is getting send to it, not what is not getting send to it...
(sorry if my comment makes no sense, this is all in theory, I haven't debugged this myself or looked deeply at the code, only heard it from colleagues complaining about this)
It sends values for all the fields, even the ones you haven't touched (in unopened tabs). However it does not send the extra flag for "use default value" if the tab was closed - you can see the details in my article.
@cadencelabs-master I love you.
As already said it does not work for REST API, but saving a product in the backend is a very big problem too and this is fixed.
Is it intention that attributes image
, small_image
, thumbnail
and swatch_image
are saved to store view scope anyways even without changing them? I tested the fix deleting all store view values from catalog_product_entity_varchar, then saving an unmodified product on store view scope. Before the fix I had 10000 values saved to the store view, now it's only the following:
value_id;attribute_id;store_id;entity_id;value
73872;87;3;3;/1/0/10.jpg
73873;88;3;3;/1/0/10.jpg
73874;89;3;3;/1/0/10.jpg
73875;132;3;3;/1/0/10.jpg
with eav attributes:
value_id;attribute_id;store_id;entity_id;value
73872;87;3;3;/1/0/10.jpg
73873;88;3;3;/1/0/10.jpg
73874;89;3;3;/1/0/10.jpg
73875;132;3;3;/1/0/10.jpg
If its any help I ran into this same problem when importing products into magento 2.2.3 via magenti API.
I set all my values on the "default store view" but then the Catalog Image was not saving my "use default value" when saving my individual store views. To fix this I ran the following on the database to clear out the data stored on each store view and force magento to use the "Default Store View" options and it worked perfectly.
DELETE FROM `catalog_category_entity_text` where store_id = 1;
DELETE FROM `catalog_category_entity_datetime` where store_id = 1;
DELETE FROM `catalog_category_entity_decimal` where store_id = 1;
DELETE FROM `catalog_category_entity_int` where store_id = 1;
DELETE FROM `catalog_category_entity_varchar` where store_id = 1;
Note: my store was ID 1 - youll need to replace this with each store view that you have.
Now all my store views are picking up the default store view options for all catalog options. I believe this is caused due to the API process of import and or the fact that I have a single store with multiple store views setup.
looks like this issue duplicates #9486
And also https://github.com/magento/magento2/issues/13665
But I've seen fixes landing in the 2.2-develop
branch which should fix this problem:
No idea when these will be released in an official version though.
In contrast to what the description in the first bullet point says, this bug has still not been fixed for when sending in data through the REST API, and these issues track that particular bug:
Best,
For the record only we are Running magento 2.2.5 with the same issue(s).
Best regards
Yes - these issues are not fixed in 2.2.x - I updated my original fix / article with support for 2.2. The bug fixes mentioned above don't appear to directly address this specific issue (they address other bugs)
https://www.cadence-labs.com/2018/03/magento-2-use-default-value-store-view-scope-fix/
@cadencelabs-master This issue only addresses products. Does someone know a fix for categories? Same issue when changing store view specific values on categories.
This is exactly what we are experiencing:
@romeof1980
hi there!
we've got a similar issue in 2.1.8 and 2.1.9
when DUPLICATING A PRODUCT (in "All store views") and trying to set "Use default value" on "URL key" of the "default store view" (in the "Search Engine Optimization" section) after hitting "save" the Use-default-value's checkbox of the Url_Key gets deselected and the related Url_key field gets blank.
we've experienced it since upgrading to 2.1.8 and further upgrading to 2.1.9 doesn't solve the issue.
cheers,
romeo
We are on 2.2.5, and we are seeing this on Configurable Products only (the parent product).
Did you find a workaraound Romeo? We thought about exporting default store values, then importing them again but specifying the store view....but it's a lot of work because some of our URLs are different so we would have to go through by hand.
My thread was closed and I was told it was a duplicate of this thread, but this thread seems to be discussing issues in multiple-store view environments. I only have one on my 2.2.6 installation, the default values are NOT getting unchecked they are just not working on the front-end. I read the symptoms and fix discussed on cadence-labs, but it does not seem to apply to me. None of the store id's are null or > 0.
My issues are specifically:
Another conversion killer! In one of our shops a bunch of prices where displayed wrong which significantly did drop sales volume for 2 related store views. Congratulations! We have to analyze it in detail, but 2.2.6 seems to make related issues worser than before
Yes - these issues are not fixed in 2.2.x - I updated my original fix / article with support for 2.2. The bug fixes mentioned above don't appear to directly address this specific issue (they address other bugs)
https://www.cadence-labs.com/2018/03/magento-2-use-default-value-store-view-scope-fix/
This fixed the issue with the url key, but (sometimes) the other global attributes like price, weight are cleared for all storeviews. So we cannot use this fix. Hope this issue will be fixed soon by Magento.
Yes - these issues are not fixed in 2.2.x - I updated my original fix / article with support for 2.2. The bug fixes mentioned above don't appear to directly address this specific issue (they address other bugs)
https://www.cadence-labs.com/2018/03/magento-2-use-default-value-store-view-scope-fix/This fixed the issue with the url key, but (sometimes) the other global attributes like price, weight are cleared for all storeviews. So we cannot use this fix. Hope this issue will be fixed soon by Magento.
yes you are right
Yes - these issues are not fixed in 2.2.x - I updated my original fix / article with support for 2.2. The bug fixes mentioned above don't appear to directly address this specific issue (they address other bugs)
https://www.cadence-labs.com/2018/03/magento-2-use-default-value-store-view-scope-fix/This fixed the issue with the url key, but (sometimes) the other global attributes like price, weight are cleared for all storeviews. So we cannot use this fix. Hope this issue will be fixed soon by Magento.
yes you are right
We've applied a quick fix for this issue in _app/code/Cadence/ScopeFix/Controller/Catalog/Adminhtml/Product/Initialization/Helper.php_ on rule 193.
Old code:
_if ($attribute->getBackendType() != 'static' && $rootProduct->getData($productKey) == $productValue) {_
New code:
_if ($attribute->getBackendType() != 'static' && $attribute->getScope() != \Magento\Catalog\Api\Data\EavAttributeInterface::SCOPE_GLOBAL_TEXT && $rootProduct->getData($productKey) == $productValue) {_
We've added a check to check if the attribute scope is not global.
Yes - these issues are not fixed in 2.2.x - I updated my original fix / article with support for 2.2. The bug fixes mentioned above don't appear to directly address this specific issue (they address other bugs)
https://www.cadence-labs.com/2018/03/magento-2-use-default-value-store-view-scope-fix/This fixed the issue with the url key, but (sometimes) the other global attributes like price, weight are cleared for all storeviews. So we cannot use this fix. Hope this issue will be fixed soon by Magento.
yes you are right
We've applied a quick fix for this issue in _app/code/Cadence/ScopeFix/Controller/Catalog/Adminhtml/Product/Initialization/Helper.php_ on rule 193.
Old code:
_if ($attribute->getBackendType() != 'static' && $rootProduct->getData($productKey) == $productValue) {_New code:
_if ($attribute->getBackendType() != 'static' && $attribute->getScope() != \Magento\Catalog\Api\Data\EavAttributeInterface::SCOPE_GLOBAL_TEXT && $rootProduct->getData($productKey) == $productValue) {_We've added a check to check if the attribute scope is not global.
I can't find this code in the core magento module-catalog, what versrion of magento are you building on?
Also it looks like you're fixing changes you've already made in an overridden file, if that's the case can you provide more context on what you were originally fixing and what this new code change means for a default installation?
Sorry I didn't read the whole comment chain, I now realize this is a fix to the Cadence module mentioned in the link earlier.
before saving the product or any attributes of the product setCurrentStore to '0' (zero) you can do this by following these steps
use Magento\Store\Model\StoreManagerInterface;
class YourClassName
{
/**
* @var StoreManagerInterface
*/
protected $_storeManager;
public function __construct(
StoreManagerInterface $storeManager
)
{
$this->_storeManager = $storeManager;
}
public function yourFunctionName()
{
$this->_storeManager->setCurrentStore('0');
//do your work and save
}
It work for me let me know if any issues
So this issue seems to be caused when saving the product programmatically and the store view is not set explicitly.
I fixed this by doing the following when loading the product:
When using ProductRepository
$product = $productRepository->get($sku, false, 0, false);
When using Collection
$productCollection = $productCollectionFactory
->create()
->setStoreId(0)
->addFieldToFilter('some_field', $someValue);
This original bug was raised against the "Use default value" checkbox not functioning correctly on the backend gui. I have just re-run tests on 2.3-develop and I am happy this is no longer an issue with the backend gui, therefore closing issue.
Indeed, the original reported bug was fixed around Magento 2.2.6 (from memory).
We are using latest magento version (2.3.3) but the problem persist and a few products still have the same issue. Despite ticking all boxes, Magento does not save it and boxes remain unticked. Is there anyone has resolved the issue?
@tushhan: can you open a new issue with exact steps to reproduce, that would be very much appreciated, thanks!
I have the same issue with 2.3.3.
It seems to be a javascript issue regarding the toggle event ticking the checkbox.
Tracked this down to file:
vendor/magento/module-catalog/Controller/Adminhtml/Product/Initialization/Helper.php:204
The POST var $useDefaults = (array)$this->request->getPost('use_default', []); is empty.
Same function edition categories on store view level works without any problems.
Hi @mwieschke: great! Can you please open a new issue for this? It's probably a new issue you are running into, commenting on an old ticket is not going to get picked up by the Magento support staff I think.
Most helpful comment
Another conversion killer! In one of our shops a bunch of prices where displayed wrong which significantly did drop sales volume for 2 related store views. Congratulations! We have to analyze it in detail, but 2.2.6 seems to make related issues worser than before