Author: 芳草苑主

  • Elements of same name in Zend_Form

    It is a rigid rule that Zend_Form can not have elements of same names. If I add a second element with the same name, the first one will be overwritten.

    When I started to use Zend_Form, I thought this rule makes life difficult. For example, if the form have “Next” and “Previous” buttons, I must give them different names. How can I tell which button is clicked? I must go through all names. I thought if these buttons could have same name but different value, it was easier to tell which button was clicked.

    It was before long I started to enjoy this rigid rule. Take the above example for example, it is NOT a good practice to judge which button was clicked by its value. Because for an internationalised program, the value may change and that is out of the programmers’ control.

    What if I want to add 5 text fields for people to fill in information like team members’ name? Two solutions. The first one looks stupid but I did not come across the second one at first.

    Solution 1:

    class MyNamespace_MyText extends Zend_Form_Element_Text {
    	protected $_name = "text";
    
    	public function init() {
    		static $sequence = 0;
    		$this->id = $this->_name . '_' . $sequence;
    		$this->_label = "Label " . ($sequence + 1);
    		$this->_name = $this->_name . '[' . $sequence . ']';
    		$sequence ++;
    	}
    }
    

    Solution 2:

    for ($sequence = 0; $sequence < 5; ++$sequence) {
    	$element = Mage::getModel('moduleName/modelName', "$sequence")
    				->setBelongsTo('text'); //my form is inside Magento
    }
    
  • Limitation of Mage::getModel method

    Magento getModel can not initialise an instance whose class requires more than 1 argument.

    I assume Magento native classes can explode options from the first argument to satisfy getModel. However, if I want to use 3rd party class like Zend_Form_Element inside Magento, there is no ways to use getModel to achieve the same result as

    $element = new Zend_Form_Text('name', $options);
    

    because

    $element = Mage::getModel('moduleName/modelName', 'name');
    

    takes 1 argument which is ‘name’ only. No way to pass $options on.

  • Drupal on php 5.3.0

    今天想安装 drupal,装了N遍终于成功。一开始想装6.14版,安装过程开始时,我按提示把 sites/default 目录设置可写,把 default.settings.php 改名为 settings.php(提示不准确!),同时设置可写,结果在数据库安装页面反复过不去。

    我联想到 Magento,猜想可能是因为 drupal 6.14 与 php 5.3.0 不兼容。

    那再试试 drupal 5.20 吧。数据库安装页面倒过去了,安装能结束,但抛出一大屏错误。试着进入后台,每个页面都抛出错误,有些功能执行不了,比如修改口令。这样怎么行?继续研究。

    我又看到 drupal 6.14 release notes,说 drupal 从 6.14 起 compatible with php 5.3.0 out of box。啊?说得这么斩钉截铁,那我重新再试。

    终于发现有人提到 drupal 6.14,sites/default 目录下不可没有 default.settings.php,也不可没有 settings.php。压缩包里只有 default.settings.php,所以提示说把它改名 settings.php 是误导,正确的做法是,新建一个 settings.php(可以是空文件),或者拷贝 default.settings.php。这下安装通过了,但还是抛出一堆错误,并不比 drupal 5.20 少。

    想了一下,可能是因为我没有给 drupal 6.14 一个全新的数据库,它是覆盖在原 5.20 的数据库上的,看来 6.14 安装过程不能自动升级数据库。于是再来一遍,这样终于成了(少数页面仍有小量错误)。

  • PDT path mapping

    今天折腾了一个晚上,终于明白一个道理:PDT 下,入口文件不能使用 path mapping,服务器上必须有入口文件才能 debug on server。入口文件所调用的文件才能 path map。

  • Make best use of Godaddy Free Products

    我不算一个好顾客——很挑剔,但可以算是 Google, Godaddy 和 Tesco 的忠实顾客,因为他们的产品或服务几乎无可挑剔——又扯远了。

    我要讲的是如何把 Godaddy 购买域名后的免费赠品用足用好。Godaddy Free Products 有 Free Hosting, Free Blogcast 和 Free Photo Album。虽然我另租 1&1 的服务器,但 Godaddy 这么客气,我想不要浪费了人家的热忱。再说,在  Godaddy Free Products 上搞搞实验,物理上跟生产服务器隔绝,用得也心安。

    只是 Godaddy Free Products 既然是免费的,同时广告也来了。拿它来建商业站点肯定是不合适的,就是自己人搞实验对着广告也烦。有没有办法去掉?我稍作搜索就有答案:可爱的 css 发挥一下

    #conash3D0 {display:none; }
    

    因为答案来得太容易,没有我发挥的空间总不心甘。于是我又想,我每装一个软件都要去改 css,太烦;有些 一键安装的产品(比如 Free Blogcast 和 Free Photo Album)也不允许我改 css,怎么办?答案是 user css。以 Mozilla Firefox 3.5.5 for Fedora 11 为例,具体做法是:

    打开 /home/{myusername}/.mozilla/profile.ini,看里面说的 profile path 是什么,通常是跟 profile.ini 同级的一个目录,名字是 {randomchars}.default。

    在 /home/{myusername}/.mozilla/{randomchars}.default/chrome 目录下新建一个 userContent.css,内容是:

    #conash3D0 {display:none !important; }
    

    使用 !important 只是保证这条规则的优先权,对付目前 Godaddy 的广告条,不用也可以。因为不在服务器端动手脚,恐怕 Godaddy 到死也不会意识到它的广告被屏蔽了。万一它改进 javascript 来探测广告条的 display 状况,那 user 再换一条规则:

    #conash3D0 {position:absolute !important; left:-10000px !important}
    

    也是一样效果(你的显示器不会大于 10,000 pixels 吧)。不过 Godaddy 不会有时间整天琢磨这些玩意,所以有两条规则备用足以。

    以此类推,对付 Godaddy Blogcast 广告,可以使用:

    iframe.adFrame, div.adBanner { display:none !important; }
    

    对付 Godaddy Photo Album 广告,可以使用:

    div#wrapper div iframe { display:none !important; }
    

    至于其他浏览器怎么建 user css,我摘抄一段前人讲的

    Internet Explorer for Windows

    1. Create a .css file in a convenient location using Notepad.
    2. Tools menu, Internet Options, General tab, Accessibility button.

    Opera

    1. Create a .css file in a convenient location using Notepad.
    2. File menu, Preferences, Page Style.

  • Known issues with PDT

    我对 PDT 还不熟,碰到很多问题,都分不清究竟是我不会用,还是 PDT 本身的错。其中一个安装在 Fedora 上的 PDT 已经用了有些日子了,配置被我改来改去,所以更加分不清是谁的错。今天狠狠心,全新下载安装了 PDT Galileo SR1 for win32 版。本来想离 Windows 远一些的,无奈,相对来说,我在 Windows 下用 PDT 比 Fedora 下更久一些,出了问题也更容易定位是什么问题。

    几个小时折腾下来,终于有了结论:

    1. PHP for Windows 本来是集成 odbc 支持的,但 PDT 带来的四个 PHP 解释器不知怎么搞的,就是不支持 odbc,我也不知道去哪里 enable odbc,因为 PHP 手册上说 windows odbc 是内置的。要在 PDT 使用 odbc,那就自己安装一个原版的 PHP 吧。
    2. 在 PDT 下安装 PHP 解释器,对话框有让我填一个 php 启动配置文件,通常是 php.ini。但如果原目录下有一个 php.ini,我想做一个专门用于调试的配置文件,取名叫 php-with-zenddebugger.ini,PDT 根本就不理我填入的文件名,直接去找 php.ini,真是浪费感情。
    3. 既然是自己的 PHP 解释器,ZendDebugger.dll 也得用原版的。当时我图省事,直接把 PDT 带来的 ZendDebugger.dll 拷到我的 PHP 解释器的目录下,不能用,后来比较了原版的,文件大小都相差好多,不知道 PDT 给的是什么版。
  • A good practice in naming rewritten Magento modules

    Magento 里的namespace, module name, controller name, action name, class name, function name, model name, router name, xml identifier name, etc, etc 实在太过复杂,凭我的脑袋实在记不全什么时候该大写,什么时候该小写,什么时候该加一个下划线。

    为了不出错,我尽量照抄 Magento source code,比如 extend Mage_Catalog 模块时,我取名 Myname_Catalog。我这个模块名作前缀重写了一些 Model 和 Block,没遇到问题。最近在重写 Controller 时,出问题了——如用/catalog/product/view/id/1 能执行重写后的 controller;但用/seo-product-page-name.html 却执行了重写前的 controller。这问题不一定是命名引起的,但我在寻找解决方案时意识到要有一个好的命名习惯。

    简言之,网上讨论比较多的 Magento upgrade safe 重写规则只适合 Model 和 Block,不适合 Controller。要写出 upgrade safe Controller 也不难,就是谈的人少,不容易找到适用于最新版 Magento 的文档。有空我整理一下如何在 Magento 1.3 下重写 controller,但这不是我今天想说的话题。

    我只想说我在重写 Controller 时意识到命名习惯。命名时肯定是用自己的 namespace,但也建议不使用原模块名。比如要重写 Mage_Catalog,不妨使用 Myname_Catalogue,这样最大程度地避免了可能的名字冲突。

  • Connect to mdb under Linux

    虽然没有实际意义,只想挑战一下自己,在 centos 下尝试连接 Access 数据库。装好了 unixodbc (原先就在 centos 里,可能是默认被安装的) 和 mdbtools、mdbtools-odbc,搞定了一切设置,可就是出不来。

    我是用 php odbc_connect 去连接 ActinicCatalog.mdb,页面一片空白,连个错误提示也没有,刚开始我还以为 web server 出问题。折腾了好久,最后,自己新建了一个很简单的 mdb 文件,终于在页面上显示出来了。

    总结经验,centos 连接 mdb 需要关闭 selinux,然后,如果页面空白(连跟数据库无关的内容也不显示)不要怪自己,要么怪 mdb 里的结构太复杂,要么怪 mdbtools 能力太弱,读不出来。

    大概只有微软自己知道怎么连接 mdb,第三方是不可能完全读懂它的了。

  • Mybookworld is not safe

    我的 Mybookworld samba service 建有若干用户,各自的目录是凭各自的密码访问。昨天发现,Mybookworld 竟然不再问密码,任由我畅行在各个用户目录。Mybookworld 有一个 ip address 和一个自称的 device name,还有一个路由器指派它的 device name。凭前二者访问仍然正常,只是凭路由器指派的 device name 访问时密码失效。

    我刚开始还以为我上次误点了“记住密码”,运行

    net use * /d

    Mybookworld 还是任由我畅通无阻。奇了怪了,难道 windows 有其他我不知道的地方记住了访问密码?转念一想,不是 windows 的原因,因为我不可能多次为多个用户误点“记住密码”。

    于是重启 Mybookworld,问题依旧。正好有个 firmware 更新,更新后问题还是依旧。没辙了!

    原本准备在 internet 上开放对 Mybookworld 的 ssh 访问,这下打消主意 —— Mybookworld 不够安全,samba 会出这等问题,保不准 ssh 也会出问题。

    别说我是事后诸葛亮,刚拿到 Mybookworld 时,我看了一下它的配置,就觉得它很容易出现安全漏洞。举个例子:用 Mybookworld 自带的 web interface 创建的用户并不是 Linux 用户,这些用户属组全是 root:jewab,使用 root 就是一个非常不好的 bad practice,况且权限控制依赖于 Mybookworld 自带的程序,一点也没用到 Linux 强大的权限控制。开发 Mybookworld 的人水平再高,难道能高到抛弃一套完美的机制自搞一套?

    再举个例子,启用 Mybookworld nfs 服务时可以指定 IP Allowed,但是 /etc/exports 却是这么写的

    /nfs/myname *(rw,all_squash,sync,insecure,anonuid=65534,anongid=65534)

    我非常不理解,nfs 服务明明可以限定 IP,然而 Mybookworld 又不用它,又在自搞一套。可它自搞的一套非常地不稳定,经常发生 allow list 上的用户不许访问。我不知道会不会有 deny list 上的用户反而被允许,那就更糟了。

  • Avoid PEM pass phrase

    我在制作 SSL key file 时输入了一个 pass phrase。CA 把 SSL 证书发给我后,我在 Nignx 试着加载 key 和 证书,发现每次重启 Nginx 时,都会被要求 Enter PEM pass phrase。岂不很烦,而且万一服务器重启,岂不还要人工干预才能重启 web server?

    原本以为把 pass phrase 从 key 文件里拿掉后,要找 CA 重新制作证书,后来发现不用,证书跟 pass phrase 无关。Nginx 的文档没有提及,Apache 倒是有提:

    If necessary, you can also create a decrypted PEM version (not recommended) of this RSA private key with:

    openssl rsa -in server.key -out server.key.unsecure

    拿到 pass phrase 后安全性自然降低了,不过完全值得。