To add or update an EAV attribute in Magento, it is necessary to add setup scripts to your code base. If you don’t handle your custom attributes in setup scripts, you are not able to install your project from scratch, which could cause a lot of problems. For example, it makes it harder to run unit- and integration tests.
So lets assume that we are working in a team with 4 developers and everybody has a different task. Each task needs a custom attribute in a different entity_type.
I want to share my thoughts and summarize an overview of how the 4 developers could implement their setup scripts. Also, I want to show the advantages and disadvantages of each method.
Option #1 – Include Setup Scripts into Module:
It happens very often that a new attribute is required by a new feature. So it seems to be clever to add the attribute into your module context. As long as everybody in the team knows, that this attribute is stored in that module, you won’t have a problem. The problem will appear when your system requires hundred’s of EAV attributes. If a developer wants to make a change, he won’t know where to start at first and has to start the search struggle.
Conclusion: Good solution for standalone modules. Small systems could also use this solution without bigger worries but keep in mind that you won’t be able to scale proper.
Option #2 – Add a base Module:
Sometimes a Magento System owns a module like ‘Vendor_Base’ or ‘Vendor_Setup’. Those modules provide the whole functionality to setup a store from scratch. This solution is cool to debug.
Is there a problem with the setup?No problem, I just look into the base module.
The problem of this solution is the same as the problem in option #1. What happens when the system requires hundred’s of attributes? The base module is getting messy! A base or setup module could also cause other problems, because the name ‘base’ or ‘setup’ tells you, that it does not only contain attributes. It could contain other scripts or functionality like a product import.
Conclusion: Option #2 is a better way than option #1 because you already bundled the attributes, but you have to be careful with the module name. Don’t name it ‘setup’, ‘base’, ‘default’ or any other random name. Try to give your module an explaining and meaningful name. For example ‘Vendor_AttributeSetup’.
Option #3 – Add a Module for each entity_type:
The third option is to split up your custom attributes into several modules. One module for every entity_type. In case you can’t remember, the eav_entity_types are the following:
- customer
- customer_address
- catalog_category
- catalog_product
- order
- invoice
- creditmemo
- shipment
The modules would named like this:
- Vendor_CustomerAttributes
- Vendor_AddressAttributes
- Vendor_CategoryAttributes
- Vendor_ProductAttributes
- Vendor_OrderAttributes
- Vendor_InvoiceAttributes
- Vendor_CreditmemoAttriubutes
- Vendor_ShipmentAttributes
This option is a a way to manage a huge amount of EAV attributes and have an overview of the different kinds at the same time. The module names are very exact so every developer will instantly know what is inside the module.
Conclusion: Option #3 is my preferred way to handle EAV attribute scripts because it can be extended very easy. The naming is also very clear and I think it is never an overkill to add one more module when there is a valid reason for it. In most cases, a system won’t require attributes of all entity_types.
After this summary, the way to manage attribute scripts depends on the size of the project.
As I already mentioned, my favorite way is option #3. There are meaningful modulenames, the attributes are bundled and the modules are nice and handy.
Leave your thoughts in a comment and let me know if I can add more ways.
Update: Option #4 – Aoe_AttributeConfigurator (DRAFT / DO NOT USE IN PRODUCTION)
Tobias Schifftner gave me a hint that there is a module from AOE which tries to give developers another way to handle attributes. The module provides the functionality to configure EAV attributes by a single XML file. This method is similar to the option #2 because it also bundles all your custom attributes. The module is available here but you shouldn’t use it in production. It is made for Magento version 1.7, so it is a little old. The idea of this module is still great and I will keep that in mind for further hackathons!
