Tag: magento

  • Which part of MVC do Magento blocks belong to?

    Someone said Magento was not strictly MVC structured. I am intended to accept this point. But MVC does give people an easy way to understand how system works. So if I regard Magento as an MVC system, which part of MVC do Magento blocks fall into?

    I used to think blocks were Views because they were tied with templates. As time goes, now I think blocks are Models because blocks implement a lot of business logic as Magento model classes. Today I have another reason to support blocks are Models:

    When a frontend_model is initialised for a Sytem Configuration field or an EAV attribute field, it is actually a block class.

  • Lack of ideas to manage javascript in Magento

    In Magento System >> Configuration >> Catalog >> Frontend, when List Mode selected value is changed, some fields (i.e. Products per page on Grid allowed values, Products per Page on Grid default value, Products per Page on List allowed values, Products per Page on List default value) are shown/hidden accordingly.

    List mode showing both grid and list options
    List mode showing both grid and list options

    List mode showing only grid options
    List mode showing only grid options

    I had thought List Mode had a special frontend model defined so it could interact with other fields. I spent an hour to search for special settings of List Mode but did not find any. Instead I was disappointed to find out the frondend interaction is not defined in xml or php class, but by app/design/adminhtml/default/default/template/system/config/js.phtml.

    The way Magento did this kind of interaction is not replicable, which is a pity. By and large, the way how Magento uses javascript is messy. Maybe I am asking too much from Magento. What I am keen on is a “Google Web Toolkit” way, that means no need to manage javascript at all because javascript is compiled from server end script.

  • Lack of EAV framework for php

    最近我在仔细研究 Magento EAV 的机理。

    Magento 的强大跟 EAV module 的强大有很大关系,花点时间去研究很值得。我还发现 Magento EAV module 中一些不足之处,但我无力改进。于是想借鉴一下其他的 EAV framework 是怎么实现的,悲惨的是,如果说到 EAV php implementation,似乎 Magento EAV 就是唯一一个成熟的开源方案。但 EAV java implementation 倒有一些独立的选择。

    这是不是暗示 php 先天不足?尽管 Magento 让 php 在电子商务领域出尽风头,但这很可能是 php 的极致了。

  • Improve Magento entity setup

    Magento 文档鼓励用 entity setup (Mage_Eav_Model_Entity_Setup) 的方式去定义实体。这个类很强大,但我觉得不够灵活,因为无法用它精确控制 attribute, attribute group 和 attribute set。

    Attribute group 和 attribute set 是在两个维度分组 attribute,这样来组织 attribute 基本够用。但 setup 这个类添加 attribute 时,有不够周到的逻辑:

    如果 $attr[‘user_defined’] == 1 && empty($attr[‘group’]),那么这个 attribute 不会被添加到任何 attribute group 和 attribute set。我觉得更好的逻辑是添加到 general attribute group。

    如果 empty($attr[‘user_defined’]) && !empty($attr[‘group’]),那么 $attr[‘group’] 会被忽略,attribute 总是被添加到 general attribute group。

    没办法,已经这样啦,提供 install entities array 时,就避免进入这两种逻辑吧。

    如果我来重写 setup 类里的 addAttribute 方法,我会:

    1. 忽略 $attr[‘user_defined’] 对逻辑的影响。一个 attribute 的 user_defined 值只决定是否允许用户用 GUI 修改该 attribute。
    2. 增加对 $attr[‘attribute_set_name’] 的检查。如果 !empty($attr[‘attribute_set_name’]),则添加该 attribute 进相应的 attribute set 或 attribute sets。现有逻辑是把 attribute 一股脑地添加进所有的 attribute sets。
  • Dataflow profile back to work in Magento 1.5.0.0

    Magento 1.5.0.0 目前还是 alpha2 版,因为安装到第二步就有一个很明显的 bug,本来想等等再用的。

    可是 1.4.2.0 正式版 dataflow profile 跑不起来,一点 “Run Profile in Popup”,出来的 popup 就是空白。我很喜欢用外部编辑器格式化好数据,然后用 dataflow import 到 Magento 数据库。我有很多 modules 也用到 dataflow 来完成初始化,如果 dataflow 跑不起来,会给我造成很大的麻烦。

    联想到 Magento 1.5.0.0 在 release note 里说到它对 dataflow 作了改进,我想很可能修正了 1.4.2.0 带来的 bug。两害取其轻,所以我跳过 Magento 1.5.0.0 的全新安装过程,用 1.4.2.0 的数据库让 Magento 1.5.0.0 跑了起来。果然如我所料,dataflow profile 在 1.5.0.0 下工作正常。

    Dataflow profile back to work in Magento 1.5.0.0
    Dataflow profile back to work in Magento 1.5.0.0
  • Too early to try Magento 1.5.0.0 alpha2

    Magento 1.5.0.0 alpha2 出来了,我下载来尝鲜。可是,安装到第二步就进行不下去了。提示是:

    There was a problem proceeding with Magento installation.

    Please contact developers with error messages on this page.

    Notice: Undefined variable: params in /path/to/magento/app/code/core/Mage/Core/Block/Html/Select.php on line 142

    这挺令人失望的。

  • Magento page speed benchmark

    There are some website benchmark tools, looking after various aspects of performance.

    The tool I use most is Apache Benchmark, and parameters are 10 concurrencies, e.g.

    ab -c 10 -n 200 (page_url)
    

    It reflects the status quo. I have a decent server but the sites are not busy.

    Since I dived into Magento, I have been spent quite a lot researching how to improve its speed. I implemented database query cache, enabled block html cache, utilised memcache, tmpfs, apc, etc, etc. Recently I started a project called Full Page Cache Preparer (FPCP) and expected it fundamentally improve Magento speed on Catalog and Cms pages.

    FPCP is only 20% completion (it is not producing all blocks with session variables, but shopping cart sidebar), but I am eager to see some result. So I turn it on and compare the Requests Per Second to the time when it is off. I see a marginal 1-2% improvement which is very disappointing.

    Why I had the impression that full page cache feature will dramatically drive Magento faster? What if full page cache is working with web server cache, say nginx ncache? I simulate a test by saving a page html source code to a static file and uploading it to web server. (I should have done this test before I started FPCP project.) The result is disappointing, again.

    The test is done on a heavy page (with loads of images).

      ADSL connection (8,187/1,291 kbps) to datacentre 100 mbps ADSL connection (4,212/1,078 kbps) to datacentre 100 mbps directly run ab test on webserver
    Request via Magento /index.php 9.18 4.56 16.23
    Request a static .html file on filesystem (bypass php parser) 8.23 4.65 3368.82
    Request a .php file on filesystem (same content as .html, no php tag inside) 8.72 4.62 1584.05

    The figures in first two columns (ADSL connection) go up and down when I run tests again and again. Sometimes requesting a static file is even slower than requesting Magento index.php. My conclusion is, even when Magento full page cache is working in conjunction with nginx ncache, I cannot feel the sites are faster (when the server load is not high).

    However, I will finish my FPCP module (some day) because I believe it benefits people whose server load is high. To improve my own sites, I will focus on basic (if I call FPCP hi-tech) page speed recommendations, e.g., optimise images, concurrent downloads, cookieless domains for static files, merge js/css files, gzip, etc.

  • Magento helper class is a singleton desin pattern

    Magento did not mention this (or hide somewhere I could not find), so I’d like to mention it:

    Magento helper class is a singleton desin pattern. Whether a helper class is called in a format as

    Mage::helper('mymodule')->helperMethod();
    

    or as (in a block class or a template),

    $this->helper('mymodule')->helperMethod();
    

    the helper class is only initialised once.

    Which means Magento puts a singleton desin pattern on helpers.

  • yum install php-5.3-curl-zend-server

    我快被 zend server 搞疯了。不过说到底是我自己不好——新装了一台 Fedora 14,添了 zend.repo 以后忘了运行

    yum install zend-server-ce-php-5.3
    

    过了几天开始用它来调试 Magento。貌似 zend server php 替换了原有的 fedora php,因为 php.ini 是来自 /usr/local/zend/etc。这给我很大程度上一个误导,以为 zend server 已经装好了。

    结果 Magento 跑不起来,第一个错误是没有 pdo,我略有纳闷,zend server 怎么不代我完成 pdo 安装?不过没细想,用

    yum install php-pdo-mysql
    

    解决问题。(不过回想起来,也没搞清楚这到底装了哪个版本的 pdo)

    随后发现进不了后台,第二个错误是没有 curl,这下折腾了两个小时,用

    yum install php-curl
    

    说已安装(fedora 把 php-curl 包含在 php-common)。然后我用

    yum reinstall php-curl
    

    当然无济于事。试遍各种可能的命令都不成功,两小时后发觉 zend server 没装过,于是一装 zend server,顺利启动 Magento。

    最后说一下,如果非要单独装 zend server 版的 php curl,可以用

    yum install php-5.3-curl-zend-server
    
  • Mage_Adminhtml_Controller_action

    今天发现,我的所有的 admin controller 都写成了 extends Mage_Adminhtml_Controller_action。虽然不影响使用,我还是想把它改规范的驼峰式 Mage_Adminhtml_Controller_Action。

    于是搜索了整个硬盘到底哪些文件里包含 Mage_Adminhtml_Controller_action,结果发现这个笔误还不少。而且不光我写的 modules 里有,Aheadworks, J2t, Plieninger 的代码里也有,最后发现源头是 koukou1985 的 Magento module creator。

    看来 Magento module creator 流传甚广。