Recently, I've imported about 40.000 products through CSV to a Magento 2 staging environment (Community 2.4.1). Many of these products are configurable products (e.g. a table) with child products (red table, green table, ...) attached to it.
After the import, I noticed my price ordering and filtering is not working correctly. I figured out that column min_price and max_price of table catalog_product_index_price are '0' for all configurable products. Unlike when manually creating configurable products, Magento apparently isn't filling these columns during CSV imports. Not sure if a bug, or my mistake.
I need to fix min_price and max_price for all configurable products in order for the filters and sorting to work. I've tried updating the columns directly in catalog_product_index_price, but no result (just changes back to 0 after reindexing). I'm still digging into Magento's database structure, but can't seem to find any other place where min_price and max_price are stored though.
Am I missing something?
I finally found it.
Even though my store does not have a stock, I had to:
Set the Qty of all products to > 0.
Set all products to "is_on_stock".
Apparently there's a bug (at least, I think it's a bug) in M2 that is causing the indexer to set a Configurable Product's min_price and max_price to zero in case its Simple Products do not have a Qty or is_on_stock set.
Perhaps there's a reason behind that, but to me, it makes absolutely no sense.
Related
Magento-Data:
Magento 1.4.2 Community Edition
What's the problem?
When adding related products to single products they are not displayed completely or even not.
The problem occurs at the moment on five products, each of that products has between 15 and 36 related products.
Three of the affected products are showing 1 related product, the other 2 products show nothing.
What we've tried so far:
- We completely rebuilt all indexes (it's done every night by cron)
- Emtpying the cache
- We controlled the affected single products if they:
are in stock
have a qty >0
are assigned to a category and a website
are enabled
have a visibility of "catalog, search"
-We also checked that for every single added related product
The strange thing is, that it only occurs at a few products, all other products show their related products without problems.
I hope someone can help us with that issue and give a hint.
Best regards
tireniets
UPDATE & SOLUTION (2016-08-04):
The problem was caused by group products-all affected products are part of a group product. And that group product overwrites all assigned related products of its child products.
So it was no error or bug, it was just the default behavior of the group product. :)
UPDATE & SOLUTION (2016-08-04):
The problem was caused by group products-all affected products are part of a group product. And that group product overwrites all assigned related products of its child products.
So it was no error or bug, it was just the default behavior of the group product. :)
I am taking over a website from another developer, and have found the setup of attributes to be a bit of a mess.
Specifically, products have attributes that aren't associated with the relevant attribute sets.
If you take wine with an attribute set "Wines", one of whose attributes is "Grape Variety".
But I also have "Beers" with a completely different attribute set, but somehow one of my beers has a Grape Variety.
It's not assigned to the Beers attribute set, it doesn't show up in the back end for this product, (so I can't edit it) but if I look in the database it's there (in catalog_product_entity_* and catalog_product_index_eav), furthermore when I do an export it's there too, and if someone searches for "Merlot", they are coming up with this beer. There are hundreds of products like this.
What is the best way of removing all attributes from products that are not within their assigned attribute sets?
I could figure it out in SQL I'm sure, but that's not the best way of doing things as I'd be afraid of missing something and screwing up the products altogether.
This is what I ended up doing. A few weeks later and it doesn't seem to have caused any issues yet:
CREATE TABLE catalog_product_entity_int_old LIKE catalog_product_entity_int;
INSERT INTO catalog_product_entity_int_old SELECT * FROM catalog_product_entity_int;
DELETE FROM catalog_product_entity_int
WHERE value_id IN
(SELECT cpei.value_id
FROM catalog_product_entity_int_old cpei
WHERE cpei.attribute_id NOT IN
(SELECT eea.attribute_id
FROM eav_entity_attribute eea
JOIN catalog_product_entity cpe ON eea.attribute_set_id = cpe.attribute_set_id
WHERE cpe.entity_id = cpei.entity_id)
ORDER BY cpei.entity_id)
and
DELETE FROM catalog_product_index_eav WHERE
attribute_id NOT IN (
(SELECT eea.attribute_id
FROM eav_entity_attribute eea
JOIN catalog_product_entity cpe ON eea.attribute_set_id = cpe.attribute_set_id
WHERE cpe.entity_id = catalog_product_index_eav .entity_id)
);
Then regenerate the indices.
I would definitely use Magmi to clean this up:
First, do a product export from within Magento (System -> Import/Export -> Profiles) and choose "Export All Products." In the resulting CSV, you will have columns for each attribute and you can remove any irrelevant attribute values for each product. This will allow you to bypass the backend where attributes are set for a particular product, but not in the product's attribute set.
Take a good look at the Magmi Wiki, but a few quick tips: Magmi only imports the columns you specify, so you can safely remove most of the columns when you perform your import. For example, I always make sure to remove the image columns if I'm not importing images (or you may lose all of your images). Also, be sure to do a database backup before running your import in case something goes wrong.
I have a request to change the SKU for an existing product, so I am wondering if changing the SKU will affect the order history of this product. Since SKU is a global Identifier in Magento I am not sure what would be the effect of changing it. This is Magento 1.7 CE
Thanks
Order data is stored in the sales_flat_order_item and sales_flat_order tables. If you change the SKU of a product in your catalog, it will not affect the SKU of the product on already existing orders.
Regards,
Changing the SKU of an active product, and or the flat product's afterword will NOT retroactively update the sales order history.
100% sure on this.
Sales Order History
Referencing the old SKU to the "New" Sku will result in some broken behavior that must be accounted for, this especially is true in Configurable products.
Cheers,
-J
http://www.magentocommerce.com/wiki/2_-_magento_concepts_and_architecture/catalog_database_tables
i hope i am able to describe the problem correctly here, as it is quite complex. I guess you guys are my last chance.
We have ca. 120 config products based on 600 simple products. Some days ago, we accidently overwrote all the prices of the simple products with false prices. We did not notice as in the frontend every price is still ok, they are not indexed.
So we now have the correct prices in the frontend, but the wrong prices for the simple products in the backend.
Is there any method the get the prices from the indexed frontend and write them back in the backend?
Until i reindex all proces should be ok in the frontend.
Does anyone have any idea what i could do to get the prices right again?
If you browse the database, there should be a catalog_product_flat_1 table - this is basically your product index. You should have columns for all the product attributes (including SKU and Price) so you could export this table, then do a product export from Magento, then update all the prices/SKUs accordingly and re-import. Or duplicate the flat_1 table, then write a PHP script to loop through it, updating all the prices, then re-index your data (after checking it's worked of course!)
I'd like to set up catalog price rules discounts based on SKU.
However when I go to 'manage attributes' and try to edit SKU to 'use in Promo Rules: yes'. I get an error saying that SKU is a system reserved atrribute.
I have already changed the SKU attribute to user_defined=1 under eav_attribute table, but the message still appears.
It seems this was possible in earlier version of magento but not 1.6?
Any help is much appreciated.
I took a guess and managed to fix my own problem.
I had set SKU attribute to user_defined=1 under eav_attribute table earlier on along with every other attribute. I had assumed setting them all to '1' would make life easier in the future. However, setting SKU user_defined to 0 via phpmyadmin, actually allowed me to make the changes I wanted.