有時在 Blog 的內容內，會有含程式碼的範例，若要讓其能正常顯示，一般是設定 html 的〈pre〉標籤。 不過呢，想當然其 format 樣式是不會好看的，若希望能如在 程式碼 IDE 編輯器上所顯示的那般，不同的關鍵字、不同的程式語言，就能顯示不同的顏色。甚至呢，還可以顯示出行號來。

有兩種方法，可以讓網頁的程式碼片段(code snippets)內容，顯示出行號與關鍵字顏色等比較看起來像是真的在看程式碼的內容般。 一種是在 Client 端能解析網頁內程式碼的內容。 最具知名度的應該是這個吧： Syntax highlighter。它是 Javascript 的程式，是伴隨著網頁內容一同下載到 Browser 端，再由其編譯器來解析。 這種方法好處是很方便，不用更改到 server 端的設定，就是只要在網頁的 header 區貼上該段程式碼即可。 而主要的缺點就是要多下載約快 200k 的 javascript 程式，耗費傳輸頻寬，也稍微增加了 Browser 端的解析負擔，還有呢，也會與所使用的 Browser 各種版本所使用的 javascript 編譯器有關，使得解析出來的結果，在各種瀏覽器所看到顯示結果的會不太一樣。

另外一種方式就是在 server 端，也就是在 Blog 平台上，安裝 “code lightlight” 解析器的 plugin。 然後當 blog 文章要輸出時，整個網頁內容會在 server 端這邊作一個完整的解析。這個過程應該是稱之為 “Text Rendering”。 好處就是網頁內容在傳輸輸出前，就已經處理過，並轉為完整 HTML (XHTML) 格式的網頁。 但是缺點就是，必須在 server 端上設定安裝，而這與各個平台版本是否有支援這類的 plugin 機制是有關係的。

我傾向後者的方式，主要的原因是我的 Blog 內容，在每一個頁面(page)，並不會常出現程式碼的片段內容； 再則，我總覺得從 server-side “空降” 一個 javascript 的解析器，有說不出的彆扭感，且每次傳輸要多上近 200K，實在覺得說不過去。

所以，決定後，我的方向就是轉向尋找 b2evolution 有無支援 “code hightlight” 的 plugin 模組。 原來官方版本就有提供一個預設的了，但是蠻陽春的，好像只支援 php 與 html 的程式碼顯示而已。 還好的一點是，在官方網站上有看到其中一位國外網友改寫了這個陽春的模組，將其解析的核心改為 GeSHI。 這太棒了！ 這個 GeSHI 解析器(php-based)，可以解析的程式語言可是高達上百種，而且還在持續的維護更版中。

這個網友改寫的模組在這裡： b2evolution code highlighter plugin modded to use GeSHi。 安裝超級容易，就是依照該網站的安裝提示，下載該網站所提供的 plugin 模組，以及最新版本的 GeSHI 程式，再一同解壓縮至 “blogroot/plugins/code_highlight_plugin/” 目錄即可，然後在 Blog 個管理平台啟動該模組就可以了。

閱讀全文 »

昨晚約 10:00 左右，想說我的部落格系統已有約 10 個月時間沒升級了，再來則是 b2evolution 釋出最新的穩定版本 2.4.2，已經與我現在使用的版本差了一個大版的號碼，功能等應該有增進不少。 依著以往的經驗，升級的時間約兩個小時內應該可以完成的。

參考原先我寫的升級備忘錄： [系統升級] b2evolution from 1.10.2 to 1.10.3，與 【系統升級】b2evolution from 1.8.2 to 1.10-beta。

沒想到，整個升級的過程相當不順利。 先是執行 phpmyadmin 所下載回來的資料庫 Dump SQL 檔，全都是亂碼。找了許久，才發現到連線校對系統給我的預設為 utf8-unicode-ci, 我沒看清楚，以為是正確的，結果應該是設定為 utf8-general-ci 才對。 然後，執行升級的程序(script)後，資料庫是可以順利升級沒錯，但是，部落格首頁(以及系統頁面的 Blog設定標籤)總是在最後面會出現錯誤訊息：

An unexpected error has occured!
If this error persits, please report it to the administrator.
Go back to home page
Additional information about this error:
Requested User does not exist!

從官方網站討論區找解答，仍是找不出所以然。 然後又想啟動 DEBUG 模式，結果呢，一啟動 DEBUG 本身也是 Bug，它會出現：

MySQL error!
Variable ‘sql_mode’ can’t be set to the value of ‘TRADITIONAL'(Errno=1231)
Your query:
SET sql_mode = “TRADITIONAL”

又再去查了資料，發現到應該是與 MySQL 版本(只有 v5 以上才支援上述的模式)有關，但是目前我使用的 v4 版本實在不知道如何設定．．．。

弄到凌晨兩點多，不想再弄了，想說倒回去還原好了。 結果呢，資料庫因為新舊版的 Schema 定義並不一樣，必須砍掉再從我原來的備份檔上傳載入(Import)。使用原來我一直用來很順利的 BigDump.php ，這次竟然不靈，在 Dump 備份檔的過程中，它一直顯示出問題，好像是某一些 INSERT 的資料行有太多的 LF RETURN 符號所致？ 只好改用 phpmyadmin，但是又因為備份檔高達 27MB，結果導致 Import 上傳會 Time-out，弄得到後來我只好分批切幾個備份檔，再一一載入，才完成還原的工作。 至於 blog 檔案目錄，就很簡單了，把原先備份在 server 的目錄(已更名)，再更名回來就可以了。 弄得灰頭土臉，到今日近 5:00 時才又恢復原來的系統，實在是耗費了一整夜的白工！

這一次最大的教訓就是，應該把原來的資料庫直接給複製到 Server 端另一個資料庫系統就好了，透過 Dump 檔執行還原工作，耗費時間且不是太保險(當然，無論如何還是要 export 備份出來)。 再來就是，應該先在我自己 Local 的 VM(Virtual Machine) 環境內，先預先作過完整的升級過程，待沒有問題的話，再至 Server 端執行升級作業，如此，才能確保升級的順暢，也不致影響部落格平台的運作。

我一直對 php-based 的密碼防護有蠻大的顧慮，將連線帳號密碼以明碼的方式寫入 php 設定檔中，感覺實在甚不安全。剛好在升級 xoops 系統時，爬文看到此篇：「把管理者帳號和密碼從Mainfile.php中移出來」 。想說應該同樣的方式也適用在 b2evolution 的系統下！

原理其實很簡單，b2 的帳號密碼是放在 \conf\_basic_config.php 中，不要把帳號密碼放在這裡，而是改成：

$db_config = array(
	'user'          => $db_user,     // your MySQL username
	'password'      => $db_passwd,     // ...and password
	'name'          => $db_name,  // the name of the database
	'host'          => 'localhost',    // MySQL Server (typically 'localhost')
);

而帳號密碼抽離出來，另存成一個檔案，就名為 b2evolution-auth.php ，放在 securedata 目錄下 (目錄與檔案名稱均可自訂) ：

$db_user   = "username";   //database username here 
$db_passwd = "password";  //database password here 
$db_name   = "b2evolution";    //your database name here 

而在原來的 _basic_config.php 內容中，在第一行加入如下：

include ("/home/hsdctw/securedata/b2evolution-auth.php");

該檔案存放的位置就是重點了。可不是存在 b2evolution 的子目錄下，而是應該儲存在你的 home 目錄，或者是在虛擬主機給你的根目錄下。例如以我的為例，就是放在 /home/securedata 下。如此除非 Hacker 有登入虛擬主機系統的權利，否則是無法從 web 下讀取到該檔案的內容，自然這也就形成密碼保護的目的了。