I’ve tried to compare different url-rewrite

1. 在 lighthttpd 的 config file 當中 wordpress 的部份 (vhost 或 subolder) 加上

server.error-handler-404 = "<your_wordpress_root>/index.php"


2. 修正一下你的 theme 的 404.php

在第一行加上

< ?php header('HTTP/1.1 404 Not Found');?>

如果你是用 CGI / FASTCGI 設定的話就是

< ?php header('Status: 404 Not Found',false,404);?>

總共才不過兩佪 file 兩行而已，而且執行起來的效率很高。

不但語意上簡單而正確，也能使用顯示自訂的 wordpress 404 頁面。

如果配合 rewrite 的話也可以更一步減少 server 執行 stat() 檢查檔案是否存在而作出的 IO operation

其實如果單純只是 TagCloud 的話其實很易就能有網上找得到，可是它們都是只是任意把 Tag 放在一起，再依比重來設定字體大小。
但是我想造出來的是一個有互相連結，類似 Byecycle 的相關性 TagCloud。就算 Tag 之間沒有直接關係，但卻可以從共同文章中直接/間接得到一個相關系數。再依文章與文章、文章與 Tag、Tag 與 Tag，安排其在畫面上的大小和位置。最後只把 Tag 顯示出來，就能造出一張依從 Tag 相關性而產生的 TagCloud 吧！？

概念是有了，也做出的基本 phonotype 但實作起來問題一大堆。首先是慢，其次係畫面密度控制和相關性的運算。

遲D 再找找 tags 有無方法整理得好少少

好在發現得唔算太遲，改番轉頭就無事了。不過有幾個鐘時間，用唔到舊 Hyperlink 進入。

原來 Wordpress 個 Permanent Link做法同 TYPO3 的 RealURL 做法好唔同。

ReaURL 會用 database 記住每一個 rewrite 過的 URL 來實現高速 encode cache 和 reverse mapping，直至有人走去按 purge 為止。
而 Wordpress ，就完全唔會記低自己做過咩野，只係每個 request 都會再讀取 config 來重新 encode/decode URL。

而 RealURL 規則比較煩，不過具有擴展性，Typo3 extends 可以自己加 rewrite rules，相對 encode/decode 工作就會好重，所以用 database 係必然的。encode/decode 一條連結可能要載入數十個 php library 和幾十次的 SQL query，反應時間會很慢的。

而 wordpress 則比較簡單，組合很少，不必事先載入沒有用的 class，解碼很快，也不會產生大量 SQL Query。可是也就有可能出現，規則或設定上的小改動而令到大量結連失誤。

不過我唔太滿意右手邊自己寫個 search button 整來整去都做唔到 Fx 同 IE 同時有我滿意的效果。

順手改左少少 sidebar，加入少許 awstats 的數據，睇落都算整齊。