插件開發的目標最佳實踐

問題描述

啓動社區 wiki 來收集插件開發的客觀最佳實踐。這個問題是由 @EAMann’s comments on wp-hackers 啓發的。

這個想法是協調一些客觀的最佳實踐，以便我們最終可以在一些社區協作審核過程中使用它們。

更新：在看到前幾個答覆之後，很明顯，我們只需要有一個想法/建議/ best-practice 每個答案，人們應該查看列表，以確保在發佈之前沒有重複。

最佳解決方案

Use Actions and Filters

如果您認為人們想添加或更改某些數據：在返回之前提供 apply_filters()。

P.S. One thing I find a bit disappointing and that your question addresses is the percentage of plugins that are designed only for end-users, i.e. that have no hooks of their own. Imagine if WordPress were designed like most plugins? It would be inflexible and a very niche solution.

Maybe things would be different if WordPress were to have the ability to auto-install plugins on which other plugins depended? As it is I typically have to write a lot of the functionality I need from scratch because clients want things a certain way and the available plugins, while 90% there, don’t allow me the flexibility to update the remaining 10%.

I really do wish those leading the WordPress community would identify a way to ensure that plugins are rewarded for following best practices (such as adding in hooks for other developers) much like good answers are rewarded on a StackExchange site.

以 another question 為例：

Example: I want to do something in my plugin when someone retweets an article. If there was a custom hook in whatever the popular retweet plugin is that I could hook in to and fire off of, that would be great. There isn’t, so I can modify their plugin to include it, but that only works for my copy, and I don’t want to try to redistribute that.

Offer Extensible Forms

次佳解決方案

使用 `wp_enqueue_script` 和 `wp_enqueue_style` 加載腳本/ CSS

插件不應加載/嘗試加載 JS / CSS 文件的重複版本，尤其是 WP Core 中包含的 jQuery 和其他 JS 文件。

在連接 JS 和 CSS 文件時，插件應始終使用 wp_enqueue_script 和 wp_enqueue_style，而不要直接通過<script> 標籤。

Re-Use existing functions

第三種解決方案

I18n 支持

所有輸出字符串都應鏈接到適當的文本域，以便有興趣的方面進行國際化，即使開發人員沒有興趣翻譯自己的 plug-in 。

請注意，在 init 操作期間加載語言文件非常重要，因此用户可以掛接到該操作中。

見食典：I18n for WordPress Developers

還有這篇文章：Loading WP language files the right way 。其結論如下：

[…]
Finally, I would like to point out that is important to load custom user language files from WP_LANG_DIR before you load the language files that ship with the plugin. When multiple mo-files are loaded for the same domain, the first found translation will be used. This way the language files provided by the plugin will serve as a fallback for strings not translated by the user.

public function load_plugin_textdomain()
{
    $domain = 'my-plugin';
    // The "plugin_locale" filter is also used in load_plugin_textdomain()
    $locale = apply_filters( 'plugin_locale', get_locale(), $domain );

    load_textdomain(
            $domain,
            WP_LANG_DIR . '/my-plugin/' . $domain . '-' . $locale . '.mo'
    );
    load_plugin_textdomain(
            $domain,
            FALSE,
            dirname( plugin_basename(__FILE__) ) . '/languages/'
    );
}

第四種方案

確保插件使用 WP_DEBUG 生成無錯誤

始終使用 WP_DEBUG 測試您的插件，並在開發過程中理想地啓用它。插件不應該在 WP_DEBUG 上拋出任何錯誤。這包括已棄用的通知和未檢查的索引。

要打開調試開關，請編輯 wp-config.php 文件，使 WP_DEBUG 常數設置為 true 。有關詳細信息，請參閲調試法典。

第五種方案

首先在 WordPress 核心中使用現有的功能

如果可以：使用 WordPress 核心中的現有功能，而不是編寫自己的。只有在 WordPress 核心中沒有適當的 pre-existing 功能時才開發定製的 PHP 功能。

一個好處是您可以使用「日誌已棄用的通知」來輕鬆監控應該替換的功能。另一個好處是用户可以在 Codex 中查看功能文檔，並更好地瞭解插件的功能，即使他們不是經驗豐富的 PHP 開發人員。

第六種方案

使用輸入數據防止 SQL 注入

在使用輸入值查詢 MySQL 數據庫之前，插件應清理直接或間接檢索的所有用户輸入 (例如通過 $_POST 或 $_GET) 。

參見：Formatting SQL statements 。

第七種方案

卸載應該刪除所有插件的數據

從 WordPress 安裝中刪除後，插件應刪除其創建的所有文件，文件夾，數據庫條目和表以及其創建的選項值。

插件可能提供導出/導入設置的選項，以便在刪除之前可以將設置保存在 WordPress 之外。

Deactivation should not provoke Data-Loss

第八種方案

前綴所有全局命名空間項

一個插件應該適當地前綴所有全局命名空間項 (常量，函數，類，變量，甚至諸如自定義分類法，帖子類型，小工具等) 。例如，不要創建一個名為 init()的函數; 而是將其命名為 jpb_init()。

它的共同點應該是在名稱前面使用三個或四個字母的前綴，或者使用 PHP Namespace Feature 。比較：Single-letter prefix for PHP class constants?

Global Namespace is a limited Resource

第九種方案

使用類和麪向對象的 PHP5 代碼

沒有理由不寫乾淨的 object-orientated PHP5 代碼。 PHP4 的支持將在下一個版本 (WP 3.1) 之後逐步淘汰。當然，你可以把所有的函數名稱前綴到 finallyly_long_function_names_with_lots_of_underscores，但是編寫一個簡單的類並且捆綁所有的東西要容易得多。此外，將您的課程放在一個單獨的文件中，並相應地命名，以便您可以輕鬆地擴展和維護它：

// in functions.php
require 'inc/class-my-cool-plugin.php';
new MyCoolPlugin();

// in inc/class-my-cool-plugin.php
class MyCoolPlugin {
    function __construct() {
        // add filter hooks, wp_enqueue_script, etc.

        // To assign a method from your class to a WP
        // function do something like this
        add_action('admin_menu', array($this, "admin"));
    }

    public function admin() {
        // public methods, for use outside of the class
        // Note that methods used in other WP functions
        // (such as add_action) should be public
    }

    private function somethingelse() {
        // methods you only use inside this class
    }
}

第十種方案

停用不應該引起 Data-Loss

停用時，插件不應刪除任何數據。

Uninstall should remove all plugin’s data

參考文獻

Objective Best Practices for Plugin Development? [closed]

注：本文內容整合自 Google/Baidu/Bing 輔助翻譯的英文資料結果。如果您對結果不滿意，可以加入我們改善翻譯效果：薇曉朵技術論壇。