Some very basic, rather obvious, best practices for Magento developers:
http://prattski.com/magento-dev-best-practices/
I recommend reading them to any Magento developer. Be honest: Do you follow all of them?
Dipl. Inform. Fabian Schmengler | Magento Certified Developer | Magento Certified Solution Specialist
Some very basic, rather obvious, best practices for Magento developers:
http://prattski.com/magento-dev-best-practices/
I recommend reading them to any Magento developer. Be honest: Do you follow all of them?
I compiled a list of the most important Magento specific development tools in my toolbox. Additions are most welcome!
Greetings to the Magento Stammtisch Aachen guys, this is for you 😉
http://www.magentocommerce.com/magento-connect/magneto-debug-8676.html
A free extension that integrates a developer toolbar in the Magento Layout where you find various information about the current page:
http://store.pulsestorm.net/products/commerce-bug
Another integrated developer toolbar for $49.95 that offers mostly the same features but with two important additions:
http://www.ecomdev.org/shop/code-testing/php-unit-test-suite.html
PHPUnit extension for unit tests and integration tests. Includes database fixtures, configuration tests and more. See PDF documentation for details.
https://github.com/alistairstead/MageTool
Command line tool for shop management and extension development. Some features:
Activate the Zend SQL Profiler with the following node in your local.xml
:
<resources> <default_setup> <connection> <profiler>1</profiler>
Then you can access the profiler somewhere in your code and retrieve a lot of informations about all executed queries:
$profiler = Mage::getSingleton('core/resource') ->getConnection('core_write')->getProfiler();
To simply output all queries:
print_r($profiler->getQueryProfiles());
There is a way to rewrite carrier classes of shipping methods but it is not obvious and required me to browse the shipping module source:
If you look at Mage_Shipping_Model_Config
, you will discover that the code used as parameter for Mage::getModel()
is taken from the store configuration. This code is NOT the standard code like 'shipping/carrier_tablerate'
, so it does not help overriding as usual.
Now you have to find out first what this code is. For example I wanted to override the matrixrate carrier, so I tested it like that:
$carrierConfig = Mage::getStoreConfig('carriers/matrixrate') var_dump($carrierConfig['model']);
Yes, you can put this code anywhere on the page temporary but it is useful to have a separate file for such things that can be run from the command line (starting with Mage::app()
to initialize Magento)
In my case the code was matrixrate_shipping/carrier_matrixrate
so I had to change my config.xml like that:
<global> <models> <matrixrate_shipping> <rewrite> <carrier_matrixrate>my_class_name</carrier_matrixrate> </rewrite> </matrixrate_shipping> </models>
instead of
<global> <models> <matrixrate> <rewrite> <carrier_matrixrate>my_class_name</carrier_matrixrate> </rewrite> </matrixrate> </models>
If you add a new attribute to the customer entity in a a setup script, using addAttribute()
, gets a surprise starting from Magento 1.5. The setup runs and database entries in customer_eav_attribute
are created correctly but in the backend there is no new form element.
Which works well with other entities like categories and until Magento 1.4 also with customers, needs an additional setup step now, to add the attribute explicitly to the admin form (and/or other forms, like the registration form).
There is a new table for it, customer_form_attribute
, which defines for each attribute, in which forms it can be used:
mysql> select * from customer_form_attribute;
+----------------------------+--------------+
| form_code | attribute_id |
+----------------------------+--------------+
| adminhtml_customer | 1 |
| adminhtml_customer | 3 |
| adminhtml_customer | 4 |
| checkout_register | 4 |
| customer_account_create | 4 |
| customer_account_edit | 4 |
| adminhtml_customer | 5 |
| checkout_register | 5 |
| customer_account_create | 5 |
| customer_account_edit | 5 |
| adminhtml_customer | 6 |
| checkout_register | 6 |
| customer_account_create | 6 |
| customer_account_edit | 6 |
| adminhtml_customer | 7 |
| checkout_register | 7 |
| customer_account_create | 7 |
| customer_account_edit | 7 |
[...]
+----------------------------+--------------+
88 rows in set (0.00 sec)
So much to for a better understanding, of course you don’t need to (and should not!) modify the database manually, it is sufficient to add the following lines after the addAttribute()
call in your setup script:
Mage::getSingleton('eav/config') ->getAttribute('customer', $attributeCode) ->setData('used_in_forms', array('adminhtml_customer')) ->save();
with $attributeCode
being the unique code of the new attribute and 'adminhtml_customer'
the code for the customer management form in the backend. To keep setup scripts more clear if you add multiple attributes, it helps to extend the entity setup class, like this:
class MyNamespace_ExtendableCustomer_Model_Entity_Setup extends Mage_Customer_Model_Entity_Setup { public function addAttributeToForm($attributeCode, $formCode) { Mage::getSingleton('eav/config') ->getAttribute('customer', $attributeCode) ->setData('used_in_forms', (array) $formCode) ->save(); } }
Now when you use this class for your setup scripts that add customer attributes, it’s as simple as:
$this->addAttribute('customer', 'new_attribute', array( /* ... */); $this->addAttributeToForm('new_attribute', 'adminhtml_customer');
Of course you can add the attribute to other forms in the same way, for the codes see the list above.
Thank you to the Magento forums for the crucial hint.
Pay attention, on save the field eav_entity_attribute.sort_order
gets set, regardless being specified before!
See my comment on StackOverflow.
Furthermore sort_order
only applies if user_defined => 0
was specified in the attribute setup because Magento sorts by user_defined
first and then by sort_order
.