有朋友問起如何開發一個 WordPress 外掛。我自己也不太會寫這方面的東西。就摘一篇官方的教程吧。自己也順便學習一下。
WordPress 外掛 允許你透過一種簡單的方式來修改、定義和強化部落格的功能。你可以在不修改 WordPress 的核心程式碼的情況下,透過外掛來直接向 WordPress 中增加功能。
以下是對 WordPress 外掛的基本定義:WordPress 外掛可以是一個程式,也可以是 PHP 語言編寫的一個或一組函式。它可以透過外掛 API 提供的一系列方法和介面,來向 WordPress 網站中增加一些特定的功能或服務,並且讓它們看上去就像是 WordPress 原有的功能一樣。
想要為你的部落格新增一些新的或者不一樣的功能?你可以先去 WordPress 外掛庫搜尋一下,看看是不是有人已經開發了一個符合你要求的 WordPress 外掛。如果很不幸——沒有,那麼這篇文章會指導你自己開發一個。
要想讀懂本文中的內容,你需要對 WordPress 的基本功能和 PHP 程式設計有一定的瞭解。
資源
- 如果想要了解 WordPress 外掛應當如何安裝,以及它們是怎樣工作的,去外掛資源集合裡看看,這裡有許多外掛開發者的文章和資源,包括如何編寫 WordPress 外掛,以及其它特定主題的文章等。
- 如果想要知道 WordPress 外掛是如何編寫的,你可以檢視一些外掛的原始碼,例如 WordPress 中自帶的 Hello Dolly 外掛。
- 如果你的外掛已經寫完了,並且感覺良好的話,你可以閱讀外掛提交以及推廣來學習如何把它釋出出去,與他人分享你的勞動成果。
建立外掛
這個部分告訴你怎麼把開發外掛的理想變為現實。
名字,檔案和位置
名字
首先你需要想好這個外掛是用來做什麼的,然後你就可以為它起一個獨一無二的名字。如果你不確定這個名字是否被使用過,你可以透過 Google 或者其他的方式來搜尋一下。大多數外掛開發者為外掛起的名字都能很直觀地描述它的功能,例如,一個與天氣有關的外掛的名字中就應當包含 「天氣」 兩個字。外掛的名字可以由多個字片語成。
檔案
下一步就是根據你外掛的名字,建立一個 PHP 主檔案。舉個栗子,如果外掛的名字叫做 「Fabulous Functionality」,那麼 PHP 主檔案的名字就可以是 "functionality.php",當然,還要注意重名的問題。因為使用者在安裝你的外掛的時候,會預設把你的外掛安裝到一個叫 wp-content/plugins/的目錄下,如果兩個外掛的檔名衝突了,那就杯具了。
你的外掛中至少應當包含一個 PHP 主檔案 (當然你也可以把它拆分成多個檔案),還可以包含 Javascript 檔案、 CSS 檔案、圖片檔案以及語言檔案等。如果你的外掛中包含多個檔案,你還需要建立一個資料夾,並把外掛包含的所有檔案放到這個資料夾中,這樣你只要讓其他人把整個資料夾放到 wp-content/plugins/目錄下就可以了。外掛資料夾的名稱通常和外掛 PHP 檔案的名稱相同,例如 PHP 檔案的名稱叫做 functionality.php 的話,資料夾的名稱就可以叫做 functionality 。
需要注意的是,由於在 WordPress 中可以配置 wp-content/plugins/目錄的位置,所以你必須使用 plugin_dir_path() 和 plugins_url() 兩個函式來獲取外掛的路徑。
檢視 http://codex.WordPress.org/Determining_Plugin_and_Content_Directories 以獲取更多資訊
- 在這篇文章之後的部分,如果再提到 「PHP 主檔案」 這個概念的話,指的就是外掛中最主要的 php 檔案,這個檔案通常位於
wp-content/plugins/目錄或其子目錄下。
自述檔案
如果你想將你的外掛釋出到 http://WordPress.org/extend/plugins/, 你必須在外掛包中建立一個標準格式的 readme.txt 檔案.
你可以訪問 readme.txt 檢視如何去格式化自述檔案,或者訪問 plugin-readme 來使用檔案自動生成器
需要注意的是,WordPress 是透過自述檔案來判斷這個外掛是處於 「必要」 還是 「測試」 狀態的。
主頁
為你的外掛建立一個主頁會非常有用,你可以在外掛的主頁上對外掛的功能、安裝方法、使用說明、適用的 WordPress 版本以及外掛更新資訊等進行介紹。
檔案頭
現在開始吧,首先讓我們向 PHP 主檔案中加入一些資訊
標準外掛資訊
外掛的主檔案頂部必須包括一個標準外掛資訊頭。 WordPress 透過標準資訊頭識別外掛的存在,並把它加入到控制面板的外掛管理頁面,這樣外掛才能啟用,載入外掛,並執行裡面的函式;如果沒有資訊頭,外掛將無法啟用和使用。標準資訊外掛頭的格式為:
<?php /* Plugin Name: 外掛名稱 Plugin URI: http://URI_Of_Page_Describing_Plugin_and_Updates Description: 外掛的簡單描述 Version: 外掛版本號, 例如: 1.0 Author: 外掛作者 Author URI: http://URI_Of_The_Plugin_Author 作者地址 */ ?>
標準資訊頭至少要包括外掛名稱,這樣 WordPress 才能識別你的外掛。其他資訊將顯示在控制面板外掛管理頁面中。標準外掛資訊對各行順序沒有要求。
版權資訊
通常我們還要在標準資訊頭中加入外掛的許可證資訊。大多數外掛使用 GPL 或 GPLCompatibleLicenses 許可。如果使用 GPL 許可,要求外掛中包含以下資訊:
<?php
/* Copyright 年份 作者名 (email : 你的郵箱)
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
*/
?>
開始編寫外掛
現在是時候讓你的外掛做些事情了。這部分內容包括外掛開發的一般思路,以及需要完成的工作。
WordPress 外掛鉤子
在 WordPress 中,「外掛鉤子」 是一個非常重要的概念。許多 WordPress 外掛都是透過與外掛鉤子相關聯的方式,來完成他們的功能的。外掛鉤子的工作原理是:在 WordPress 執行期間,有許多特定的時間點,WordPress 會在這些時間點檢測相應的外掛鉤子,如果檢測到有函式與當前的外掛鉤子相關聯的話,就會執行這些函式。正是這些函式改變了 WordPress 的預設功能。
例如,當 WordPress 在發表一篇文章之前,會首先檢測一個名為」the_title」 的外掛鉤子 (過濾器型別的鉤子),如果此時有任何外掛的函式與這個鉤子相關聯的話,那麼文章的標題就會首先被這些函式依次進行處理,最後再把函式處理的結果顯示到螢幕上。所以,如果你的外掛想要對文章的標題進行處理的話,就需要將對應的處理函式註冊到名為」the_title」 的過濾器鉤子上。
再舉個例子,在 WordPress 即將生成</HTML> 標籤之前,會檢測一個名為」wp_footer」 的外掛鉤子 (動作型別的鉤子),如果此時有外掛的函式與這個鉤子相關聯的話,那麼 WordPress 就會先依次執行這些函式,然後再繼續生成</HTML> 標籤。
如果想要了解動作型別鉤子和過濾器鉤子的區別、如何向鉤子上註冊函式,以及 WordPress 在什麼時間點會呼叫哪些外掛鉤子,你可以參閱 Plugin API 。如果您發現了一個想要對其進行處理的時間點,但是 WordPress 並未對這個時間點提供外掛鉤子的話,您也可以透過 Reporting Bugs 向我們提出建議,您的建議通常都會被我們採納。
模版標籤
另一個向 WordPress 中加入外掛的方式就是建立自定義的模板標籤 Template Tags 。這樣如果有人想要使用你的外掛,就可以把這些標籤新增到他們的主題、側邊欄、文章內容以及任何合適的地方。例如,可以為外掛定義一個名為 geotag_list_states()的模板標籤函式,該函式可以為側邊欄的文章新增地理位置標籤,當點選這個標籤時,還可以開啟這個地理位置標籤下所有對應的文章。
要定義一個自定義模板標籤,你只需要寫一個 PHP 函式,然後把它透過檔案、外掛的主頁或是在 PHP 主檔案中宣告的方式告訴外掛的使用者就可以了。當你為這個函式編寫檔案的時候,如果還能夠提供一個該函式的使用示例,來告訴使用者在主題中應當如何呼叫這個函式,就再好不過了。
儲存外掛資料到資料庫
大多數 WordPress 外掛都需要獲取管理員或使用者輸入的一些資訊,並儲存在會話中,以便在過濾器函式 (filter) 、動作函式 (action) 和模板函式 (template) 中使用。若需要在下次會話中繼續使用這些資訊,就必須將它們儲存到 WordPress 資料庫中。
以下是將外掛資料儲存到資料庫的 4 種方法:
1. 使用 WordPress 的」 選項」 機制 (稍後會有介紹) 。這種方式適合儲存少量靜態的、具有特定名稱的資料——這類資料通常是網站所有者在建立外掛時設定的一些初始化引數,並且以後很少會進行改動。
2 、使用文章後設資料 (又名自定義域) 。這種方式適合儲存與個人文章、頁面或附件相關的資料。若需要了解更多,請參閱 post_meta 函式示例,以及與 add_post_meta() 相關的函式。
3 、使用自定義分類。這種方式適合儲存那些需要分門別類存放的資料,如使用者資訊、評論內容以及使用者可編輯的資料等,特別適合於當你想要根據某個型別去檢視相關的文章和資料的情況。若需要了解更多,請參閱 Custom Taxonomies 。
4 、建立一個新的,自定義的資料庫表。這種方式適合儲存那些與個人文章、頁面或附件無關的,會隨著時間逐漸增長的,並且沒有特定名稱的資料。關於如何使用,你可以閱讀 Creating Tables with Plugins 以獲取更多資訊。
WordPress 選項機制
參閱 Creating Options Pages,你將學會如何去建立一個自動儲存選項資料的頁面。
WordPress 有一個」 選項」 機制,用於儲存、更新以及檢索那些獨立的,具有特定名稱的資料。選項的值可以是字串、陣列,甚至是 PHP 物件 (當然,PHP 物件在儲存時必須能夠被序列化或轉換成字串,檢索的時候也必須能夠被反序列化) 。選項的名稱必須是字串,且必須是唯一的,這樣才能夠確保它們不會和 WoredPress 或其它外掛產生衝突。
通常情況下,你最好能夠對外掛選項的數量進行一下精簡。例如,如果你有 10 個不同名稱的選項需要儲存到資料庫中,那麼,你就可以考慮將這 10 個資料作為一個陣列,並儲存到資料庫的同一個選項中。
以下是讓你的外掛使用選項機制的主要函式:
add_option($name, $value, $deprecated, $autoload);
建立一個新的選項並儲存到資料庫中,若選項已存在,則不進行任何操作。
$name:必要引數 (string) 。要建立的選項的名稱。
$value:可選引數 (string) 。要建立的選項的值。預設值為空字串。
$deprecated:可選引數 (string) 。該選項是否已經過期。若需要讓後面的 $autoload 引數生效,則該引數必須傳入空字串或 null 。
$autoload:可選引數 (enum: 『yes』 or 『no』) 。是否自動載入該選項。若設定為 『yes』,則該選項會被 get_alloptions 函式自動檢索到。預設值為 『yes』 。
get_option($option);
從資料庫中獲取指定選項的值。
$option:必要引數 (string) 。選項的名稱。你可以在 Option Reference 中找到與 WordPress 一同安裝的預設選項列表。
update_option($option_name, $newvalue);
更新資料庫中的選項值,若選項不存在,則建立該選項。 (注意:如果你用不到 $deprecated 和 $autoload 引數的話,那麼大可不必使用 add_option 函式) 。
$option_name:必要引數 (string) 。要更新/建立的選項名稱。
$newvalue:必要引數 (string|array|object) 。要更新/建立的選項的值。
管理面板
假定你的外掛有一些選項 (option) 儲存於 WordPress 的資料庫中 (參看上一節), 你可能會想要一個主控面板來允許你的外掛使用者檢視和編輯選項值。實現這一目標的方法闡述於 Adding Administration Menus 。
外掛國際化
在你完成了你的外掛的編寫工作之後,另一個需要考慮的問題 (假設你準備跟大家分享你的外掛的話) 就是將其國際化。國際化就是將你的軟體設定成能夠本地化的過程;本地化是將軟體中顯示的語言翻譯成其他語言的過程。 WordPress 正在被全球的人們使用,所以全球化和本地化是他內在的特性,這其中就包括了外掛的本地化。
我們十分希望你能夠將你的外掛國際化,這樣其他國家的使用者就可以在自己的本地使用它了。我們有一個關於國際化的綜合說明在 I18n for WordPress Developers,這其中就包括了一個描述外掛國際化的部分。
更新你的外掛
這個部分描述必要的步驟來更新你在 http://WordPress.org/extend/plugins 上的外掛, 還包括在 WordPress.org 中使用 Subversion(SVN) 的細節。
假設你已經提交了你的外掛到 WordPress 外掛儲存庫。隨著時間的推移, 你可能會發現需要並希望將新增新的功能到您的外掛或修正錯誤。你常常想要完成這些改變並提交它們到你的外掛的主幹。變化將是公開可見的, 但只有專業人員透過 SVN 才能檢視你的外掛,其他使用者透過網站或他們的 WordPress 外掛管理下載的將不會改變。
當你準備釋出一個新版本的外掛時:
- 確保一切都被提交併且新版本可以正常工作。注意測試所有你的外掛所支援的 WordPress 版本。也不只是測試新特性,確保你沒有不小心破壞一些老的功能外掛。
- 更新主 PHP 檔案中頭註釋的版本號 (在主資料夾) 。
- 更新 readme.txt 檔案中的』Stable tag』 的版本號 (在主資料夾) 。
- 在 readme.txt 檔案中新增一個新的部分——「更新日誌 (changelog)」, 簡要描述相比於最後一個版本的變化。它將被列在外掛頁中。
- 提交這些更改。
- 建立一個新的 SVN 標籤作為主幹的副本, 參見這裡。
給系統幾分鐘去工作, 然後檢查 WordPress.org 外掛頁面和 WordPress 上安裝你的外掛的頁面, 看看一切是否正確更新和是否在你安裝的 WordPress 中顯示了外掛更新 (更新檢查可能會被快取, 這可能需要一些時間, 試著訪問 「可用更新」 的頁面在你安裝的 WordPress 中) 。
故障排除:
- 在 WordPress.org 上的外掛頁面仍然列出了舊版本。你是否更新主資料夾中的』stable tag』?只是建立一個標籤, 更新 readme.txt 在標籤資料夾中是不夠的!
- 外掛頁面提供了一個新版本的 zip 檔案,但按鈕仍然列出了舊版本號並且在你的安裝 WordPress 中並沒有更新通知。你是否記得更新 「版本 (Version)」 的註釋在主 PHP 檔案中?
- 對於其他問題請參考 Ocodeo 的關於常見問題的頁面:The Plugins directory and readme.txt files
外掛開發建議
最後這個部分是關於開發外掛的一些建議。
- WordPress 外掛的程式碼應該遵循 WordPress Coding Standards. 另外請同時參考 Inline Documentation 。
- 你的外掛中所有函式的名稱都應該與現存的 WordPress Core 函式,其他外掛或主題的任何名稱不同。基於這個原因,我們建議你在你的外掛的所有函式的名稱之前加上一個你自己選擇的字首,或者把你的外掛的函式都寫在一個類裡面 (當然這個類的名字也必須是唯一的) 。
- 請不要把 WordPress 資料庫表格字首 (通常是 「wp_」) 直接寫在你的外掛裡,請使用
$wpdb->prefix。 - 雖然資料庫的讀取相對便宜,但它的寫入是相當昂貴的。資料庫十分擅長獲取資訊並呈現給使用者,而且這些操作 (通常) 是非常迅速的。然而對資料庫進行改動就是一個非常複雜的過程了,而且需要使用更長的計算時間。因此,請儘量減少你對資料庫進行寫入的次數。在你編寫程式的時候就做好所有的準備,這樣就可以只在必須的時候再進行寫入了。
- 在資料庫裡只 SELECT 你需要的東西。儘管資料庫的讀取十分便捷,我們依然推薦你值查詢真正需要的資料,來儘量減少資料庫的負載。例如,如果你只想獲得表格的行數,不要使用
SELECT * FROM, 因為這樣的話每一行中的所有資料都會被讀出,導致記憶體的浪費。同樣的,如果在外掛中你只想獲得 post_id 和 post_author,請只SELECT這兩項來減少資料庫的負載。記住:在某一個操作的同時可能有其他上百個程式需要使用資料庫,而資料庫和伺服器都必須同時滿足所有這些程式的需求。學習怎樣儘量減少你的外掛對資料庫的使用可以避免對這些資源的濫用。 - 不要讓你的 PHP 出錯。在你的 wp_config.php 檔案中新增
define('WP_DEBUG',true);,對你的所有函式進行測試來確定是否有任何的錯誤或者警告。有多少,就修復多少,直到再也不出現為止。
原文:http://codex.WordPress.org/Writing_a_Plugin