I'm sorry to keep beating a dead horse, but this quantity bug still isn't fixed in Magento. I fixed it in Agent Ohm almost 2 months ago.
http://github.com/markkimsal/agent-ohm/commit/496caa56c7c7796d02f7b922fe4beae3c6fbc132
If you're in Europe and you like to count ten thousand as 10.000, Magento will treat it as just ten.
http://svn.magentocommerce.com/source/branches/1.4-trunk/app/code/core/Mage/Checkout/Model/Cart.php
Tuesday, 15 September 2009
Thursday, 16 July 2009
API Docs
I just uploaded HTML API documentation for Agento Ohm.
http://code.google.com/p/agent-ohm/
It was generated with my own secret c2x documentor. It only took about 4 minutes to scan and generate the entire thing. Incremental documentation only updates files that have changed (SHA1) hash so it's only about 1/10th the time to generate second time around. And it uses about 1/10th the RAM that phpdoc needs. If anybody is interested in beta testing c2x let me know via github or comment here.
http://code.google.com/p/agent-ohm/
It was generated with my own secret c2x documentor. It only took about 4 minutes to scan and generate the entire thing. Incremental documentation only updates files that have changed (SHA1) hash so it's only about 1/10th the time to generate second time around. And it uses about 1/10th the RAM that phpdoc needs. If anybody is interested in beta testing c2x let me know via github or comment here.
Wednesday, 17 June 2009
Quantity Bug
I found another Magento bug today, going to fix it in Agent Ohm first.
When ordering quantities 1000 or greater, Magento cannot parse non-US number formats. In Spain, if you were to order "10.000" of an item, you would expect to get ten thousand of that item. But Magento gives you 10 only. The fix isn't as easy as using Zend_Locale_Format::getNumber (although this function does properly parse the number). Something even deeper is wrong with Magento.
This is just one more issue that points to the fact that Magento undergoes no automated testing before it is released.
The function "getNumber" in Mage_Core_Model_Locale says that it uses the current locale setting, but it does not. The locale is not referenced in the code at all.
When ordering quantities 1000 or greater, Magento cannot parse non-US number formats. In Spain, if you were to order "10.000" of an item, you would expect to get ten thousand of that item. But Magento gives you 10 only. The fix isn't as easy as using Zend_Locale_Format::getNumber (although this function does properly parse the number). Something even deeper is wrong with Magento.
This is just one more issue that points to the fact that Magento undergoes no automated testing before it is released.
The function "getNumber" in Mage_Core_Model_Locale says that it uses the current locale setting, but it does not. The locale is not referenced in the code at all.
Playing with the Zend Framework
http://libertini.net/libertus/2009/03/11/playing-with-zend-framework/
This blog entry is parallel to this entire blog to a certain degree. If you're interested in bogging about code analysis, you might like it.
This blog entry is parallel to this entire blog to a certain degree. If you're interested in bogging about code analysis, you might like it.
Wednesday, 20 May 2009
How many times can I fall victim to the same bug?
I just lost about an hour tracking down a problem resulting from a naive transfer of a running Magento site to another server. If you simply use an old mysqldump client, or phpmyadmin your dump file will be corrupted, don't use it. Use mysqldump from 4.1 or later.
So, the problem revolves around magento using a frown-upon practice of staring primary keys at 0. Normally, in mysql, if you insert a value of NULL or 0 into a primary key field, it will run its sequence generator and give you the next sequence. Combine this fact with the nicety of your dump files specifying which auto increment to start at in the table definition, and you can say goodbye to your admin store (store_id 0) after you import.
The mysqldump tool will spot this and insert a call to change the SQL mode to "NO_AUTO_VALUE_ON_ZERO" for you, but phpmyadmin will not! Also note that Magento's own DB dump feature will put in "NO_AUTO_VALUE_ON_ZERO" for you as well.
Remind me to get rid of this bad, highly error prone, and frustrating "feature" of Magento - primary keys starting at 0 have to go.
So, the problem revolves around magento using a frown-upon practice of staring primary keys at 0. Normally, in mysql, if you insert a value of NULL or 0 into a primary key field, it will run its sequence generator and give you the next sequence. Combine this fact with the nicety of your dump files specifying which auto increment to start at in the table definition, and you can say goodbye to your admin store (store_id 0) after you import.
The mysqldump tool will spot this and insert a call to change the SQL mode to "NO_AUTO_VALUE_ON_ZERO" for you, but phpmyadmin will not! Also note that Magento's own DB dump feature will put in "NO_AUTO_VALUE_ON_ZERO" for you as well.
Remind me to get rid of this bad, highly error prone, and frustrating "feature" of Magento - primary keys starting at 0 have to go.
Monday, 18 May 2009
checkout_cart_product_add_before
There is no event in Magento called "checkout_cart_product_add_before", but it is sorely missed.
Dealing only with "checkout_cart_product_add_after" means that you cannot easily massage the input data for a product. Basically, what this means is, if you are trying to manipulate product attributes which aren't submitted directly in the POST data, then you're in for a rough ride.
If your attributes aren't within certain bounds, or are completely non-existent, then you can't ever get your product into the cart. One solution is to make the attributes not "required" and massage the POST data into your attribute data after adding the product to your cart. But that just means that you have to duplicate all the bounds checking yourself, and go through the extra step of removing the item if it fails attribute validity checking (see: core/Mage/Catalog/Model/Product/Type/Abstract.php: public function prepareForCart)
Going to add the event checkout_cart_product_add_before to Agento-Ohm.
Dealing only with "checkout_cart_product_add_after" means that you cannot easily massage the input data for a product. Basically, what this means is, if you are trying to manipulate product attributes which aren't submitted directly in the POST data, then you're in for a rough ride.
If your attributes aren't within certain bounds, or are completely non-existent, then you can't ever get your product into the cart. One solution is to make the attributes not "required" and massage the POST data into your attribute data after adding the product to your cart. But that just means that you have to duplicate all the bounds checking yourself, and go through the extra step of removing the item if it fails attribute validity checking (see: core/Mage/Catalog/Model/Product/Type/Abstract.php: public function prepareForCart)
Going to add the event checkout_cart_product_add_before to Agento-Ohm.
Thursday, 14 May 2009
Security Issue
I've found a security issue which may or may not be related to other bug posts on the magento bug tracker. I would not recommend anybody use the back-end order creation tool in Magento or Agent-Ohm until further notice.
Update: It is not recommended to run any multi-store setup under Magento or Agento-Ohm.
Update: Fixed in the latest Agento-Ohm
Update: It is not recommended to run any multi-store setup under Magento or Agento-Ohm.
Update: Fixed in the latest Agento-Ohm
Subscribe to:
Posts (Atom)