WordPress 是鷹眼觀察新網站的基礎架構，後台的操控與設定難度遠大於 Google Blogger，不過外掛（Plugins[1]，又稱插件）與佈景主題（Themes[2]）的豐富度也是遠遠勝過，雖說筆者對於如此龐大的外掛數量是否必要還是存疑的。
如果你要的是一個安全、穩定、簡單、易用，而且還可以進階設計與控制，我個人依然大推 Blogger 的 BPS 網誌系統。就算鷹眼觀察網已經搬家，我們還是會把 Blogger 當成備份站使用。
這幾天在不斷反覆的使用 WordPress，以及不斷不斷又不斷的重新安裝 WordPress[3] 之後，我將自己的心得與經驗用列表記錄如下，作為自己的工作日誌：
工具人提醒：本文可能包含程式、指令及核心的修改，請確定知道自己正在做什麼再動手；盡可能在修改前備份相關檔案與資料庫，並且在修改後立即查看網站是否有不良反應。
不使用 SEO 相關外掛程式？
這段辛酸的時間，我分別用過 WordPress Seo by Yoast 以及 All in One Seo 這兩套 WordPress 界中最知名的 SEO 軟體，它們兩位甚至連 Plugins 的 Popular 都分別立足在前五名中，其受歡迎與廝殺的程度可見一班，說明大家對網站的 SEO 都有高度需求。
不過網路上有一份實驗報告，指出這兩套軟體占用伺服器記憶體將近 0.7 MB “at least in Controlled Environment”，在有限的伺服器資源中，也可稱得上是螞蟻雄兵，因此是否要安裝上述兩套外掛需要你自行判斷。
有關 SEO 的需求，我認為沒有比網站對於讀者的友好度更重要。況且這些 SEO 軟體能做到的事情，我們都能透過簡單的網頁修改辦到（Blogger 可以提供你很好的訓練），也有許多精實的 Plugin 能針對額外需求提供服務，像是 Google XML Sitemaps。
如果是一般網頁分析的需求，建議直接在 Theme 的 Header 範本檔中內建 Google Analytics 程式追蹤碼。
而不管是 Sitemap 或是 Analytics，其實都是我們一般關注 SEO 軟體的主要功能。當然了，選一套設計良好的背景主題，內建的 SEO 服務對於使用者來說也很有使用價值。
從 Blogger 轉移至 WordPress
我在轉移文章的過程沒有使用 Blogger Plugin，因為網站對網站的轉移過程相當不穩定，這有可能是伺服器的問題（後來發現並不是 Bluehost 的錯，因為大多數伺服器都有相同問題）。
所以我的作法是先將 Blogger 完整匯出一個檔案（後台 > 設定 > 其他），接著在 WordPress.com 上建立一個全新的私人網站，再將剛剛的 XML 檔案匯入（後台 > 工具 > 匯入 > Blogger > Have a Blogger export file?），再用 WordPress 格式匯出（Tools > Export）新的 XML 備份檔案。
最後才是回到自己新架設的 WordPress 網站後台，匯入剛剛從 WordPress 產出的備份檔案（需要安裝 WordPress Importer Plugin）。
提示：如果匯入的過程中斷，可以試著反覆匯入同一個檔案；不過原因大多出在 XML 檔案過大，超出伺服器允許的單次上傳容量，可以請教管理員修改 php.ini 內的設定，調大上傳檔案容量允許上限。
安全防護（Security and Safety）
有關 WordPress 的系統安全與管理，前面提到 Blogger 有 Google 這位老大哥在幫忙做資安把關，因此你的密碼只要不外洩，基本上很難被攻克（不過有轉攻擊 Godaddy 的可能[4]）。
WordPress 卻是一切只能靠自己，我分別使用過網路上兩套知名的安全性軟體 Better WP Security 與 Wordfence Security，最後選擇的是 Better WP Security，至於原因嘛…… 純粹是推薦人數 2000 比 1000。
但是嚴格來說 Wordfence 比較炫，像我另外架設的實驗網站就是採用 Wordfence，對原始檔案是否遭到竄改的監控與比對有很大幫助，而且能看到各個參觀者的資料也挺有趣的（相對的代表耗資源）。
另外，無論你選用哪一套 Plugins，請務必進入檔案目錄中查看各個關鍵檔案的讀取 Read /寫入 Write /執行 Execute 權限。尤其是 .htaccess、wp-config.php 以及 php.ini 這三個主要系統檔案，最好分別設為 604、600、600。關於這部分說明，在 Codex 上有一份更改文件權限的說明文件[5]，有中文版本可以自行參考。
相關議題可參考我們在2018年新文章介紹：修復 WordPress 連線失敗 HTTP 500 Internal Server Error 的 8 種維修方案。
效能與速度（Performance and Speed）
網路上主推的 Plugin 包括 WP Super Cache（WPSC） 與 W3 Total Cache（W3TC），我個人選用 W3TC。不過我也未曾試過 WPSC，因為不管是網路文章的分析，或是推薦人數的差距，都沒有讓我嘗試的動力。
如果可以，我大力推薦 W3TC 開啟 CloudFlare CDN 模式，即使是 Free 版本，網站也會像用飛的一樣。
資料庫備份與復原
關於備份與復原的 Plugin，幾套推薦人數比較多的像是 BackUpWordPress、UpdraftPlus – WordPress Backup and Restoration、BackWPup Free – WordPress Backup Plugin、WP-DB-Backup，我在先前的測試網站中都曾經安裝過，功能大多大同小異，也是導致每一套都用過的主因，不過我最後的決定是全部都不採用。
不是說備份不重要，而是我希望透過手動的方式達到相同的目的（一切是資源導向）。Codex 有提供一份關於系統備份的說明文件，有需要的人可以自行參考[6]。
關於網站檔案的備份，我們只要透過 cPanel 將整個 WordPress 資料夾壓縮為一個檔案，再全部下載到電腦中即可。
至於資料庫的備份則是恰巧在 Better WP Security 中有提供這項功能（Backup WordPress Database），甚至有自動備份的排程服務（Scheduled Backups），大大省去我們用 phpmyAdmin 進入資料庫備份的麻煩。
智慧型裝置佈景主題
JetPack 的官方 Plugins 其實就有提供手機專用的佈景主題與模板設計，只是外觀不甚好看。
頗受歡迎的 WPTouch 則是與 W3 Total Cache 相容性不足（主要問題出在 Minify 的設定會破壞 CSS/JavaScript），最終也只能捨棄不用。
我的作法是在選用佈景主題（Themes）時直接挑選已經有響應式設計或稱自適應網頁設計（RWD, Responsive Web Design）的主題，如此一來便能省去安裝對應手機與平板電腦的主題外掛的麻煩（但是 Minify 的問題還是容易出現）。
搬移 WP-Content/UPLoads 資料夾
UPLoads 是 WordPress 預設的上傳資料夾，都是小寫（實因個人文字癖，不首字大寫會坐立難安啊啊啊），預設位置在 WordPress 主目錄下的 WP-Content 目錄中（還是小寫）。
提示：我會一再提到大小寫，是因為這真的很重要。切記在 Unix-Likes 架構下的 Linux 伺服器，大小寫指的是完全不一樣的東西。
對多數使用者來說，預設位置其實就是最方便的位置，不需要更動，也是最安全保守的方法，因此近來的 WordPress 才將這個原本開放使用者自行設定的選項給取消。
除非你有架構圖床的計畫！所謂圖床一般是指專門存放多媒體資源（尤其是指照片、圖檔）的位置，可以是同伺服器下的固定資料夾，或是另外建構一個新的圖床專用伺服器（例如：Amazon S3）。
圖床的目的不外乎是方便管理以及降低主伺服器的資源耗損。或是像我，只是為了方便重灌 WordPress（近來 Microsoft Windows 8.x 相當穩定，少了重灌的樂趣，所以轉移目標… 是有多愛重灌啊！？）。
一般更改預設的上傳路徑 UPLoads 的方法，是在 WordPress 目錄下的 WP-Config.php 檔案中，新增如下指令碼：
define( 'UPLOADS', 'wp-content/'.'Vedfolnir' );其中 ‘wp-content/’ 指的是在 WordPress 根目錄（Root）下的 WP-Content 目錄，而 Vedfolnir 就是我們新建的上傳目錄。另外，如果想在根目錄創建一個新的上傳目錄，指令碼可省略為：
define( 'UPLOADS', 'Vedfolnir' );然而，如果想用 URL/URI（Uniform Resource Identifier）的網址指向圖床，這並不是一件容易的事情。即便 WordPress 允許，基於檔案管理安全性的考量，正常的伺服器也不會允許外人（WordPress）隨便存放檔案到子網域或是 WordPress 自己根目錄的上層目錄中。
這讓我想起一句台詞，如果非要為這份愛定一個期限，我希望是一萬年（淚）……… 呃，我是說這題還是有解決方案。
有站長是自行建構圖床後，用 FTP 上傳的方式將文章要用的圖檔先傳入圖床，再到文章中插入圖片（Windows Live Writer 更方便，直接提供文章圖片可另外上傳到 FTP 的功能）。
另外一種解決方案則需要更動資料庫（Database > wp_options > upload_url_path），目前我沒打算做這麼大的工程，所以還是乖乖的在 WordPress 根目錄下建立方便管理的資料夾就好。以後有需要用到圖床時，只要進資料庫一次取代字串即可[7]。
搬移 WP-Content 上傳資料夾
進一步來說，不管是為了方便管理、方便備份，或是為了增加駭客的一丁點麻煩，如果你打算將整個 WP-Content 目錄完全移動到其他位置存放，方法更簡單（Better WP Security 僅提供修改目錄名稱的功能）。
我們只要先用 FTP 軟體/網頁，將整個 WP-Content 目錄移動到隱藏位置後，在 WordPress 目錄下的 WP-Config.php 檔案中，新增包含有 ‘WP_CONTENT_DIR’ 變數，如下列所列的指令碼即可：
define( 'WP_CONTENT_DIR', $_SERVER['DOCUMENT_ROOT'] . '/content/wp-content' );或者，使用絕對路徑的對應變數 ‘WP_CONTENT_URL’，完整指令碼如下：
define( 'WP_CONTENT_URL', 'https://www.Vedfolnir.com/content/wp-content' );提示：我不建議初學者更動 WP-Content 位置，畢竟 WordPress 會安裝許多 Plugins，然而開發者的思維並非都很周全，就怕一個路徑弄錯會讓我們躺著也中彈 :-P。
結語
大概是 Blogger 用了太久，對於那些你無法瞭解就能使用的功能，總是不太放心。
Blogger 的頁面規範簡化了網站複雜度，所有東西都塞在同一個頁面上多好啊。但是 WordPress 的架構為了方便程式開發卻不能妥協，因此才會讓初學者覺得難以入手。關於 WordPress 的設計架構，可參考 Codex 上的 1.5 版說明文件[8]。
但是這不是最後，因為我還在繼續嘗試 WordPress 中。往後有更進一步的心得與經驗，會在本篇文章中繼續補充，所以請你務必追蹤粉絲團「鷹眼觀察」接收我們的最新消息！
發佈留言