I read this article http://inchoo.net/ecommerce/magento/how-to-add-new-custom-category-attribute-in-magento/comment-page-1/
There is part of code in the installer:
//this will set data of your custom attribute for root category
Mage::getModel('catalog/category')
->load(1)
->setImportedCatId(0)
->setInitialSetupFlag(true)
->save();
//this will set data of your custom attribute for default category
Mage::getModel('catalog/category')
->load(2)
->setImportedCatId(0)
->setInitialSetupFlag(true)
->save();
Two question here:
Function load has a parameter. It is ID. Which table should be used for?
What is for setImportedCatId here? it's setter, but I don't understad what is it for.
Magento categories still use the EAV table structure, so the table you're interested in is
catalog_category_entity
However, you won't be able to see the category names here. Most data for the category objects are persisted to
catalog_category_entity_varchar
indexed back to the catalog_category_entity table by entity_id.
I grepped around modern source trees and it appears that the data property imported_cat_id (which is what the setter could be setting), but based on patterns used elsewhere in the Magento system my guess is that some version of Magento has code in the category saving tree that looks for imported_cat_id, and if it's set the new category data will be based on the old category. In other words, it allows you to quickly copy a category and save all it's meta-data. By setting it to 0 above, the Inchoo code is telling Magento that this is a new category.
That's just a guess though, but it's not something I'd worry about.
Related
The problem I'm having is that I import products with Magmi (magento product import open source solution), but I want to change the url slug. I need to know which table in magento database contains slug so that I could maybe feed it somehow directly...
I know this question is old and answer was accepted but for users do not using Magmi is there this answer:
URL Key is stored by EAV model.
You can find value by following query:
SELECT `attribute_id` INTO #urlKeyId
FROM `eav_attribute` WHERE `entity_type_id` = 4 AND `attribute_code` LIKE 'url_key';
SELECT * FROM `catalog_product_entity_varchar` WHERE `attribute_id` = #urlKeyId;
(if you are using table prefix add it to table's names)
The most excellent Magmi will do that for you. I suggest you read every single page of the Magmi instructions slowly and carefully to comprehend the enormous capabilities of this software tool. But the one you want to concentrate on is here.
So if you use a CSV like:
"sku","url_key"
"00085722994075","my-awesome-product-you-will-fail-without-it"
Then Magmi will update all the product 'slugs' for you.
To answer your question: The core_url_rewrite is the main table but it is built from, among other things, the product attribute 'url_key' and the product attributes are in the EAV so it isn't a single table update. That is why we bow to the genius of Dweeves and his magical Magmi code.
i think better idea to load product then update product URL otherwise if you try to do in direct database table. some problems can come out like indexing , magento can stop working.
i means how you do load MAGE class then load product then do this manually
So what i'm trying to achieve is that the product with the attribute 'promotion' set to 'yes' is displayed on the frontpage of the website. This is working, but the .phtml file i'am using with this is the regular list.phtml. This is currently showing all the items I have set to promotion but I only want to show 1.
So in short: How do I edit the list.phtml to only show 1 product instead of everything?
Change how you are pulling your collection. Clone/Rename your list.phtml, for example promotion.phtml. Then change this line, from this:
$_productCollection=$this->getLoadedProductCollection();
To this:
$_productCollection = Mage::getModel('catalog/product')
->getCollection()
->addAttributeToSelect('*')
->addFieldToFilter('promotion', 1)
->addAttributeToSort('updated_at', 'DESC')
->clear()->setPageSize(1)->load();
And it should load only one item with promotion set to yes. Make sure you set the new template in either your CMS Page Content or XML, depending on which method this is added.
Explanation
Mage::getModel('catalog/product')->getCollection(): Gets the Product Collection. You can get other collections by changing the model, such as "catalog/category" and "cms/page".
->addAttributeToSelect('*'): Adds All Product Columns. This can be exchanged for things like ('name', 'url'). I'm assuming it's faster than loading all but I haven't benchmarked it. Since you're using the full template it's probably best to leave this set to all.
->addFieldToFilter('promotion', 1): Filters out products by attributes. Here we have the products filtered for all those with the 'promotion' attribute set to 1(yes/true). Products use this one, while categories use ->addAttributeToFilter() oddly enough. Definitely give Alan Storm's Collection Explanation(link below) a read through to know what all you can do with this one. You can add multiple filters to your collection, either by adding another ->addFieldToFilter(), or storing your filters in nested arrays.
->addAttributeToSort('updated_at', 'DESC'): Sorts the product collection by specific attribute and direction. Here I have the "updated_at" date set to descending order, "ASC" is ascending. You can add multiple sorting attributes, pay attention to the order you add them in, of course.
->clear()->setPageSize(1)->load(): These three are needed to make adjustments to how much the collection pulls. ->clear() must be called before it will allow changing how many products are pulled. The ->setPageSize() bit is where you specify how many products you would like to return, and ->load() of course loads the collection. Note that if you do not limit the size of the collection returned, you do not need this entire line, the products will iterate without having to call ->load().
Resources
Alan Storm said it best, give this a read and you should be a pro at manipulating collections: http://alanstorm.com/magento_collections
I was looking at the Flat Tables and saw this perculiar behaviour. For some of my attributes like 'language' there were two columns (language and language class) while for other 'age' there were no such values stored.
I could not find any settings in the attribute field which described this and it seems to follow no pattern.
Also in the place where language is stored language is int(11) and langauge_value is varchar(256) while in age it is varchar(256) but actually stores just a number.
UPDATE:
I think the question was not understood. I am seeing some attributes being shown as varchar(255) while some attributes being shown as attributes (int(11)) and attribute_value (varchar(255)
Found the answer:
For simple dropdown, the attribute_value is also added to the flat table.values being shown.
For Multiselect, the values are not added to the Flat table.
Pattern is very simple, when you create new attribute, you select whether it is used for search/layered navigation. If yes - indexer will add new column for this attribute to flat table.
Answered under the topic Can I add other attributes to magento's flat product catalog table? And don't get too slap-happy in adding attributes to your Flat Product Catalog table. It has a row limit defined by MySQL limitations.
I believe it is all about the scope of the variable and if it is available on the frontend of the website (where the flat table is used).
If you set an attribute to be displayed on the front end of the website (or I believe if its scope is set to store view, but dont quote me on that) it will be put into the flat table.
One way I generally look at it is, if when I create the attribute I need to reindex the flat product index, it is going to go in there.
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.
I am facing a problem while making product configurable i used this link http://www.magentocommerce.com/knowledge-base/entry/tutorial-creating-a-configurable-product/ but In associated tab the products doesnt show up
Thankds and regards
2 things you can check:
Are you sure that the simple products you want to associate to the configurable product actually have values for the attribute you made the configurable product configurable by? So if you made a configurable product based on 'color', do the simple products have values selected for 'color'?
When you are looking at the associated products tab, and seeing the blank grid there, have you tried resetting the filter, or selecting 'No' or 'Any' in the first column? If it is set to 'Yes', it is only looking for products that have already been associated.
How does configurables products linking works in magento ?
Getting rid of being trolled by the linking of configurables products with their simple counterparts ? Let's explain how does Magento link'em... and why it sometimes doesn't work as expected.
The first point to understand is how the data persistence is managed by the application. As expected, links are stored in database. Thought it was in catalog_product_relation ? You were wrong. It should be too simple to respect the Magento's spirit :)
catalog_product_relation vs catalog_product_super_* tables
I won't tell catalog_product_relation is useless – in fact, it's necessarily there for something. But from version 1.5+, this is not there that links are stored, and I can't explain what does its purpose is.
First step
The first step of the linking process is the definition of the configurable product's configurable attributes. Supposing we're creating a new configurable product from an attribute set having a few global-select attributes.
If you try to access to your configurable product, the application will ask you which of 'em should be used as configurable attributes, in a form using a list of checkboxes associated to each attribute. By selecting some and saving your product, you insert in catalog_product_super_attribute a row by attribute (an association between product's id and attribute's one).
Second step
The second step is the linking itself with the associated simple products. This step is a bit more complex, because it implies some checks of the database's content, which we'll detail further below. Some rules to keep in mind about that :
only products having the same attribute set as the current configurable product
options must be defined for the configurable attribute
only one simple can be linked for a given configurable attribute combination
simple can be linked to as many configurables as desired
Then, what happens when we go to our configurable's associated products tab ? Don't be scray to not see any of your simple-corresponding-product in the list that display – it's filter is configured by default to display only already linked products. Here is what happens behind the scene :
the application go check the catalog_product_super_attribute table, and bring back each corresponding attribute id defined there for the current product (our configurables attributes)
from them, it will go check eav_attribute to get some details about them – in which ones the backend_type, which is the more important part of this explanation
parallely, the catalog_product_super_link table is checked too. Any product linked to current_product is a potential linked product
for each attribute, the application check if a value exists in catalog_product_entity_{backend_type} for each potentially linked product. Note that if no value exists for a given product, it won't be validated nor as a potential link nor than an effective one, even if it has already been linked (we'll see below what it implies for attribute creation).
To resume, only products with a valid value are diplayable and effectively linked / linkable. Note that all of the combination must have valid values – if any of the configurable's attribute as none, game over, you'll not have any link between your simple product and its configurable counterpart.
We should think it's ok, and everything will go right now, since we know how everything works in database. That's true if you always create your attributes from the application's back-office. But since scripting attributes is a very common way to proceed, you're much like to be in this second case, which implies a potential HUGE problem.
Programatically created attributes and... What the hell !?! This attribute has change of backend type !
Edit note: this case happens effectively when using a eav/entity_attribute_source_table source model
This a trouble I personnally runned through. If you check attributes backend models in database (only for select attributes – we do not care about which ones are not usable as configurable's ones), you'll see some varchar, some int... In short, multiple ones, and we could rightfully expect any of them works.
And they do so. Since you do not decide to add an option to your attribute from the back-office, or anything else that require to click on the « save » button on the attribute page.
The point is that when you save your attribute, Magento, in it's great goodness, ask itself what is the type of the attribute you ask him to save. The point is that before anything else, it's a select. And a select has options. And options has id. Which are the values that will be put in catalog_product_entity_{backend_type}, in any case. The label is just properly ignored in that (it's stored in it's proper table and doesn't affect anything there). Only the id is used.
And what shall we expect from Magento :) ?
It just change the attribute backend type to int systematically.
So, if you have products that used to be linked and are no more, go check the catalog_product_entity_{backend_type} tables and the eav_attribute one – compare the backend type, look for values in each values table... If you find 'em in a table that does not correspond, you get your problem. You have a few ways to correct the problem, here are the both I find myself (and I really do not promote the first, which I put only for explanation purpose).
First way: get the backend type back (The Dirty Trick)
It has changed to int ? Don't care. Bring it back to what you want it to be.
Why it's dirty : because you want you user to be able to update it's attributes when he wants. If you update the backend type to varchar, for example, any label change in the back-office for an option will rollback to int as it will be saved.
Second way: let's correct everything ! (The Right Thing)
You can pass throught this... bad situation, with a bit of MySQL without harming your database. But please, first, dump it. Then you'll require 4 steps :
check that you don't already have the data in catalog_product_entity_int table
duplicate the rows of the current ...entity{attribute} table to the ..._entity_int one by using an INSERT / SELECT statement (this query can be a bit long)
update your configurable attributes (not all your attributes, ONLY the ones you know you have created and are use to set configurable products) to set their backend type to int (and never do something else again for configurable selects :) )
delete all entries corresponding to attribute in the ..._entity{attribute} table that you'll no more use (it can do pretty much entries since you can have a lot of products if you get a lot of options)
Here are some MySQL scripts, corresponding to these steps, supposing you have at start a list of the attributes codes concerned :
Check existing entries in entity int for a given list of attribute codes
-- Check existing entries to not duplicate
SELECT ea.attribute_code,
count(*)
FROM eav_attribute as ea
INNER JOIN catalog_product_entity_int as cpei
ON ea.attribute_id = cpei.attribute_id
WHERE ea.attribute_code IN(
{attributeCodesList}
)
GROUP BY ea.attribute_code
Duplicate entries from entity_varchar table (for example) to entity_int for a given list of attribute codes
-- Duplicating missed selects from varchat entity table to int
INSERT INTO catalog_product_entity_int (entity_type_id, attribute_id, store_id, entity_id, value)
SELECT cpev.entity_type_id,
cpev.attribute_id,
cpev.store_id,
cpev.entity_id,
cpev.value
FROM eav_attribute as ea
INNER JOIN catalog_product_entity_varchar as cpev
ON ea.attribute_id = cpev.attribute_id
WHERE ea.attribute_code IN(
{attributeCodesList}
)
Update attributes to never have the problem again!
-- Update missed select attributes from varchar backend type to int one
UPDATE eav_attribute as ea
SET ea.backend_type = 'int'
WHERE ea.attribute_code IN (
{attributeCodesList}
)
Remove the no more used entries from your database
-- Kill old varchar in varchar entity table
DELETE FROM catalog_product_entity_varchar
WHERE attribute_id IN (
SELECT ea.attribute_id
FROM eav_attribute as ea
WHERE ea.attribute_code IN (
{attributeCodesList}
)
)
Hope it will help all of the ones who can't make their associated products show up to get the trick!