目前我在 Drupal 上愛用的編輯器是 TinyMCE，最近碰到了一些由使用者貼上的文章會造成版面被破壞的問題。
我是使用 Wysiwyg 配合 TinyMCE 來載入，所以可以只改 Wysiwyg 模組裡面的檔案，來達到控制 TinyMCE 貼上的動作。
我用的 Wysiwyg 版本是 6.x-2.2，TinyMCE 的版本是 3.3.9.3
要改的檔案是：wysiwyg/editors/js/tinymce-3.js
在 init: function(ed, url) {...} 這個函數裡面新增以下程式碼：
// Force Paste-as-Plain-Text
ed.onPaste.add( function(ed, e, o) {
ed.execCommand('mcePasteText', false);
});
存檔，然後清空 Drupal 的 Cache 即可。
這幾天在找 solr 跟 sphinx 的相關資訊，在網路上找了許多資訊後，有個亮點突然吸引我：那就是 MariaDB 居然有把 Sphinx 的儲存引擎整合進去～
把 MariaDB 裝上後看看，卻沒發現有 Sphinx 的儲存引擎，上官網找了資料後才知道要先把 Plugin 安裝進去～
由於檔案都有了，所以只要下 SQL 命令即可，同樣也是要先作一次安裝 Plugin 的儲存引擎還有 OQGraph。
SQL 語法如下：
在一般硬碟上，如果你直接格式化它，是不會出現 exFAT 的選項可以選，你必須用 Disk Management 先把硬碟的分割區給刪除掉，然後用 New Simple Volume 把分割區切出來時，格式化的選項才有 exFAT 可選。
另外一個方式是用 CMD 去下 Format 命令。
不過問題在於，這時候的磁簇大小的範圍是 512 ~ 64K，沒有 32M 的選項可選 (我用來測試的硬碟是 500G)，只有用 Format 命令的方式可以強迫指定磁簇大小為 32M。
後來我拿手邊兩個容量分別為 4G 和 16G 的隨身碟來試，兩者的磁簇大小都有 32M 的選項可選，不過最小的磁簇大小的選項有點差異，4G 的那個最低可以選到 512，16G 的那個則只到 1024。
底下是我剛剛把一些檔案複製到測試的 500G 的硬碟上的資料。
| Size | Size on Disk | Files | |
| 來源：NTFS/64K | 269G | 269G | 3582 |
| 目的：exFAT/32M | 269G | 349G |
值得注意的是，當複製小檔時，會有停頓的現象。
雖然我認為 exFAT 這樣的設計很雞肋，不過我想知道為什麼會有這樣的差異。有誰能提供進一步的資料嗎？
先講結論：
如果你的儲存媒體是電子式的 (例如：RAMDISK、SSD、Flash 隨身碟等)，請用 exFAT。
如果你的儲存媒體是機械式磁性紀錄的 (例如：傳統硬碟)，請用 NTFS。
不過有兩個例外：SSD 當系統碟使用、Flash 隨身碟當安裝碟使用時，則必須使用 NTFS。
如果你懶的管這兩個檔案系統的差異，那就都格式化成 NTFS，磁簇大小 64K 來使用就行了。
這幾天我在研究這兩種檔案系統的特點，試圖找出增加其搜尋、存取效能的關鍵以及適用的方式，底下是純理論的分析。
對於搜尋方面，在不靠 Windows Search Index 的前提下，由於NTFS 的目錄內容使用 B+ 樹的關係，所以在相同的儲存媒體中，效能會比 exFAT 來的好。
不過由於電子式比機械式在搜尋速度跟存取速度都有強大的壓倒性優勢，因此對於這兩個檔案系統在電子式的儲存媒體中的搜尋效能來說，並沒有很明顯的差異。
對於存取方面，磁簇大小則是關鍵，底下是這兩種檔案系統的磁簇大小的比較表，單位是 Byte。
| 檔案系統 | 最小 | 最大 | 預設 |
| NTFS | 512 | 64K | 4K |
| exFAT | 512 | 32M | 32K |
一般來說，磁簇越大，存取效能也越好，但相對的對於小檔空間損耗也比較大。
另外，檔案的 Fragmentation 對存取效能也是一個問題，由於 exFAT 一樣使用 linked list 來分配檔案空間，所以這個問題也許會變得很糟。
不過如同上面提及電子式的儲存媒體的特性，這個問題在電子式的儲存媒體中基本上可以無視。
雖然 exFAT 有許多新的特性，例如：TFAT、free space bitmap、ACL 等等，不過我在 Windows 7 裡面沒有確認到這些特性有被實做出來。
另外 exFAT 一樣是兩個 FAT 是連續存放的，如果該區域損毀則整個分割區的資料都無法重建，因此我很難就可靠度、搜尋的議題上，在硬碟中使用 exFAT。
以目前來說，硬碟的每 GB 價格仍然遠低於電子式的儲存媒體，因此在適合 exFAT 的環境中，很難出現真正使用大量的大型檔案的應用。
如果要給 MS 建議的話，我會說請把未來新版的 NTFS 的最大磁簇大小放大成跟 exFAT 甚至超過，這樣比較有意義。
根據水球的鼓吹，我買了 SSD 回來當系統碟。
過去很少注意 Windows 7 系統的調教，不過因為據說 SSD 寫入次數比硬碟少非常多，所以上網找了一些文章來實驗。
我用來修改系統設定的是 Ultimate Windows Tweaker，簡稱 UWT。
底下是一些心得：
我一直以來使用的防毒軟體都是免費的小紅傘。
我愛用它的原因主要是兩個：
尤其是第二個，我通常設定檔案讀取時才進行即時掃描監控。
這樣的設定對於在跑 BT 軟體或是 Web Server 蠻有幫助的，跟選擇兩者時比較起來系統的反應會比較快一些～
不過最近發現一些小問題：
後來發現只要先把小紅傘的的即時掃描先關掉，在進行上述的動作就都沒問題。
WebATM 的解決方式還有另一個解法：把小紅傘對各種威脅的項目全部不要選取即可。
i18n 模組對 Drupal 的各類翻譯方式幾乎都能進行翻譯的支援，雖然有些方式比較麻煩，不過還算堪用～
Translation table 模組可以幫忙一半種類的翻譯（分類、內容類型、選單），其他的部份則是需要用搜尋的方式進行翻譯，而且一次只能翻譯一句，比較不方便。
其中最麻煩的是 CCK 的翻譯，翻完之後不會立即生效，必須要跑一下 update 才會生效（對，你沒看錯，就是那個升級系統跟模組用的 update）。
簡單來說，CCK 的翻譯流程如下：
以速度上來說，Google 是比較快的。
以功能上來說，SourceForge 是比較齊全的。
我是籌備委員之一，這是 Drupal Taiwan 成立以來第一個 DrupalCamp，活動議程目前正在排定。
今年已知應該會發行的 Drupal 中文書籍有 3 本，而新的 Drupal 7 更對優使性大大增強，個人估計這兩年會是 Drupal 在台灣發展的成長期起點。
想了解 Drupal 的一切嗎？快來報名吧～
報名網站：http://registrano.com/events/drupalcamp
活動網站：http://camp.drupaltaiwan.org/
這幾天在研究 GIT 跟 Mercurial 這兩套版本控制系統。
網路上找了一堆文章來看，大致上只了解 GIT 上手比較難一些，其他的要用過之後才知道。
很巧的是 Google 跟 Microsoft 的 Code Community 都支援 Mercurial。
不過據說 Drupal 正在評估的是 GIT~
上禮拜本來要被親戚抓壯丁（貌似我也不是壯丁，應該說抓參謀比較恰當），臨行出發前在整理房間，結果彎腰撿東西後，就不得不到醫院看病了～
這幾年這樣的腰痛發生次數有變多，這次是因為要跟其他人團隊合作，所以想說去醫院看看會不會比較快好～
不過還是拖了快一個禮拜才復原，接下來要追進度囉～
我承認我並沒有很勤勞的在寫部落格～
不過最近我發現，常常有人回文的地方是 facebook 那邊，而不是痞客邦這裡。
有人知道 facebook 上能裝 GA 或是 Yahoo! 奇摩站長工具嗎？
我是很想知道那邊的流量狀況～
Views 2.x 要改變排序方式的方式跟 1.x 差不多，最大的差異是設定上要繫結 views_handler 的物件，處理上比較麻煩。
底下假設目前排序方式是依據 "Post date" desc，而我們想要在傳遞任意的一個參數，改變其排序順序為根據 "type" asc, "Post date" desc，即插入一個 "type" asc 條件在原先的 "Post date" desc 之前。
$sort = views_get_handler('node', 'type', 'sort');
$options = array(
'order' => 'ASC',
'id' => 'type',
'table'=> 'node',
'field'=>'type',
'relationship'=>'none',
);
array_unshift($view->sort, $sort);
$sort->init($view, $options);
return true;
views_get_hander 的三個參數為：
$options 的內容，可以建立一個你想要的排序條件，然後 dpm($view->sort) 來觀察～
今天接到一位好友的噩耗，覺得相當突然，不過我也不知道該如何反應才好。
明明前幾天還在 GTalk 上談事情，這兩天沒看到上線，結果等來的卻是他不幸的消息～
希望他能一路好走，我們一起合作未完成的事情我會扛起責任將它完成。
有時候不寫下來真的會忘記～
當 Content Taxonomy 配合 Hierarchical Select 時，原本會自動帶入討論分類作為預設值的行為卻不見了。
我試過在 form_alter 跟 #pre_render 等地方去設定 Hierarchical Select 的 #default_value 卻無效～
後來在該Content Taxonomy 的 CCK 欄位的預設值填入：
return array(
0 => array('value' => arg(3)),
);
這樣便可以自動帶入討論區分類的預設值了～
P.S. 因為新增討論區文章的連結是像這樣：q=node/add/forum/123，123 是討論區分類號碼
這幾天花了點時間把 ZendServer CE 版的一些元件抽出來放到我自己包的 Portable APM 上，並且作了一些壓力測試的交叉比較。
先說結論：
測試環境：
壓力測試命令：ab -r -c 100 -n 10000 http://127.0.0.1/index.php
比較表格：
| zend_enabler_module | N/A | XCache | Optimizer+ | ||||
| #/sec | 129.03 | 297.60 | 362.98 | ||||
| % | 1.00 | 2.31 | 2.81 |
| php5_module | N/A | XCache | |||
| #/sec | 185.91 | 393.75 | |||
| % | 1.00 | 2.12 |