跟隨潮流與為了網站訂閱功能的可攜性，所以也申請了 "Google FeedBurner"，讓自己的網站有一個唯一 (unique)的訂閱網址。
透過 FeedBurner 訂閱的方式有兩種： 以 Email 訂閱，或直接以 RSS 閱讀器訂閱。
另外我仍提供了 wordpress 預設的 RSS 訂閱方式。兩者的差別好像 (我也不清楚)是後者在遇到 {閱讀全文} 的標籤前，都可以列出本文的內容，而不像 feedburner 需事先設定本文的長度。
我的 RSS 訂閱網址為：
o FeedBurner: http://feeds.feedburner.com/kenming 。
o WordPress: http://www.kenming.idv.tw/feed 。
實現的效果參考下圖：
與其說 Drupal 功能強大有彈性，倒不如說因為有太多玩家為其開發各類功能的模組 (modules)，而使得網站的客製化 (customization) 與個性化大幅提昇。 例如 View, CCK 等重量級的模組，很難想像若不安裝這兩個基礎模組，Drupal 網站該如何運作設定啊。
為了讓網站功能更形強大多樣化，網站管理者往往需要安裝到數十個之多的模組。 說實話， Drupal 的模組設計，個人覺得甚為不欣賞。 雖然它有很大的優點是容易開發，且容易與核心 (kernel) 整合；但模組與模組之間的相依性 (dependency)太重了，會因模組的更換而連動影響到相關連的模組，而導致這些模組所提供的功能並不穩定。更甚者，大版本的更新，如從 4.X, 5.X, 6.X, 7.X 等的升級，所有模組均無法順應升級到下一大版，只能重新安裝支援該版本的模組，這實在相當不合理。
上述是題外話，算是對 Drupal 開發一個小小地抱怨 (當然，更期許的是，Drupal 的結構設計能更形有彈性，那可就相當完美了)。
現在較頭痛的一個問題是，安裝了太多模組後，效能與穩定性往往會被影響到。 以我來說，目前安裝了近 20 個模組，雖然功能尚稱穩定，不過常常會遇到在管理頁安裝某些模組後，就停滯在該網頁運轉許久，然後就出現 空白頁 (Blank Page)，使得我經常需要去資料庫刪除掉該安裝的模組，移除掉該模組檔案，再重新開啟模組管理頁，再重新試著安裝……，實在令人困擾。
這一類的問題，當然就是要透過 Google 找 How-to Solution 了，或者應該是要至 Drupal 的官方網站論壇找尋答案了。 這裡： The White Screen of Death (Completely Blank Page)。 整理了許多引起 Blank page 的可能原因與建議的解決方案。
昨晚靜悄悄地把 WordPress 系統給升級了 (from 2.71 to 2.8) ……
其實，只要在後台單鍵點個選項，Wordpress 就全傻瓜式的自動幫你完成升級。 期間所有的模組 (plugins) 也完全正常運作，沒有相容性的問題；而且許多模組也似乎順應 2.8 的升級，很快地同時釋放出更新版本，所以也是單鍵傻瓜升級即可。 當初選擇轉移到 WordPress 平台是對的，平台的管理與升級，實在輕鬆簡單太多了。 🙂
另外，ISP 這邊，Why3s 前兩個月主動徵詢我的意見，看要不要轉移主機，因新主機效能更佳，MySQL 版本也是較新的 5.0。 這當然好啊，唯一稍稍擔心的是原來是使用 MySQL 4，不知道是否會有資料庫相容性的問題。 不過從 MySQL 4，透過 phpmyadmin Dump Blog 資料，再倒入 MySQL 5，一切完全正常！ 不過我的資料檔 (純文字檔) 有 70餘 MB 之大，而 Why3s 這邊的 phpmyadmin 上載 dump 檔最大限制為 50 MB，所以從下載到上傳，改用 phpmyadmin 預設 .gzip 壓縮，整個過程也是相當順利。 (不過注意的是，改用 .zip 卻是不行倒入。)
目前新系統的主要應用伺服器版本為：
從某一個應用系統 (或資料庫系統)要把資料轉移到另一個應用系統 (或資料庫系統)，這個轉移的過程稱之為 “Migration” (相對地，若是同一系統的版本更新，則稱之為 Upgrade)。
上一個月，要從原來 b2evolution Blog 系統轉移 (migrate)到 wordpress 系統時，就如同當初我從 MT 轉移到 b2evolution 一樣，官方的系統均有提供 import (載入) 的 script 檔。 只是， MT 轉 b2evolution 時，當時因為資料結構比較單純，所以完全不用作任何修正，透過 import 工具程式一下子就轉好了；但是，這兩三年來， b2evolution 系統相當積極，版本更新極快，而每一次大版本的更新，必然會變動到 DB Schema，這使得 wordpress 所提供可以 import from b2evolution 的 script 檔，不可能不作修改就可以順利完成轉移作業。
wordpress 官方所提供對各大 Blog 系統的 import script 檔在此：Importing Content。 不過，我真的挺懶，想說若能找到無痛地可以從我現在 b2 1.10.3 版本 → wordpress 2.71 的網友加持修改版，那就更省事了。 結果呢，花了大半天的時間，是有找到啦，像這篇： Import From B2evolution(2.4.6) to WordPress (2.7)。 只是，要收費耶！！ 含售後客服要價 50 USD。 其實啊，這價錢是算便宜的啦，當初我擔任某家公司的 Oracle DBA 時，幫企業客戶作轉檔的話，起碼是 10 數倍以上收費起跳的呢。
不過，想想還是乾脆又自己來動手 DIY 好了。 其實轉檔的原理相當簡單，就是把 Source Schema 對應 (mapping) 到 Target Schema 就對了。 b2evolution 有 31 個表格；wordpress 則只有 10 個 (非常欣賞它的結構簡潔)！ 怎麼會差這麼多？ 主因就是前者是被設計來服務多個部落格用戶的，而後者僅設定單一的部落格，所以前者儲存了非常多的統計數據，而這些，其實是不用轉移的。
轉移的核心會是什麼？ 當然就是本文內容了。 本文就是包含 Post 內文 (content)與迴響 (comment)，一篇內文會包含 0 到 多篇迴響，非常典型的 “Master-Detail” 表格結構，一般就是會有兩個表格個別儲存並以 Key (primary-key to foreign key)來關聯了。 所以只要找出含有 “_post” 字串的表格，大部份就是儲存 Post 內文的主表了。 再以此為中心，把一些如類別 (category)、帳號等額外資訊，給一一的加進來即可。
轉檔的寫法百百種，可以利用 stored-procedure、利用 C#/VB.NET、PHP、Perl 等機制來轉寫轉檔程序。 事實上，對資料結構與 SQL 語法精通的真正高手來說，只要寫個 SQL 陳述 (statement)甚至就可以轉移了。 嗯，我那個 partner Ringle 就是精通此道，他對資料庫的掌握度，我仍是沒有看到一個比他更強悍的。 可惜，他可不幫我作這種小事，而他收費可更是不便宜。 所以呢，我還是又繞回來，下載回來 wordpress 官方的 import script 程式，當然是利用 php 撰寫的，再以此作為轉移程式的 “骨架 (skeleton)”，然後慢慢地調整 SQL 陳述，修改表格與欄位、資料型態等。 呵呵，比想像得簡單，我採用漸進調整的方式作業，大概反覆轉移了有四、五次之多，至最終轉到我滿意正確的結果，大約也才耗上半天的時間而已。
從 b2evolution 轉移到 wordpress 的過程，吃足最大苦頭的不是轉檔 (migrate)，而是版面的 CSS 設計。
這一次我對版面的需求一開始就打算使用三欄式的 Layout 了，原因是我打算提供更多樣化的一些額外附屬資訊，同時現在是流行大螢幕尺寸，1024*768 以上的瀏覽畫面，已經佔絕大部分使用者的比例了。 我的版面構思是右邊兩側為 Sidebar 列，一個稍寬、另一個稍窄 (均可調整寬度)，左側就是內容 (content) 主頁了。 然後 Sidebars 是設成固定寬度 (fixed-width)，而內容區則可以視瀏覽器寬度的大小而變動 (Liquid-layout)。
當然一開始是透過諸多提供 wordpress 佈景主題 (theme)網站來找尋，結果花了一整天的時間，瀏覽了數百個佈景主題，就是找不到我心中所想的，絕大部分的 CSS Layout 均是採用固定式寬度的設計；再則，我似乎有一些 "潔癖"，看到 style.css 編輯得很凌亂，就挺不舒服的。 後來決定了，自己重寫 css layout！ 我甚至不是 copy 自 default 的 css 當成樣板，而是僅把它當成參考，然後逐漸地邊嘗試、邊摸索，一點一滴試到可以接受為止。
事實上，我發現到，如果 sidebar 與 content 都是可變動的比例式或為固定寬度，那麼 layout 就挺好設計的。 但是像我這樣的需求，反而比想像得還要困難。 更重要的是，我其實不太會 CSS，我是在這一次為了達成我理想中的版面，才去瞭解一些基礎觀念。 版面 CSS 的設計，最基本的就是對所謂的 "Box Model" 要能有清楚的理解才行。起碼你總要知道 margin 與 padding 的差異、float 與 position 的浮動調整，以及還要注意的是 IE 與 Firefox 兩者瀏覽器(及其版本) 的支援程度才行。 這裡我強烈推薦 網站製作學習誌 這個網站， 版主在其一篇：CSS 排版觀念—Box Model ，寫得非常清楚，是一篇相當棒的教學文。
仍然又是透過我的好朋友 Google，查詢到了能達成我理想中版面的 CSS 解法，起碼有三種方式可以達成。 我這裡也不想去比較各種方式的優劣與否，大致上就是作個整理，有興趣的網友們可以去行參考。
反覆嘗試，我是採用了最後這一個，"The 'Blog Style' 3 column Liquid Layout (Pixel-widths)" 。 這個版面的 CSS Layout 設計可以說是相當古怪 ( 簡單的說，它利用一個 200% 的 parent 區塊再折成只有右側 100% 來包含 content 區塊。)、也最複雜，但相對也是最具彈性，無論你用 IE or Firefox or 其它各類瀏覽器，無論你怎麼伸縮，版面真的是不會跑掉 (如側邊欄掉下問題)。
不過，我有做了一些調整。 如果三欄式的兩個 Sidebar 是放在同一側，那麼，我就把它視為是一個 "大" 的 Sidebar (parent)，其內在包兩個左右 "小" 的 Sidebar (child)。 如此我是覺得無論這個大的 sidebar 內部怎麼變化，都是它自己的事，所以也可以任意調整內部甚而再加上 "上與下" 的 sidebar 列了。
怎麼實現最好呢？ 就是把 html 與 css 都寫在同一個 html 檔內，然後打開 IE 與 Firefox，同時去測試比較寫出來後的效果。 對了，我強烈建議，一定要安裝 Firefox 的 Plugin: Firebug， 真是太好用了！ 如此要能追蹤除錯，相當地方便。
我這裡也列出我原先所寫得這一個 css layout template 檔案：
閱讀全文 »
我想要能在讀者閱讀某一篇文章時，在文章區的底部能提供其他相關文章的額外資訊，諸如 延伸閱讀、歷史上的今天等。
延伸閱讀 我採用了 Yet Another Related Posts Plugin (YARPP)，功能應該是同類型的外掛中最強的。 它可以依據 標題、本文、標籤(Tag)、類別(Category) 等來找出在部落格內的其它相關連的文章。 大陸網友有寫了篇該插件(plugin)的使用說明，相當詳細。 可惜，透過 “標題” 來找出相關連的文章，對於中文字詞並沒有什麼效果。 反之，透過 “標籤(Tag)” 效果是最好也是最簡單的方式了，但是，前提就是每一篇的文章在下標籤關鍵字時要多更用心些才可。
歷史上的今天，我則是採用了 This Day Plugin，非常簡單，只有一支 PHP 程式而已，就是可以顯示同一部落格內同一日但不同年份的其它文章。
插件啟動後，就會直接把其它年份的 “This Day” 列表在本文內容的底部。 這我可不喜歡，我比較傾向上述這些算是 “額外的資訊”，我是會把這些給獨立放在另一個區塊的，再以 CSS 來調整 layout。 但是，稍稍可惜的是，原作者就是直接內建這個插件功能，並沒有提供可以直接呼叫的函數(function)，這就不同於那個 YARPP 插件，可直接將其函數任意放在你想要的 template 位置上。
所以，追蹤了該支 PHP 程式，在最下面有一行把它給註解(comment)掉：
//add_filter('the_content', 'ddtd_generate'); |
這一行的功能就是屬於對本文內容的 “rendering”，對其本文後面再加上 This Day 的相關資訊而已。
再來，找到 ddtd_show_posts() 函數，在最底下的一行：
return $the_output; |
改為：
echo $the_output; |
然後，在你所使用的 theme template 目錄下 (wp-content/themes/XXX)，利用文字編輯器(如 notepad++) 打開 single.php 檔案，在你想要顯示的位置上插入：
<?php ddtd_show_posts(); ?> |
像我，就是把上述兩個額外的相關文章資訊，放在底部(foot)的下一個區塊，並利用 table 給排列成左右兩欄各別的參考資訊。
<div id="extra-info"> <!-- 延伸參考資訊 -->
<table width= "98%">
<tr valign="top" align="left">
<td width= "50%"><?php related_posts(); ?></td>
<td width= "50%"><?php ddtd_show_posts(); ?></td>
</tr>
</table>
</div> |
至於為何使用 Table 而不使用 CSS float 來設定呢？ 只能說，這比想像得還要難，只要放大縮小瀏覽器視窗，經常就會跑掉排列位置，不勝其擾。而使用 Table 排一版只花兩分鍾即可，所以在這種小地方，也就不想太講究、多花這些無謂的研究功夫了。
