Category: 小小草

I was wondering how Magento merge or handle into handle in layout.

I was expecting something like

<default>
    <update handle="customer_logged_in" if="logged_in"/>
    <update handle="customer_logged_out" if="logged_out"/>
</default>

Obviously, there is not such codes in layouts.

I searched within Magento folder for keyword “customer_logged_in”, but only occurrences I could find in layout/customer.xml.

So, how is customer_logged_in/out handle added to Magento layout?

At last, I found

class Mage_Customer_Model_Observer
{
    public function beforeLoadLayout($observer)
    {
        $loggedIn = Mage::getSingleton('customer/session')->isLoggedIn();

        $observer->getEvent()->getLayout()->getUpdate()
           ->addHandle('customer_logged_'.($loggedIn?'in':'out'));
    }
}

by tracing addHandle() in app/core/Mage/Core/Model/Layout/Update.php.

I must say using observer adding layout handle makes very easy for other modules to detect customer login status.

Magento 说不要使用 localhost 安装，我也就不用，也没深究原因。

我为了在本地调试一个网站，先拿了生产网站 euro-bags.eu 的一个子域名。后来该子域名被挪作他用，那时我想，如果换个子域名再被挪作他用，我干脆用一个用于域名保护而未建站的域名，于是开始用 euro-bags.com 来调试。

没过很久，Euro Bags 要在生产网站上实施一条网站提速实践：静态文件使用单独的 cookieless domain。因为 euro-bags.eu 使用了顶级域名，顶级域名上使用了 cookie，那么子域名上无法实现 cookieless。Euro Bags 也不想依赖第三方服务 cookieless domain，于是启用 euro-bags.com 专门为生产网站提供静态文件。

我的调试域名再次被挪作他用。为了防止此类不可预测的事情发生，我想到干脆用一个不可能用于生产网站的域名来完成调试，于是想到用 euro-bags。

一开始没发现问题，用了几天后想登录 euro-bags admin area 发现登录不了，输入密码后总是弹回到登录页。

百思后才得其解，原来在 Magento 里使用任何 dotless hostname 都犯了跟使用 localhost 同样的禁忌。Magento 基于安全考虑在 cookie 里打上 domain 烙印，而大部分浏览器用拒绝接受含 dotless hostname 的domain 烙印。虽然可以 comment out app/code/core/Mage/Core/Model/Session/Abstract/Varien.php 某些行让 Magento 在 cookie 里不打 domain 烙印，从而让浏览器接受它的 cookie，但我觉得这么做是南辕北辙：不含 domain 烙印的 cookie 固然通行，但 open to cookie hijacking。Magento 最值我称道的就是每个细节（我没见其它 ecommerce software 有如 Magento 的周到）。

既然 Magento 要在 cookie 里打 domain 烙印，而大部分浏览器又不接受 cookie 里有 dotless hostname，那我就不要用 dotless hostname 来安装 Magento 不就得了。于是我最新启用euro-bags.net 来继续本地调试，因为未有迹象表明 Euro Bags 要把 euro-bags.net 纳入域名保护，也没有要用这个域名来提供服务的计划，所以我不用再频频更换调试域名了。

I am planning a project called Fpcp (Full Page Caching Preparer) to improve Magento performance. Yeah, it is called Fpcp and very similar to another module Cpfp (Cms Page Foot Print).

I have a bit research on Magento Enterprise only features, and pick full page caching as my next interested project. I do not know how Magento Enterprise implements full page caching, but my idea is rewriting all blocks containing session related content with an ajax get method.

Most Magento model, resource, collection are placed this way:

• Model is located at Model folder
• Resource is located at Model/Mysql4
• Collection is located at Model/Mysql4/(ClassName)

What if you want organise them in a different way? Say how place all of 3 classes under one folder?

I enclose a complete a working sample.

1. Model class

class Qian_Msdk_Model_MediaGallery_Mg extends Mage_Core_Model_Abstract
{
public function _construct()
{
parent::_construct();
$this->_init('msdk_mg/resource');
}
}

2. Resource class

class Qian_Msdk_Model_MediaGallery_Resource extends Mage_Core_Model_Mysql4_Abstract
{
public function _construct()
{
$this->_init('msdk_mg/product_attribute_media_gallery', 'value_id');
}
}

3. Collection class

class Qian_Msdk_Model_MediaGallery_Collection extends Mage_Core_Model_Mysql4_Collection_Abstract
{
public function _construct()
{
parent::_construct();
$this->_init('msdk_mg/mg');
}
}

4. config.xml

<?xml version="1.0" encoding="UTF-8"?>
<config>
<global>
<models>
<msdk_mg>
<class>Qian_Msdk_Model_MediaGallery</class>
<resourceModel>msdk_mg_mysql4</resourceModel>
</msdk_mg>
<msdk_mg_mysql4>
<class>Qian_Msdk_Model_MediaGallery</class>
<entities>
<product_attribute_media_gallery>
<table>catalog_product_entity_media_gallery</table>
</product_attribute_media_gallery>
<product_attribute_media_gallery_value>
<table>catalog_product_entity_media_gallery_value</table>
</product_attribute_media_gallery_value>
</entities>
</msdk_mg_mysql4>
</models>
</global>
</config>

Magento product custom options 的存储结构比较“绕”，我绕了好长时间才解开。

假设 $product 有两个 custom options，一个是 textarea input type，另一个是 multiple select input type：

先用 $product->getOptions()，得到是包含两个 custom options 的集合；
然后 foreach 一下，得到每个 $option。对第一个 textarea 类型的，处理起来相对简单，用 $option->getData(‘title’) 查看 title，以此类推。对第二个 multiple select 类型的，用 $option->getData() 只能查看概况，对于 select 里的每个 option （对应 <select><option>…</option></select>），还得用 $option->getValues()，然后再次 foreach 才能得到 select option。

够复杂吧。