Magento's rule-based product relations (up-sell, cross-sell etc) are stored in a database table, and I assume they are updated once in a while. Unfortunately, I can't find any documentation about when that happens or what triggers it. Is it:
Cached, like a block, and expires after a certain time?
Generated whenever you save a product?
Generated by CRON?
I'd really appreciate it is someone could fill in the blanks for me. I'm using the Enterprise edition, if that helps or makes any difference.
So I dug around the product link data a bit. The relevant object we're looking at here is catalog/product_link, which the catalog/product object uses to retrieve linked object data.
While grouped and bundle products seem to write to this in cronjobs, I have not found any cases where this data is written in a cron-job for actual upsell/cross-sell products. I will keep digging a bit, but this seems to imply that the products are calculated at save time.
Hope that helps!
Thanks,
Joe
Search for the observers on events "catalog_product_save_before" and "catalog_product_save_after" to see in your project when it is fired and what function is called.
In the enterprise edition the observer fired is enterprise_targetrule/observer, function : catalogProductAfterSave ...
Related
I am working on a custom Magento module to enter Composer information (name, bio, birth, death, etc.) and associate products (songs) with the composer. The module contains two tabs, one for the general info and the other for a list of the products (songs). The association should work exactly as the functionality of Related Products, Up-sells, and Cross-sells in the Product editing page. I feel like I've been running around in circles on a few points in regards to paging through the available songs and selecting and saving the entries. It's mainly dealing with the Grid Serialization. I've looked through as many resources as I can find, including several tutorials, without any luck:
http://magebase.com/magento-tutorials/understanding-the-grid-serializer-block/
I've posted the relevant files at this Gist and would appreciate any feedback or discussion. The files have a lot of material commented out from trying various solutions but they may prove useful in terms of thought process. Certainly available to post any other files that may be relevant.
I think this answer is exactly what you need. I know that single link answers are not very appreciated but the answer is kind of long to replicate in here.
You can also use this module creator to create you module (also available on magento connect). It has an UI that let's you create the modules in a similar way with how you create a table using phpMyAdmin. For each entity you create in your module you have the ability to say "Link many to many with products". This will create the the relation table between products and your entity and the second tab in the admin where you can choose products that are associated with your entity. Exactly like the products in the categories or like related products.
I admit that I'm the developer of the extension, but this should not be considered as spam since the extension is free and I get no profit out of it.
I created an extension for joomla using:
$id=$database->insertid();
I just covered that if two users are logged on to the site will fit together perform two records in the database and then this statement will return in both cases the same value.
in php you can solve this problem with the transactions.
In joomla how do I solve this problem?
If you have a table you are working with that extends JTable then make sure that you included the check out functionality that is optionally a part of that. THis must means adding a couple of fields like what is in the content table. This will prevent two people from editing the same row at the same time which creates a race condition in which one of the other will lose their data.
Please note that both php and joomla functions to return the last insert id rely on the mysql implementation, and mysql returns the last id inserted on the currently open connection so concurrency is not an issue
#iacoposk8 Your are right it might possible that in very rear case. Such time try to add current logged in user id in your sql query or any where so that it doesn't make any confict. I hope you get it what i want to say. Thanks
I'm terribly sorry to post this question here, but RedCOMPONENT just does not bother to answer my forum post or anyone else for that matter.
All I want to know, can this mod_products from RedCOMPONENT display featured products as well as products from a specific brand?
Thanks in advance.
You won't be able to do it with the extension you mentioned unless you code it yourself. I haven't looked into redSHOP majorly before and I;m not going to pay to download the module you mentioned, but in one of the PHP files, there will be some code retrieving the products from a specific table column using an SQL command. You could always try adapting this so that (if features products have their own table column) the SQL command retrieve products from both columns.
Else, you might be interested in this module which shows the features products for RedSHOP.
http://extensions.joomla.org/extensions/extension-specific/redshop-extensions/13964
You should use mod_redshop_featureproduct module.
I know EAV logic and I know what is eav_entity_attribute for. (about eav_entity_* - the same).
But I'm not clear about table eav_entity. It is always empty.
Could someone give some comments please.
I would be glad to get any assumption.
Google gives nothing on this question, as usual)
Doing a grep of the Community Edition code, the only time eav_entity is mentioned is in the config file (/app/core/code/Mage/Eav/etc/config.xml) and in the database setup files (/app/code/core/Mage/Eav/sql/eav_setup/mysql4-install-0.7.0.php).
To me this says that it was put in just before a release and then never actually used. The devs possibly decided to go with a slightly different way of storing the data...
I expected to see all records of all entities in the table eav_entity. But I see that Magento has created separate tables for each of the 8 entities ( customer, customer_address, category, product, order, invoice, shipment, creditmemo) with the following table names ( customer_entity, customer_address_entity, catalog_category_entity, catalog_product_entity, sales_flat_order, sales_flat_invoice, sales_flat_shipment, sales_flat_creditmemo). So eav_entity table is empty and you get data for entities directly from their respective tables.. Some level of de-EAVing the database design :-)
After building some frontend stuff, I'm now exploring the internals of the admin side of Magento. I read Alan Storm's article on creating a simple model (as opposed to an EAV model, something which I am not yet ready for).
My main goal is to create a module that enables the user to upload and manage media to the Magento installation, so that it can be used in some templates I defined in the frontend. So I would create a model to keep track of the relations between certain media (pictures) and certain categories, pages, you name it. Just for the record: I don't like EAV models, they scare me, so unless it's absolutely necessary, don't push the conversation that way. Thank you :)
I've also skimmed through this article.
It's about backend models, and my question is about that:
What IS a backend model?
Is it a model that's used only in the backend (admin)? I wouldn't know what that would be good for. If someone could tell me something about it, or give me a hint on what to read to know more about it, it'd be great.
The reason I'm telling what goal I want to reach is so that someone can tell me if these "backend models" are significant to what I want.
Thanks!
Don't worry about EAV, don't worry about "backend models". You'll need some in the trenches programming experience before you can fully understand their significance. You can get a lot done with the plain-jane Magento model classes and SQL queries.
The light version: Backend models have nothing to do with the frontend-cart/backend-admin application split. A "backend model" handles loading, storing, and persisting information into a datastore (the database). A "frontend model" is PHP code that handles rendering a user interface element to display the attribute in the web browser. The terms are used in several different systems in Magento, including EAV and the System Configuration section.
The article you linked to is talking abou EAV backend models. Again, the light version: Each data property of an EAV model is, itself, an object. For example, in a simpler system you'd store the product's name as the string 'Bicycle'. In Magento you assign a product attribute object to the parent EAV model for name. This way, the code for saving "name" to the database can be kept separate from the other saving code.
Long story short, It's overkill for what you're after.
In Magento backend attribute models is used to prepare data before placing it in the database. This preparation is done by beforeSave method. A good exampe is Mage_Eav_Model_Entity_Attribute_Backend_Datetime