很久以前就想要好好地重整一下我的 blog 了，剛好趁著搬家重灌系統的機會，好好地整理一番。那時的目標有
真正的版本控制
資料庫瘦身
升級後台編輯用的 FCKeditor
與 Sidebar Widget 相容
IE 下的畫面極為慘烈
其中，「升級後台編輯用的 FCKeditor」已經在《Wordpress 編輯器升級到 FCKeditor 2.5.x》時搞定，theme 的問題暫時先不解決，所以剩下「真正的版本控制」與「資料庫瘦身」兩個目標。
真正的版本控制
以前的作法是，用 Subversion 管理我的 Wordpress 目錄，不過只是簡單的直接 checkout 出 Wordpress 程式。雖然升級或更換版本很方便，svn update 或 svn switch 一下即可，不過自己在 local 端，因應自己的喜好而做的更改，就沒辦法有好的版本控制機制，加以管理了。
也就是說，我希望在能夠隨時將 Wordpress 主網站的更新同步回來之外，還能夠保有自己因喜好而產生的一些小改變。如果 Wordpress 主程式和我自己的改變，是存放在同一個 subversion repository 裡，那這一切就可以做到。
簡單講就是，如上圖，我希望能夠隨時 incrementally 從 Wordpress 主 subversion repository 將最新的修正，mirror 到自己電腦上的 subversion repository 裡，成為一條 mirror branch。然後，又能夠有自己的一條 local branch，儲存自己的喜好，同時又能夠隨時視需要，將 mirror branch 裡的東西，merge 進我的 local [...]
我的 Recent Backlinks 自從升級到 wordpress 2.3 之後，就一直有問題，會多顯示出 kramer_pre%--> 的字樣。用這個奇怪的字樣去找，發現是 Kramer 這個 plug-in 的問題。當初會裝主要是因為 trackback 壞掉了，所以乾脆裝了 Kramer，會直接到網上找 back links，找到後代替 trackback auto-discovery 機制，插入資料到 wp_comments 表格。既然 Kramer 壞掉了，只好先拔掉再說。
沒想到拔掉 Kramer 之後，問題依舊，即使關掉 get-recent-comments 的 cache 也一樣。於是就直接進 database 裡找，發現不曉得為甚麼，Kramer 把製造出來的 wp_comments.comment_content 內容，前後加上了 <!--%kramer-pre%--> 與 <!--%kramer_post%-->。所以，只好辛苦地，寫個 script 修正 database：
#!/usr/bin/perl -w
use strict;
use utf8;
use File::Basename;
use Getopt::Long;
use DBI;
my ($__exe_name__) = (basename($0));
my ($__revision__) = ('$Rev: 26 [...]
雖然自從 Wordpress 2.x 開始，就內建了 TinyMCE 這套 WYSIWYG 的編輯器，但因為之前使用 EditorMonkey 裡面的 FCKeditor 功能實在強大，又能依據我的需要進行 customization，因此我仍然還是使用 EditorMonkey。可是，EditorMonkey 內附的 FCKeditor 是 2.2 版，已經很舊了，在使用的過程中，也一再地發現某些 bug，甚至培養出了迴避這些 bug 的編輯行為。
是故，我一直在思考著，是不是什麼時候，來升級一下。就在編寫 dprintf() 系列文章的過程中，實在是受不了了舊版 FCKeditor 的一些 bug 的情況下，再加上 FCKeditor 就在 2007-10-10，剛剛釋出了 2.5 Beta 版，所以一不小心，就把 editormonkey 拔掉，搞出了個 FCKeditor 2.5.x 的 wordpress plug-in 來。
當然，我並沒有那麼厲害，能夠無中生有的憑空造出一個 plug-in 來，主要還是參考了 Dean's FCKEditor For Wordpress，這是官方的 wordpress plugin directory 裡用 fckeditor 當關鍵字，所可以找到的唯一一套真正的 fckeditor [...]
自從啟用 footnotes plug-in 以後，我在編輯時，就方便了許多。不過，原本的 footnotes 0.91 版，還是有一些小問題，讓我有些困擾。所以，剛剛我找了一下官方的 wordpress plug-in directory，發現 footnotes 已經更名為 wp-footnotes。測了一下，並照著原本的改法，將 <span class="footnote"> 的標示法修正進去，再加上修了一些小 bug 後，順利升級到了 wp-footnotes 1.4 版。
在原本的 footnotes 0.91 版裡，是使用 while 迴圈搭配 strpos() 尋找註腳，也許是因為這樣，有時候在後台編輯時，會發生程式陷入無窮迴圈的錯誤。新版的 wp-footnotes 改用 preg_match_all() 搜尋註腳，希望效果會好一些。
不過，也許是因為改用了 preg_match_all()，原本只要修改 $footnote_open 與 $footnote_close 兩個常數變數的技法[1]，反而失效了。因此我鑽了一下，發現這兩個常數，在丟給 preg_match_all() 之前，有先用 preg_quote() 先處理過。這本來是件好事，但壞就壞在，preg_quote() 預設會替很多 delimiters 前面加反斜線，包括 < 與 > 等。然而，在 preg_match_all() 這行的 regular expression 裡，FOOTNOTE_OPEN 與 FOOTNOTE_CLOSE 所在的部份，其實式不需要替 [...]
本文拖太久了，斷斷續續寫，寫到後來都忘記本來想寫什麼了。不過我發現，好像 thegiive 自己分多次，把很多我要寫的都寫完了。:-p
剛剛看到這篇《Twitter , Rails , Scalibility...More》，我哈哈大笑三聲。所謂的 scalability，就是「有沒有能力在短時間內應付突然爆增的流量成長」嘛！結果 thegiive 最後的結論竟然是：
那麼一時之間無法解決也是非常正常的事情。所以，他們應該也不是太懶惰，只是成功的太突然，沒辦法吃下來。…至於 Ruby 是不是真的太慢，Rails 是不是真的不夠 Scalibilty 呢？這個問題我也不知道…
既然這樣子，那我也沒辦法了，寫再多，又有何用，情人眼中出西施咩。所以剩下的我也就懶得寫了，各位看官自行斟酌吧。
這篇是為了回應 thegiive 的這篇《簡單的回應 JeffHung 的文章》，thegiive 對於我在《COSCUP2006》裡對 RoR 的一些意見，不表認同。不過在談技術之前，我想先澄清一點的是，這種很明顯地就是會沒有結論，甚至容易陷入 flame war 的問題，其實並不適合在那種場合提出 challenge，因為不會解決任何事情。用 challenge 這個字眼，其實也不太對，COSCUP 是個可以讓大家 up up 的場合，真的沒有必要白刀子進紅刀子出。事後的交流，也是可以產生火花，而且更為持久，一切由心，端看我們怎麼想，個人覺得實在是沒有必要那麼亢奮。
再好的 template engine，也解決不了套版的問題
我們先來看看套版的問題好了。也許是雙方對「套版」兩字的定義不同吧？我的意思是，在一般網站的開發過程中，程式設計師將動態網頁的功能寫好時，通常網頁的畫面是「素」的，非常陽春不經任何裝飾。接下來要做的就是，將轉交給版面設計師，也就是俗稱的美工，所設計好的華麗版面，套在這個「素」的版面上。對於程式設計師來說，這個「套版」的過程，通常是非常痛苦無聊的，但又不可能交給版面設計師處理，因為通常版面設計師，並無法處理到「碼」的層級。面對美麗的美工姊姊，小小工程師只好乖乖地與複雜的 HTML 混碼奮鬥。
更恐怖的是，通常來說，這個過程不會只做一遍，通常會形成一個循環，程式改好後套版，版面或程式稍微改寫之後，又要重新套版，循環不休。這當然是因為，在專案進行的過程當中，通常不可能很幸運地可以一條鞭式地順著瀑布溜下來。
對於套版問題，目前已經成熟的技術，是各式各樣的 template engine，如 PHP 的 Smarty。除了解決了 security-concern、separate-from-login 與 caching 等需求之外，簡單的語法，也讓套版的困難度，降低了少許。但無論如何，template 仍然是以「碼」的形式存在，要處理套版，仍然是只能讓程式設計師會版面設計，或者是讓版面設計師會寫點程式。
幸好，這個世界有在慢慢地改善，隨著 CSS/W3CStd. 的普及，以及 Ajax 的流行，套版的問題，將可以得到相當大的改進。如果網頁是功能性的，像 Gmail 那樣，比較好的解法會是使用如 ZK、GWT 這類的 Ajax [...]
從 clsung 那邊看到，WordPress 2.1 “Ella” 出了，想想也蠻久沒升級了，再加上是應該要處理一下 WordPress 2.0.7 解掉的 security hole，所以就來升級我的 blog 版本。
照往例一樣是採 svn update 的方法升級[1]：
先備份資料庫。
然後到主目錄下 svn update，升級到最新 trunk 版。這次我是從 r4497 升級到 r4784，差距蠻大的，
用 svn diff 檢查了一下 local modification 沒有爛掉。
用瀏覽器進管理介面，畫面顯示訊息說要 upgrade database，執行後就一切正常了。
這次的升級，應該是成功的，至少到目前為止，看起來沒什麼異狀發生。整個過程不到 5 min，簡單快速，爽。
見《Wordpress 升級到 1.5.1.3》與《升級到 wordpress 2.0.1》兩篇。 ↩
敝小站的 trackback 爛很久了，趁著今天放假有空[1]，追了一下程式，發現原來是啟用「Did You Pass Math?」時安裝的 Did you pass math 這個 plug-in 的問題。
簡單講，這個問題出在於，Did you pass math 乃是註冊 comment_post 這個 action，以進行驗證數學的答案的工作。但 trackback/pingback 時，也都會進行 comment_post，因此就被 Did you pass math 擋了下來，讓 trackback/pingback 失敗。
事實上，每一種 spam checking 的 plug-in，應該都會碰到這個問題。解法很簡單，就是偵測是否此次 comment_post 是否為 trackback/pingback，如果是，就直接通過，否則就進行數學答案的驗證。
但是要怎麼偵測此次 comment_post 是否為 trackback/pingback 呢？我不是 wordpress 達人，所以只好偷看一下 Captcha! 的程式碼，原來關鍵在於，也註冊 pingback_post 與 trackback_post 這兩個 actions，於處理此兩個 actions 時記錄於 $this->is_trackback，然後在處理 comment_post 時，若是 [...]
最近對 JeffHung.Blog 動了一些手術，裝了在《今日連結 (2006-09-20)》時看到的 Sandbox 的這套 theme，並予以改造，準備將外觀改回原來的樣子。Sandbox 是一個 semantic-rich 的 wordpress theme，其設計極端注重語意的保留，是一個很好的，設計自己的佈景主題的起點。
對於 blog 的佈景主題，之前換成 beeblebrox 布景時，我就已經有了基本的想法，最主要的就是要能夠讓我得以清晰的擺放程式碼在文章裡。這當然是因為，實在是文筆不好，只好多填些程式碼充數的關係。再又經過一段時間的觀察與沈澱之後，想法多了一些，以下簡單條列於下，算是再次整理：
在版面配置上，如果有邊欄 (side-bar, side-panel, ... what ever) 的話，必須要放在左邊。這是因為程式碼以及我會使用到的語言，方向都是由左至右的 (left-to-right)，而程式碼有時候又有「不可換行」的特性，當有這樣子的狀況發生時，版面就會被撐大，若邊欄放在右邊，在「由左至右」以及「不可換行」兩個因素的限制之下，邊欄就會對本文的閱讀造成影響。
在版面配置上，本文區塊應當要是 fluid，也就是會隨著瀏覽器的大小而變動。理由正是由於上述程式碼有「不可換行」的特性之故。當版面被撐大時，fluid 的版面配置，就不會讓版面受到破壞。
本文字體大小必須是瀏覽器預設的大小，這是預設閱讀起來最舒適的字體大小。Gslin 在這篇《字形的問題》有聊到相關的考量。以前小時候，總喜歡在一個頁面裡，塞下越多的資訊越好。但現在老了，眼力不行了，所以字還是大一點，看起來比較舒適。
非本文的內容，在樣式上，應該盡可能地不喧賓奪主。這可以用較小的字體，或較淺的前景色來達成。尤其是在邊欄放在左邊的情形下，邊欄的內容更是容易讓使用者分心，因此適度的淡化處理，是必須的。
邊欄存在的目的，應該只是提醒使用者，「還有這些東西可以看」，而不是直接把內容呈現給使用者，內含真正內容的邊欄，只會使使用者分心。因此，放在邊欄的 recent-comments 與 recent-trackbacks 等，應該要只放連結與標題就好，毋需列出部份內容。
內頁的 HTML <title> 必須包含文章標題，考量到 tab browsing 時，tab width 通常不寬，因此文章標題應該置於 blog 名稱之前，如：「Sandbox, look.urs, and blogging frequency [JeffHung.Blog]」。
Search form 應該擺在越上面越好。我通常會擺在 header 的右方。Searching 已經超越 surfing 成為現今主流的瀏覽方式，所以應該放在最立即所得，但又不影響主體的地方，就好像 firefox 的 search [...]
睡到一半口渴睡不著，所以就來裝裝 wordpress plugins，找到一個 PostTeaser 看起來還不錯，所以就裝起來試試看。PostTeaser 是一個 excerpt 的加強版，其簡介是說：
Post Teaser generates a preview or "teaser" of a post for the main, archive and category pages, with a link underneath to go to the full post page. It includes features to generate a word count, image count, and an estimated reading time.
可惜，裝起來後發現，他的 word count 對中文字感冒，連帶地也算不準 excerpt 的長度。如果是中文字比較多的文章，很容易就帶出一大票文字，喪失了使用 [...]
前幾天我在裝「Did You Pass Math?」的時候，其實也一併裝了「footnotes」，不過這個套件可以討論的東西比較多，所以遲至現在才發表。
我一直認為，寫文章用 HTML 實在是用錯了格式。如果可以的話，我希望 blog 裡的文章，是使用 DocBook 格式為其原始格式，然後再經過某種機制，好比說 XSLT，轉換成 HTML 在 blog 裡呈現。理想狀況是，blog 的後台，內建 Web-based WYSIWYG DocBook editor。但這是理想，在現實上，連 stand-alone 的版本都沒有了[1]，遑論 blog 後台的整合。因此，遷就於工具的問題，也只好將就[2]。
是故，退而求其次，我希望至少能夠在 (X)HTML 裡，呈現出我常用的文章樣式。對偏向技術性文章的我來說，最重要的就是 program listing 與 inline code 的呈現了。這個我已經藉由 FCKEditor 可自訂 CSS 的功能達到[3]，若需要更進一步的 syntax coloring 或 line numbering 的花俏功能，我認為直接在 client 端藉由 javascript 達成[4]即可。
而第二常用的文章樣式，則是 footnote，我個人喜歡使用論文 reference 的寫法，於指涉處與註解處，皆使用方刮號 ( [ 和 ] ) 包裹註解編號，並加上超連結在兩者之間跳躍。這篇《升級到 [...]
