Hello! I'm currently working on setting up Magento 2 and have a few thousand potential attribute options. I've set the php settings to allow us to work with the large set of data, but I've run into an issue applying those attributes to products.
It seems Magento 2 is limiting each attribute on a product to 50 entries. I've verified this by maxing out the attributes, removing one, then replacing it with another value. This saves fine all the way up to 50, where it just stops accepting the values.
I've gone into the database and added attributes to the catalog_product_index_eav table, but even then it only displays/saves the first 50 entries. I've set the php variables to insanely high values to see if it's an input limitation, but it looks like nothing I change helps.
Any ideas?
Solved! Go to Solution.
Figured it out! I was looking in the wrong tables!
While attributes for each product are saved to catalog_product_index_eav, it seems those values don't actually matter at all when it comes to saving and loading the attributes (another magento 'quirk'!)
Attributes are actually saved in catalog_product_entity_varchar as a comma separated string, and Magento has most, if not all varchar columns set to a limit of 255 characters. Upping that value obviously leaves more room for text to be entered, thus allowing the attributes to save!
I kind of understand why you'd use catalog_product_index_eav to store the values for faster queries, but why would you then make a single string to contain all the values, and have the backend use that instead of the normal table? Seems a bit redundant to me.
Figured it out! I was looking in the wrong tables!
While attributes for each product are saved to catalog_product_index_eav, it seems those values don't actually matter at all when it comes to saving and loading the attributes (another magento 'quirk'!)
Attributes are actually saved in catalog_product_entity_varchar as a comma separated string, and Magento has most, if not all varchar columns set to a limit of 255 characters. Upping that value obviously leaves more room for text to be entered, thus allowing the attributes to save!
I kind of understand why you'd use catalog_product_index_eav to store the values for faster queries, but why would you then make a single string to contain all the values, and have the backend use that instead of the normal table? Seems a bit redundant to me.