When in backend I can't see all custom attributes. Same occurs in frontend.
I selected EAV_ATTRIBUTE table and can see 179 product attributes (type = 4).
But backend Product > Attributes shows only 119.
Anyone know what could be happening?
Magento Version: 1.7.0.2
IN the admin grid for attributes, the attribute collection is retrieved like this:
$collection = Mage::getResourceModel('catalog/product_attribute_collection')
->addVisibleFilter();
So not all the attributes that exist are listed in there. Only the ones marked as is_visible in the catalog_eav_attribute table.
Try this select and see what you get.
SELECT
*
FROM
eav_attribute e
LEFT JOIN `catalog_eav_attribute` ce
ON e.attribute_id = ce.attribute_id
WHERE
e.entity_type_id = 4 AND
ce.is_visible = 1
This should get you the attributes that are listed in the admin grid.
Perhaps the database has inconsistent data due to use of direct SQL insert statements or such. Its logical that only the consistent data would show up.
I've seen some import scripts which could lead to such inconsistencies floating around on the 'net.
Maybe you got bitten by one?
Related
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 created csv file and import that using System -> Import/Export -> Dataflow-Profile
I found that in Catalog -> Manage Categories in Category Products, product is displaying
but in Manage Products product is not displaying.
and in database catalog_product_flat_1 table has not entry for that product and in other tables there is entry for that product
I have Re-index data and cleared cache but no solution..
Please help some one..
Checking the data in catalog_product_entity_int should display if there is any missing record.
The Manage Products Grid Collection query has the following inner joins:
INNER JOIN `catalog_product_entity_int` AS `at_status` ON (`at_status`.`entity_id` = `e`.`entity_id`) AND (`at_status`.`attribute_id` = '96') AND (`at_status`.`store_id` = 0)
INNER JOIN `catalog_product_entity_int` AS `at_visibility` ON (`at_visibility`.`entity_id` = `e`.`entity_id`) AND (`at_visibility`.`attribute_id` = '102') AND (`at_visibility`.`store_id` = 0)
In your case it seems that there is no record for product status in catalog_product_entity_int causing the product not to be displayed in the grid, but to be displayed in Category Products (where product's status is not checked).
The source of the problem is related to the value 1 in status column (csv file used for import). DataFlow relies on text values for the attribute (Enabled/Disabled).
It happened to me because of a special character in the product name. In my case the word "Crème" was creating all the trouble.
Check you have the field "status" in you CSV file is set to Enable or Disable.
It happened to me after I forgot to save my CSV file with all values enclosed in " ". The dataflow profiles import returned an error. And even after I tried to feed the correct CSV later, all products have disappeared from product grid (but remained in Catalogs related product list)
The way I solved it - was to create a temporary product and fill as many fields as possible. Perform an dataflow profile export selecting "Export: All Fields"
When I got my new CSV file, I compared fields of my new product with the ones of the hidden ones. The field "status" simply had no value. And it must be either Enabled or Disabled
I'm trying to add some custom options to already existing products in Magento. Seems to work fine, I added the needed rows in the following tables:
catalog_product_option
catalog_product_option_title
catalog_product_option_type_value
catalog_product_option_type_price
catalog_product_option_type_title
I also updated has_options and required_options for the right product, in the following tables:
catalog_product_entity
catalog_product_flat_1
catalog_product_flat_2
catalog_product_flat_3
When I open the product, the options doesn't show, actually, it shows less. The button to order it disappears. When I open the edit page, it does show the options. After saving, it appears on the front-end too.
What am I missing?
Update:
After manually going through literally every query that was executed after a save action, I discovered what I was missing. When a product has options, it has to display them in a different template (or whatever it's called in Magento). To do this, you'll have to change the value for the attribute options_container.
So, there's a really easy fix for that. Just look up the attribute_id in the table eav_attribute. Then just run the following query for each product:
UPDATE `catalog_product_entity_varchar` SET `value` = 'container1' WHERE `attribute_id` = 836 AND `entity_id` = $productId;
That'll do the trick! :)
After manually going through literally every query that was executed after a save action, I discovered what I was missing. When a product has options, it has to display them in a different template (or whatever it's called in Magento). To do this, you'll have to change the value for the attribute options_container.
So, there's a really easy fix for that. Just look up the attribute_id in the table eav_attribute. Then just run the following query for each product:
UPDATE `catalog_product_entity_varchar` SET `value` = 'container1' WHERE `attribute_id` = 836 AND `entity_id` = $productId;
That'll do the trick! :)
You really shouldn't be accessing the database directly for any reason. This undermines the power and resourcefulness of using an EAV system.
Extend Mage.php if outside of magento (disregard if not)
Make a collection of whatever entities you want to manipulate
Use said collection to write/read data
Save yourself headaches down the road!
we have a magento store with various categories one inside another (subcategory). Our problem is that when we enter in the admin to manage categories in the category tree on the left, some of our categories that has subcategories looks correctly with the plus (+) icon on the left but when we try to expand the category magento doesn't display any item.
The ajax call point to this url:
index.php/admin/catalog_category/categoriesJson/key/09b218741dce69171825fdbf4954855d/?isAjax=true
and it returns an empty array without throwing any error. Frontend displays all the categories correctly.
Magento version 1.4.2.1
Any idea ?
you want to go into table catalog_category_entity
run the following SQL query:
UPDATE catalog_category_entity SET children_count =
(SELECT COUNT(*) FROM
(SELECT * FROM catalog_category_entity) AS table2
WHERE path LIKE
CONCAT(catalog_category_entity.path,"/%"));
After reading Joseph answer i've tried to search for errors in catalog_category_entity and founded that all the categories in my tree has level 1 or 2 except for the categories that doesn't appear that have level 7. The strange things is that level 7 is the correct level for those category anyway i think that the problem is that Magento found a category with level 2 and it direct children has lavel 7 and it doesn't recognize those category as children for the father category.
I've changed level of the children to 2 and everything seems to work.
Why all the category in my tree has level 1 ? i don't know ...
Did you create the categories programmatically (as opposed to using the admin interface)? As is often the case in Magento, when some value is missing or incorrect in the database, entries may not show up at all. If this is the case, please take a look at a "good" category record in the database and make sure that the missing categories follow the correct conventions.
Hope that helps!
Thanks,
Joe
In my case I imported all of the categories and assigned 'level' as its position in the tree. Maybe that isn't what it's for, because setting all the categories to a level of 2 worked beautifully and kept my tree intact.
Code I used to put all levels to 2 after setting it incorrectly:
foreach ($categories as $category) {
$category = $category->load($category->getId());
$level = $category->getLevel();
if($level > 2) {
$category->setLevel(2);
$category->save();
}
}
For the mentioned cases, this query could have helped:
select c.entity_id cid, p.entity_id pid
from
catalog_category_entity c
inner join catalog_category_entity p on c.parent_id = p.entity_id
where c.level != p.level+1
It didn't help me with my categories, though.
We have a website with 2 store views: FR and EN. For some products after import catalog_product_flat for EN store view is not refreshed. In EAV tables everything is fine. Data re-index should truncate this flat table and fill it with updated data. Somehow it doesn't work for some items.
Did anyone of you had a similar problem? I'd appreciate for any clues or advices on this topic.
EDIT
I have made further checks and I was wrong about EAV tables. It turns out that catalog_product_entity_varchar is consistent with catalog_product_flat. So flat table has the same data as EAV table but in the Admin Panel values are wrong. For EN store view they are the same as default values, only for some products (magic? ;)). On my local PC I didn't encounter such issue. This is only on our production environment. As far as I know we do not use any DB replication (which could be the issue here).
EAV database model is used by Magento for easy upgrade and development as this model gives more flexibility to play with data and attributes.
When flat catalog is enabled in Magento then all the above product attributes (id, name, price) are kept in one table named like catalog_product_flat. Then Magento fetches product data from the flat table rather than joining all the other smaller tables.
There are two types of Flat Catalog:
1) Flat Catalog Product
2) Flat Catalog Category
Flat Categories are recommended for any Magento installation for improved performance.
Flat Products is designed and recommended for catalogs that have over 1000 SKU’s.
Enable Flat Catalog Category:
Go to Admin Panel->System->Cache Management->Rebuild Flat Catalog Category
Go to Admin Panel->System->Configuration->Catalog->Frontend->Use Flat Catalog Category = Yes
Enable Flat Catalog Product:
Go to Admin Panel->System->Cache Management->Rebuild Flat Catalog Product
Go to Admin Panel->System->Configuration->Catalog->Frontend->Use Flat Catalog Product = Yes
Remember that, initially the selection list of
Admin Panel->System->Configuration->Catalog->Frontend->Use Flat Catalog Product
OR,
Admin Panel->System->Configuration->Catalog->Frontend->Use Flat Catalog Product
is non-editable. You have to rebuild Flat Catalog from Cache Management. Only then the selection list becomes editable.
Make sure that while importing of the Catalog Products, the required attributes of the products are provided with correct values in the import file. If this is not done properly, then Data re-index may not function correctly.
Also before re-indexing, it is always advisable & wise to clear the cache from the "Cache Management" & from the "cache" folder of your Magento installation directory.
Hope it helps.
I was wrong about what's wrong. And everything is OK with database. The problem was an order of attributes that are retrieved from DB.
In Mage_Eav_Model_Entity_Abstract we can find:
$selects = array();
foreach ($this->getAttributesByTable() as $table=>$attributes) {
$selects[] = $this->_getLoadAttributesSelect($object, $table);
}
if (!empty($selects)) {
$values = $this->_getReadAdapter()->fetchAll(implode(' UNION ', $selects));
foreach ($values as $valueRow) {
$this->_setAttribteValue($object, $valueRow);
}
}
Line implode(' UNION ', $selects) concatenates all select statements. But there is no ORDER BY, so data can be retrieved in random order. As a matter of fact, for some of the products it is like this. That select takes values of attributes for store view 0 (always) and selected store view (current one).
Array $values contains of arrays with attributes properties. Order does matter here, because if attribute (for example 'name') for store view e.g. 1 will be proceed before one for store view 0, then it will be overwritten.
Solution is to add ORDER BY clause to the $selects or sort $values array.