WP_Query 在 WP 中的工作，就是幫你把文章從資料庫中搜尋出來。所以大約在部落格中 70% 以上的作業都與其有關係。

關於 WP_Query 最正確的解釋當然是其位於 WP codex 中的說明，前往觀看。老樣子，全篇文章為英文。

那 WP_Query 有多強大呢？

可以依照作者、分類、標籤、自訂分類標籤、文章(頁面)、時間、meta等條件下去檢索想要的文章出來，
再依照文章的某一項資料進行排序，
最後回傳指定數量的文章給使用者進行處理。

這樣說感覺上好像有一點複雜，不過說的講簡單一點，就是使用 WP_Query 之後就可以不用自己辛苦的下 SQL 語法來搜尋文章！註1

就隨便寫幾個例子來看看，至於仔細的說明有時間我在寫！

隨機推薦給我 10篇文章。

使用者A 發佈於 分類B 中的文章，全部給我顯示出來。
PS. 這裡的 A 跟 B 指的是 ID。

不過關於一個時間區間的文章，目前是沒辦法以單純調用 WP_Query 的方式達成，還需要配合 filter 下一小段 SQL 語法。這才是高級一點的應用方式。
給我最近一個月內修正的文章，數量20篇就好，以修正日來排序

註1：大約99%的情況，因為我有一個外掛暫時想不到改用 WP_Query 來抓取文章的方法，主要是牽扯到 postmeta 的問題。

站上撰寫了一些關於 WordPress 的教學文，不過因為站長我的惰性與現實生活中的忙碌。
讓站上的文章目前呈現一個停滯的狀態，對於有在關注本站的貴賓至上 十二萬分的歉意。
小的我真是不應該的開了一個網站而又讓他呈現荒廢狀態。

但我來是有在關注於 WordPress 的發展與台灣的推廣狀態。
所以今天來分享一個對於想要學習 WordPress 的人來推薦一各課程。

輕鬆學WordPress架站實作全攻略

這是由知名部落格的站長 阿湯 所開設的課程，他不只是知名的站長，也是 站長親授！WordPress 3.0部落格架站十堂課 的作者之一，相信他有一定的功力與實力，課程上一定可以充分的教會你如何實做，而你有任何的問題相信他也可以解答的。

還有想要知道更詳細的內容嗎？

請不要在這裡問我！因為我與這課程完全的無關，只因為參與過他們之前的活動，所以有收到課程的開課通知。
且基於這裡是 WordPress 的推廣教學網站，所以一定要分享這樣的訊息。
詳情還是請上他們的網站或他們連繫。

附上一些資訊

而二次引入原因是她在寫佈景主題的時候，因為需要使用到 jQuery 而在主題中直接的加入引用指令。
而她所使用的外掛中也有需要使用 jQuery 的，所以利用 WP 內建的 API 進行了 jQuery 的引入，所以才會發生二次引入的現象。
這時需要一些修正了，讓佈景主題也採用 WP API 的方式採入 jQuery 。
不過問題這麼簡單就不會想要寫一篇文章啦！還有需要轉換成使用 CDN 以節省流量。

廢話不多說啦！
要修正這些問題需要有幾個步驟！

首先讓我們將 jQuery 的網址轉向 Google CDN 的網址吧！
開啟你的佈景主題中的 functions.php 檔案，然後加入這一段程式碼

接下來，就是為你的佈景主題引用 jQuery 進來。
同樣是在 functions.php 檔案中加入以下程式碼

到此我就滿意了嗎？當然不是啦！那還剩下什麼東西要處理呢？

要教學當然一次搞定， jQuery UI 也順便轉向給 Google CDN 處理吧，都不要來浪費我寶貴的流量。
繼續在剛剛開啟的 functions.php 檔案中加入以下的程式碼

恭喜你完成了所有需要的修正，請記得存檔。同時將檔案上傳到 伺服器 中讓修改發生實際的作用。

在這些修改與引用的動作之中，都只有針對前台進行修改，後台的部分完全採用 WP 本身提供的 jQuery 與 jQuery UI 檔案。
因為如果讓後台也採用這些修正，會發生一些小小的問題，詳細原因並沒有研究。

至此，感謝各位的收看！

這期間只有短短的不到一個月的時間，就新的出現了，所以就是有一些重大的安全性問題的修正。
請各位用戶盡速的服用。

另外，中文版的維護者，好像遇到了些許的問題，希望是他的工作太忙碌了而沒有時間進行翻譯的工程。不過各位可以安新的自動更新成 英文版 的程式，因為你原本的中文語系還是會留下來，只有少部分會英文的狀態。
而 3.3 版多了很多提示的功能，這部分在中文版出來之前都會是英文，不過老手應該沒有差了！
新人就請先服用 2.8 的然後上網找找教學啦！這裡就有一些，不懂的也可以發問。

那這次更新了多少檔案呢？
其實不多，才19個，檔案明細如下：( 官網詳細說明 )

wp-includes/nav-menu-template.php
wp-includes/version.php
wp-includes/functions.php
wp-includes/user.php
wp-includes/functions.wp-styles.php
wp-includes/capabilities.php
wp-includes/script-loader.php
wp-includes/class-wp-admin-bar.php
readme.html
wp-admin/users.php
wp-admin/includes/dashboard.php
wp-admin/includes/update-core.php
wp-admin/includes/template.php
wp-admin/includes/ms.php
wp-admin/js/common.js
wp-admin/js/common.dev.js
wp-admin/load-scripts.php
wp-admin/press-this.php
wp-admin/about.php

首先是這次的改版量算是很大的，依目前的狀態一共新增 63個檔案、移除 75個檔案以及修改 352個檔案。
光是一將檔案解壓縮，就發現檔案少好幾個。新增的檔案集中在wp-includes，移除的檔案集中在 wp-admin。這時不知道自動化的升級會不會做移除的檔案。可以確定的是人工上傳的時候，升級成是不會主動的移除檔案。

確定有的是升級第三方程式，將 jQuery 從 1.6.1 升級到 1.7 版本。
根據 蘇主任 的提前測試，他是使用 WP 3.2.1 然後將 jQuery 升級成 1.7版本，在效能上有所提升。這部分也呼應了 jQuery 官方的說法。
同時也加入了更多的 jQuery UI 的程式進來。

同時新增 Plupload 這一套程式，這是一個很強大的上傳輔助程式，就是他讓網頁版的程式也實現了拖拉上傳的功能。

不過，發文的地方是沒有看到什麼重大的改變，不過使用的程式 tinymce 也是有經過一番的更新，相信會給線上編輯有更好的體驗。如果你是離線編輯的愛用者，建議可以上來嘗嘗鮮，因為有很多的不一樣。

在後台的側邊選單上，也做了些修正。只有目前選重的那一個大區塊會顯示細節，其他的區塊細節一律不顯式。在滑鼠滑道區塊大項目的時候，會側邊滑出來細節讓你點選。
這樣可以避免在後台很多的操作之後，側邊欄還是長得像沒有隱藏一樣，自己手動的再去隱藏。

在前台的 adminbar 部分，也做了一些修正，顏色更為純正。項目也重新整理排列過。

為了方便比較，這是三張圖合併在一起的，最上面的一張是現行的 WP 3.2.1 版本的樣式，下面兩張是新版的 WP 3.3 的樣式。
整體的大項目變少，不過感覺上影響不大！因為外觀的選項，會修改到的機會很少，消失了也不會有太大的影響。

另外，語系上也有不小的修正，在後台不時可以看到英文的出現。所以別太著急的更新英文版的WP3.3。
搶先爆爆到此~
期待正式版~~

如果不知道的人，偷偷的說 WordPress 也是

這次的更新主要是針對 Event 進行效率上的提升與強化，另外也對於 HTML5 的文盲瀏覽器 (IE6/7/8) 進行文字的訓練，讓其對於 HTML5 新出的語意標籤有更好的支援性。

詳細的內容就請上官網的 release note 觀看吧！
如果覺得英文不強的這邊找了幾個中文的看看搂，jQuery 1.7筆記@黑暗執行緒 或是 jQuery 1.7@男丁格爾’s 脫殼玩

另外，有藉由使用到瀏覽器本身提供的 matchesSelector API 功能來提升效率。
至於有多大的效能提升效益，底下這當圖官網提供的。

那麼既然 WordPress 本身有使用到，那在下一個版本會有這樣的更新嗎？
確定的，在 WordPress 3.3 將會更新成 jQuery 1.7 版本，所以各位愛用者請耐心的等待。目前是已經進行到 Beta 3 的階段，預計會在 2011年的某一時刻推出。

關看 WordPress trac 3.3 可以發現，目前的待處理事項已經完成 81%，剩下 98個事項要處理。不過根據之前的經驗，應該不會完全處理完畢，可能會有一些事項被延後至下一個版本。

那有如果有使用 Upload To FTP 的使用者，可能會發現了在媒體庫的資料中，多了一個欄位來顯示外掛的資訊。
就如同下面圖片所示這樣

當然這就是靠 WP 內建豐富的 hook 點來達成的。

這裡介紹了兩個hook，一個是 filter 型式的，另外一個是 action 型式的。至於這兩種之間的差別在之前的 外掛教學(四) 中提到。這邊就不在多說。

第一個 filter 是加最上面的標題列的資訊。
第二個 action 是為每一個媒體的添加詳細資訊。

這是第一個的函示範例，當然是直接取至 Upload to FTP 中的程式碼來用。
重點就是會傳入一個陣列的變數，然後將你要添加的資訊的辨識ID當作陣列的索引值(key)，然後顯示的標題文字當作陣列的內容值(value)。最後在將陣列回傳回去即可。

同樣的來源，不過我將內容簡化成只有一行輸出的指令。反正那就是重點，輸出資料的來源是關於你的外掛目的。這裡強調的是達成的手段。
這次改成需要兩個參數，其中第一個參數($name)代表的是目前處理的這一欄位的ID，就是與剛剛在標題列時設定的 ID 做對應，以免將資料顯示到其他外掛添加的欄位去。第二個參數($id)代表目前這一行的媒體 ID，以便我們去獲取相關的資料來呈現。

看完了，想要嘗試寫外掛的人可以動手試一試啦！

那麼，這裡講的是媒體庫的部分。
在 WordPress 的後台中，文章、分頁、連結、迴響、使用者 都是類似的呈現方式。想當然耳可以用類似的方法加入你想要的資訊。
文章的話為 manage_posts_columns 與 manage_posts_custom_column
分頁的話為 manage_pages_columns 與 manage_pages_custom_column
連結的話為 manage_link-manager_columns 與 manage_link_custom_column
迴響的話為 manage_edit-comments_columns 與 manage_comments_custom_column
使用者的話為 manage_users_columns 與 manage_users_custom_column

總而言之！
WordPress 是很活的，幾乎可以不用修改主程式而添加資訊到你想要的地方。

他提出了一個問題，再使用 Awstats 這一個Log檔案分析程式，分析一個以 WordPress 為系統的網站之時，發生在檔案類別的項目底下，有超過50%以上為無法得知檔案類型的。
因為小弟我也有使用這一套系統在分析，雖然主機商提供的不是這一到，但是看習慣了所以還是自己分析分析來研究一下。

大致上就像是上面這樣，有很高的比例屬於無法得知類型的。

但是其他的數據，基本上都沒有可惜的地方，流量沒有異常的上升，點擊數也沒有飆高，所以我猜測應該是正常的數據，只是被 Awstats 系統誤判。

一般的 LOG 檔案中的單一行會長得像是
0.0.0.0 – - [01/Sep/2011:01:13:09 +0000] "GET /2011/779 HTTP/1.1″ 200 21659 "http://fantasyworld.idv.tw/2011/779″ "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Q312461)"
這樣，顯示出 IP 時間 下達的指令 回復狀態 User-agent 等等的資訊
那麼 Awstats 如何得知檔案類型呢？
就是由記錄到的網址來判斷，但上面所表式的網址為 /2011/779 這樣，因為沒有副檔名的存在，所以才會被 Awstats 判斷為無法辨識的檔案類型。

因此，使用 WordPress 的使用者，加上設定的固定網址中沒有副檔名的狀態，就會發生這樣的問題。
我想這是多數使用者都會如此，所以不用太擔心。

題外話，這是我的每月跟九月的每日記錄，各位比較需要注意的是成長是否穩定，是否有單一日流量忽然很高。
可惜我沒有明顯有詭異的圖可以分享，但像上圖中的 22 日就是一個可疑的點，因為他的數據跟別人都不一樣。

這樣看起來不是很方便呢？想要到哪裡就要到哪！

最最簡單的方法，就是利用外掛的方式達成，以我所知的話會推薦使用 WP-PageNavi 這一個外掛。
因為他是我早期使用外掛階段時使用的，現在這功能我並不利用外掛，而是自己撰寫一個函式來使用。

早期，我是自己以 php 程式碼拼湊而成的，這樣就可以順利的運作啦！但是又想到在後台有這樣的功能，那麼 WordPress 應該有內建相關的函式可以讓我們利用。
在這樣的想法之下，找到了香腸的文章 如何讓WordPress有數字分頁功能？(非外掛) 。

但在使用一段日子之後，發現了在搜尋頁面的時候，他會失效。
因為多數人會將網址進行固定化的作業，但是在搜尋頁面的時候，WordPress 並沒有固定化的功能，所以採用香腸大的版本會出現問題，以下是小弟我的修正版，如果還是有疑問的話大家可以再提出，一定努力克服。

然後在你想要呈現的地方，加入以下的語法

這樣就可以順利的達成任務啦！
另外如果有使用快取外掛的使用者，記得清楚目前的快取資料，這樣使用者才可以看到你修改的結果！

外掛，就是要與 WordPress 的主系統產生連結的合併運作。
但是我們在寫外掛的時候卻又完全的沒有修正主程式，那之間是如何連結的呢？
就使用 WordPress 設計十分豐富的 Plugin Application Program Interface (外掛應用程式介面)，簡單的說就是 WordPress 程式中提供了數以百計的 API 嫁接點讓我們寫的外掛程式可以完美的遷入之中運行。

在與主程式進行嫁接的時候，又可以分為 Action(動作) 與 Filter(過濾器) 兩種不同的模式。註1

基本上，這兩種都是在該點執行外掛所撰寫的函式。
差別在於 Action 執行的含是不需要有回傳值，但可能會有傳入值(參數)。
而 Filter 的就需要有傳回值，相對的也就會有傳入值(參數)。
為了怕單純的文字說明有點難以理解，所以加了張自製的圖片來說明一下。註2

當要嫁接一個 Action 的時候，外掛會使用如下的函式來加入

當要嫁接一個 Filter 的時候，外掛會使用如下的函式來加入

你會發現兩者長相差不多，其各個參數的意義解釋如下
hook_name => 欲嫁接點的 action /filter hook 名稱
your_function_name => 所需要執行的函數名稱
priority => 優先權，預設值為 10，越小的數字越先執行
accepted_args => 你所執行的函數有幾個輸入值(參數)，預設為 1。某些 Action (Filter) 提供操過 2 個參數時即可以此設定。

那你會好奇在實際寫作的時候有多少得可以使用呢？
我也不清楚，這一直因為 WordPress 的版本更新而變更者，可以前往官方網站的 Codex 中有詳細說明。
Action 參考列表
Filter 參考列表

其中在看 Action 列表的那頁之時，最上面有一項標題為 Actions Run During a Typical Request 的內容，是一份根據 WordPress 3.0.1 版本生成一個頁面所會歷經的 Action 順序列表。這一份列表只是給你當作一個參考用的，因為實際上會因為妳所安裝的佈景主體、外掛種類、文章內容，等等的因素導致裂表中的項目被執行不只一次或是項目被停用或是新增。這只是一個預設合理情況下會被執行的列表給你做參考。

如此一來，有沒有多一點點的瞭解，外掛程式與主程式之間是如何達成互動的。
其實不單單是外掛以如此的方式運作，WordPress 程式本身很多時候也是利用此一機制在運行的。我們甚至可以藉由停用 action 或 filter 來改變原本 WordPress 的執行過程與內容，不過這部分就太深入了，以後有機會再慢慢的寫吧~

註1：因為翻譯成中文我個人覺得不是很好完美的翻譯，而且寫作與官方文件都是英文，所以我也會採用英文寫作。
註2：希望我的圖片不要反而照成大家的困惱。