外掛開發的目標最佳實踐

問題描述

啟動社群 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 輔助翻譯的英文資料結果。如果您對結果不滿意，可以加入我們改善翻譯效果：薇曉朵技術論壇。