เริ่มต้นวิกิพีเดียของชุมชนในการเก็บได้ถึงวัตถุประสงค์ปฏิบัติที่ดีที่สุดสำหรับการพัฒนาปลั๊กอิน คำถามนี้เป็นแรงบันดาลใจ@ EAMann ของความคิดเห็นเกี่ยวกับ WP-แฮกเกอร์

แนวคิดนี้คือการร่วมมือกันในการปฏิบัติที่ดีที่สุดตามวัตถุประสงค์เพื่อให้เราสามารถนำไปใช้ในกระบวนการตรวจสอบการทำงานร่วมกันของชุมชนในที่สุด

อัปเดต:หลังจากเห็นการตอบกลับสองสามครั้งแรกมันก็ชัดเจนว่าเราต้องมีเพียงหนึ่งความคิด / ข้อเสนอแนะ / แนวปฏิบัติที่ดีที่สุดต่อคำตอบและผู้คนควรตรวจสอบรายการเพื่อให้แน่ใจว่าไม่มีการซ้ำซ้อนก่อนโพสต์

ใช้การกระทำและตัวกรอง

หากคุณคิดว่าคนที่ต้องการที่จะเพิ่มหรือแก้ไขข้อมูลบางอย่างให้apply_filters ()ก่อนที่จะกลับ

PS สิ่งหนึ่งที่ฉันรู้สึกผิดหวังเล็กน้อยและคำถามของคุณคือเปอร์เซ็นต์ของปลั๊กอินที่ออกแบบมาสำหรับผู้ใช้ปลายทางเท่านั้นนั่นคือไม่มีตะขอของตัวเอง ลองนึกภาพว่า WordPress ถูกออกแบบเหมือนปลั๊กอินส่วนใหญ่หรือไม่? มันจะไม่ยืดหยุ่นและเป็นทางออกที่เฉพาะเจาะจงมาก

บางทีสิ่งต่าง ๆ อาจแตกต่างกันถ้า WordPress มีความสามารถในการติดตั้งปลั๊กอินอัตโนมัติที่ปลั๊กอินอื่นใช้ ตามปกติแล้วฉันต้องเขียนฟังก์ชั่นมากมายที่ฉันต้องการตั้งแต่เริ่มต้นเพราะลูกค้าต้องการบางอย่างและปลั๊กอินที่พร้อมใช้งานในขณะที่ 90% ที่นั่นไม่อนุญาตให้ฉันมีความยืดหยุ่นในการอัปเดต 10% ที่เหลือ

ฉันหวังว่าผู้ที่เป็นผู้นำชุมชน WordPress จะระบุวิธีการเพื่อให้แน่ใจว่าปลั๊กอินได้รับรางวัลสำหรับการปฏิบัติที่ดีที่สุด (เช่นการเพิ่ม hooks สำหรับนักพัฒนาอื่น ๆ ) เหมือนคำตอบที่ดีจะได้รับรางวัลในเว็บไซต์ StackExchange

ลองมาตัวอย่างจากคำถามอื่น :

ตัวอย่าง: ฉันต้องการทำบางสิ่งในปลั๊กอินเมื่อมีคนรีทวีตบทความ หากมีตะขอที่กำหนดเองในสิ่งที่ปลั๊กอิน retweet ที่เป็นที่นิยมคือฉันสามารถขอและดับไฟได้นั่นจะดีมาก ไม่มีดังนั้นฉันสามารถแก้ไขปลั๊กอินของพวกเขาเพื่อรวมไว้ได้ แต่ใช้งานได้เฉพาะกับสำเนาของฉันและฉันไม่ต้องการลองแจกจ่ายใหม่

ที่เกี่ยวข้อง

• เสนอแบบฟอร์มที่ขยายได้

โหลดสคริปต์ / CSS ด้วยwp_enqueue_scriptและwp_enqueue_style

ปลั๊กอินไม่ควรโหลด / พยายามโหลดไฟล์ JS / CSS เวอร์ชันที่ซ้ำกันโดยเฉพาะ jQuery และไฟล์ JS อื่น ๆ ที่รวมอยู่ใน WP Core

ปลั๊กอินควรใช้wp_enqueue_scriptและwp_enqueue_styleเมื่อเชื่อมโยงไฟล์ JS และ CSS และไม่ควรผ่าน<script>แท็กโดยตรง

ที่เกี่ยวข้อง

• ใช้ฟังก์ชั่นที่มีอยู่อีกครั้ง

รองรับ I18n

สตริงเอาต์พุตทั้งหมดควรเชื่อมโยงกับโดเมนข้อความที่เหมาะสมเพื่อให้เป็นสากลโดยผู้มีส่วนได้เสียแม้ว่านักพัฒนาจะไม่สนใจในการแปลปลั๊กอินของพวกเขาเอง

โปรดทราบว่าการโหลดไฟล์ภาษาในระหว่างการinitดำเนินการเป็นเรื่องสำคัญอย่างยิ่งเพื่อให้ผู้ใช้สามารถเชื่อมต่อกับการกระทำได้

ดู Codex: I18n สำหรับนักพัฒนา WordPress

และยังบทความนี้: โหลดภาษา WP ไฟล์ได้อย่างถูกต้อง

ตั้งแต่ WordPress 4.6+

WP 4.6 เปลี่ยนลำดับการโหลดและตรวจสอบตำแหน่งทำให้ผู้พัฒนาและผู้ใช้ง่ายขึ้นมาก

เมื่อพิจารณาถึงปลั๊กอินที่มี textdomain 'my-plugin', WordPress จะทำการค้นหาไฟล์แปลเป็นครั้งแรกใน:
/wp-content/language/plugins/my-plugin-en_US.mo

หากไม่พบที่นั่นปลั๊กอินนั้นจะค้นหาปลั๊กอินที่บอกให้ปลั๊กอินมองหา (ปกติในโฟลเดอร์ 'ภาษา' ของ pluigns หากติดตาม codex):
/ wp-content / plugins / my-plugin / languages ​​/ my- plugin-en_US.mo

สุดท้ายหากไม่พบไฟล์ภาษามันจะตรวจสอบตำแหน่งเริ่มต้นของ:
/wp-content/languages/my-plugin-en_US.mo

การตรวจสอบครั้งแรกถูกเพิ่มใน 4.6 และให้ผู้ใช้กำหนดสถานที่เพื่อเพิ่มไฟล์ภาษาเช่นเดียวกับก่อนที่พวกเขาจะต้องทราบว่านักพัฒนาเพิ่มไฟล์ภาษาตอนนี้ผู้ใช้เพียงแค่ต้องรู้ textdomain ของปลั๊กอิน: / wp-content / ภาษา / ปลั๊กอิน / TEXTDOMAIN-LOCAL.mo

ด้านล่างเป็นวิธีเก่า (ไม่เกี่ยวข้องตั้งแต่ WP 4.6+)

[ ... ]
สุดท้ายผมอยากจะชี้ให้เห็นว่าเป็นสิ่งสำคัญที่จะโหลดไฟล์ภาษาที่ผู้ใช้กำหนดเองจาก WP_LANG_DIR ก่อนที่คุณจะโหลดไฟล์ภาษาที่มาพร้อมกับปลั๊กอิน เมื่อโหลดไฟล์ mo- หลายไฟล์สำหรับโดเมนเดียวกันการแปลที่พบครั้งแรกจะถูกใช้ วิธีนี้ไฟล์ภาษาที่ปลั๊กอินเตรียมไว้จะทำหน้าที่เป็นทางเลือกสำหรับสตริงที่ไม่ได้แปลโดยผู้ใช้

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ดูCodex on Debugสำหรับรายละเอียดเพิ่มเติม

ใช้งานฟังก์ชั่นที่มีอยู่ใน WordPress Core ก่อน

หากคุณสามารถ: ใช้ฟังก์ชั่นที่มีอยู่รวมอยู่ในคอร์ WordPressแทนการเขียนของคุณเอง พัฒนาเฉพาะฟังก์ชั่น PHP ที่กำหนดเองเมื่อไม่มีฟังก์ชั่นที่มีอยู่แล้วที่เหมาะสมใน WordPress core

ข้อดีอย่างหนึ่งก็คือคุณสามารถใช้"บันทึกที่เลิกใช้งานแล้ว"เพื่อตรวจสอบฟังก์ชั่นที่ควรเปลี่ยนได้อย่างง่ายดาย ประโยชน์อีกอย่างคือผู้ใช้สามารถดูเอกสารฟังก์ชันใน Codex และเข้าใจดียิ่งขึ้นว่าปลั๊กอินทำอะไรได้แม้ว่าพวกเขาจะไม่ใช่นักพัฒนา PHP ที่มีประสบการณ์

ที่เกี่ยวข้อง

• รองรับ I18n
• โหลดสคริปต์ / CSS ด้วย wp_enqueue_script และ wp_enqueue_style
• เสนอแบบฟอร์มที่ขยายได้

การถอนการติดตั้งควรลบข้อมูลทั้งหมดของปลั๊กอิน

เมื่อถูกลบออกจากการติดตั้ง WordPress ปลั๊กอินควรลบไฟล์โฟลเดอร์รายการฐานข้อมูลและตารางทั้งหมดที่สร้างขึ้นรวมทั้งค่าตัวเลือกที่สร้างขึ้น

ปลั๊กอินอาจเสนอตัวเลือกในการส่งออก / นำเข้าการตั้งค่าเพื่อให้สามารถบันทึกการตั้งค่านอก WordPress ก่อนที่จะลบ

ที่เกี่ยวข้อง

• การเลิกใช้งานไม่ควรกระตุ้นการสูญเสียข้อมูล

ป้องกัน SQL Injection ด้วย Data Input

ปลั๊กอินควร ฆ่าเชื้ออินพุตของผู้ใช้ทั้งหมดที่ดึงมาโดยตรงหรือโดยอ้อม (เช่นผ่าน$_POSTหรือ$_GET ) ก่อนที่จะใช้ค่าอินพุตเพื่อสืบค้นฐานข้อมูล MySQL

ดู: งบการจัดรูปแบบ SQL

คำนำหน้ารายการเนมสเปซส่วนกลางทั้งหมด

ปลั๊กอินควรใช้คำนำหน้ารายการเนมสเปซส่วนกลางทั้งหมด (ค่าคงที่, ฟังก์ชั่น, ชั้นเรียน, ตัวแปร, แม้กระทั่งสิ่งต่างๆเช่น taxonomies ที่กำหนดเอง, ประเภทโพสต์, วิดเจ็ต ฯลฯ ) ตัวอย่างเช่นอย่าสร้างฟังก์ชั่นที่เรียกว่าinit(); jpb_init()แทนชื่อมันบางอย่างเช่น

ร่วมกันควรใช้คำนำหน้าสามหรือสี่ตัวอักษรหน้าชื่อหรือที่จะทำให้การใช้งานของคุณสมบัติ PHP Namespace เปรียบเทียบ: คำนำหน้าตัวอักษรเดียวสำหรับค่าคงที่คลาส PHP?

ที่เกี่ยวข้อง

• Global Namespace เป็นทรัพยากรที่ จำกัด

ใช้รหัส PHP5 ของคลาสและวัตถุที่ปรับทิศทาง

ไม่มีเหตุผลที่จะไม่เขียนโค้ด PHP5 ที่สะอาดและไม่เน้นวัตถุ การสนับสนุน PHP4 จะยุติลงหลังจากรีลีสถัดไป (WP 3.1) แน่นอนคุณสามารถใส่คำนำหน้าชื่อฟังก์ชันทั้งหมดของคุณลงไปได้อย่างไม่มีที่สิ้นสุดด้วย _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
    }
}

การเลิกใช้งานไม่ควรกระตุ้นการสูญเสียข้อมูล

ปลั๊กอินไม่ควร ลบข้อมูลใด ๆ ที่มีต่อการเสื่อม

ที่เกี่ยวข้อง

• การถอนการติดตั้งควรลบข้อมูลปลั๊กอินทั้งหมด

รวมเฉพาะไฟล์ที่คุณต้องการ ...

หากคุณอยู่ในส่วนหน้าอย่ารวมรหัสที่เกี่ยวข้องกับพื้นที่ของผู้ดูแลระบบ

ประกาศการถอนการติดตั้งปลั๊กอินสูญเสียข้อมูล

เมื่อถอนการติดตั้งปลั๊กอินที่ควร แจ้งให้ผู้ใช้ว่าจะลบมันเป็นข้อมูลและได้รับการยืนยันว่าผู้ใช้จะโอเคกับการลบข้อมูลก่อนที่จะทำเช่นนั้นและปลั๊กอินที่ควรนอกจากนี้ยังช่วยให้ผู้ใช้เลือกที่จะเก็บข้อมูลเมื่อถอนการติดตั้ง (แนวคิดนี้จาก @EAMann)

ที่เกี่ยวข้อง

• การถอนการติดตั้งควรลบข้อมูลปลั๊กอินทั้งหมด
• การเลิกใช้งานไม่ควรกระตุ้นให้เกิดการสูญเสียข้อมูล

ให้เปลี่ยนชื่อโฟลเดอร์ของปลั๊กอิน

/ ปลั๊กอิน / pluginname / {} ต่างๆ

"pluginname" ที่ใช้สำหรับโฟลเดอร์ควรเปลี่ยนแปลงได้เสมอ

นี่คือการจัดการตามปกติโดยการกำหนดค่าคงที่และใช้พวกเขาอย่างสม่ำเสมอตลอดทั้งปลั๊กอิน

ไม่จำเป็นต้องพูดว่าปลั๊กอินยอดนิยมจำนวนมากเป็นคนบาป

ที่เกี่ยวข้อง:

• plugins_url() เพื่อให้ง่ายต่อการลิงก์ไปยังแหล่งข้อมูลรวมอยู่ในปลั๊กอิน

ใช้การจัดการข้อผิดพลาด WordPress (ในตัว)

ไม่เพียงแค่return;ถ้าผู้ใช้บางคนป้อนผิด ส่งข้อมูลบางอย่างเกี่ยวกับพวกเขาว่าทำผิด

function some_example_fn( $args = array() ) 
{
    // If value was not set, build an error message
    if ( ! isset( $args['some_value'] ) )
        $error = new WP_Error( 'some_value', sprintf( __( 'You have forgotten to specify the %1$s for your function. %2$s Error triggered inside %3$s on line %4$s.', TEXTDOMAIN ), '$args[\'some_value\']', "\n", __FILE__, __LINE__ ) );

    // die & print error message & code - for admins only!
    if ( isset( $error ) && is_wp_error( $error ) && current_user_can( 'manage_options' ) ) 
        wp_die( $error->get_error_code(), 'Theme Error: Missing Argument' );

    // Elseif no error was triggered continue...
}

ข้อผิดพลาดเดียว (วัตถุ) สำหรับทุกคน

คุณสามารถตั้งค่าวัตถุข้อผิดพลาดทั่วโลกสำหรับชุดรูปแบบหรือปลั๊กอินของคุณในช่วง bootstrap:

function bootstrap_the_theme()
{
    global $prefix_error, $prefix_theme_name;
    // Take the theme name as error ID:
    $theme_data = wp_get_theme();
    $prefix_theme_name = $theme_data->Name;
    $prefix_error = new WP_Error( $theme_data->Name );

    include // whatever, etc...
}
add_action( 'after_setup_theme', 'bootstrap_the_theme' );

หลังจากนั้นคุณสามารถเพิ่มข้อผิดพลาดได้ไม่ จำกัด ตามต้องการ:

function some_theme_fn( $args )
{
    global $prefix_error, $prefix_theme_name;
    $theme_data = wp_get_theme();
    if ( ! $args['whatever'] && current_user_can( 'manage_options' ) ) // some required value not set
        $prefix_error->add( $prefix_theme_name, sprintf( 'The function %1$s needs the argument %2$s set.', __FUNCTION__, '$args[\'whatever\']' ) );

    // continue function...
}

จากนั้นคุณสามารถดึงข้อมูลทั้งหมดได้ในตอนท้ายของธีมของคุณ วิธีนี้คุณจะไม่ขัดจังหวะการแสดงผลหน้าเว็บและยังสามารถส่งออกข้อผิดพลาดทั้งหมดของคุณเพื่อการพัฒนา

function dump_theme_errors()
{
    global $prefix_error, $prefix_theme_name;

    // Not an admin? OR: No error(s)?
    if ( ! current_user_can( 'manage_options' ) ! is_wp_error( $prefix_error ) )
        return;

    $theme_errors = $prefix_error->get_error_messages( $prefix_theme_name );
    echo '<h3>Theme Errors</h3>';
    foreach ( $theme_errors as $error )
        echo "{$error}\n";
}
add_action( 'shutdown', 'dump_theme_errors' );

คุณสามารถค้นหาข้อมูลเพิ่มเติมได้ที่Qนี้ ตั๋วที่เกี่ยวข้องเพื่อแก้ไข "ทำงานร่วมกัน" ของWP_Errorและwp_die()มีการเชื่อมโยงจากที่นั่นและตั๋วอื่นจะตามมา ความเห็นนักวิจารณ์ & ดังกล่าวชื่นชม

ย่อชื่อที่เพิ่มเข้ามาใน Global Namespace

ปลั๊กอินควร ลดผลกระทบมากที่สุดเท่าที่เป็นไปได้โดยการลดจำนวนของชื่อจะเพิ่ม namespace

ซึ่งสามารถทำได้โดยการห่อหุ้มเซลล์แสงอาทิตย์ฟังก์ชั่นของปลั๊กอินเข้าไปในชั้นเรียนหรือโดยใช้คุณลักษณะ namespaces PHP คำนำหน้าทุกอย่างสามารถช่วยได้เช่นกัน แต่ไม่ยืดหยุ่น

ถัดจากฟังก์ชันและคลาสปลั๊กอินไม่ควรแนะนำตัวแปรกลาง การใช้คลาสปกติจะทำให้ล้าสมัยและทำให้การบำรุงรักษาปลั๊กอินทำได้ง่ายขึ้น

ที่เกี่ยวข้อง

• คำนำหน้าอย่างถูกต้อง

แสดงความคิดเห็นโดยใช้ PhpDoc

แนวปฏิบัติที่เหมาะสมที่สุดอยู่ใกล้กับสไตล์ PhpDoc หากคุณไม่ได้ใช้ IDE เช่น "Eclipse" คุณสามารถดูคู่มือ PhpDocได้

คุณไม่จำเป็นต้องรู้อย่างแน่นอนว่ามันทำงานอย่างไร นักพัฒนามืออาชีพสามารถอ่านรหัสต่อไปได้และต้องการเพียงสิ่งนี้เพื่อเป็นบทสรุป Hobby coders และผู้ใช้อาจชื่นชมวิธีที่คุณอธิบายในระดับความรู้เดียวกัน

ใช้ API การตั้งค่าก่อนที่จะเพิ่ม _option

แทนที่จะเพิ่มตัวเลือกให้กับฐานข้อมูลผ่านฟังก์ชั่น add_option คุณควรเก็บไว้เป็นอาร์เรย์ด้วยการใช้API การตั้งค่าที่ดูแลทุกอย่างให้คุณ

ใช้ API การปรับเปลี่ยนธีมก่อนที่ add_option

ปรับเปลี่ยน APIเป็นโครงสร้างที่เรียบง่ายสวยและเป็นวิธีที่ปลอดภัยที่ช่วยให้การเพิ่มและการเรียกตัวเลือก ทุกอย่างได้รับการบันทึกเป็นค่าต่อเนื่องในฐานข้อมูลของคุณ ง่ายปลอดภัยและเรียบง่าย

ปกป้องความเป็นส่วนตัวของผู้ใช้ปลั๊กอิน

(ก่อนหน้านี้: การสื่อสาร API นิรนาม)

หากปลั๊กอินสื่อสารกับระบบภายนอกหรือ API (เช่นบางเว็บเซอร์) มันควรทำโดยไม่ระบุตัวตนหรือให้ผู้ใช้มีตัวเลือกที่ไม่ระบุตัวตนเพื่อให้แน่ใจว่าไม่มีข้อมูลที่เกี่ยวข้องกับผู้ใช้ของปลั๊กอินรั่วไหลไปยังบุคคลที่สอง

โฮสต์ปลั๊กอินบน WordPress.org

ใช้พื้นที่เก็บข้อมูลSVN ที่มีให้ใน WordPress.orgสำหรับโฮสต์ปลั๊กอิน มันทำให้การอัปเดตประสบการณ์ผู้ใช้ง่ายขึ้นและถ้าคุณไม่เคยใช้ SVN มาก่อนมันจะทำให้คุณเข้าใจได้จริงโดยการใช้มันในบริบทที่ปรับให้เหมาะสม

ให้การควบคุมการเข้าถึงโดยใช้สิทธิ์

ในหลายกรณีผู้ใช้อาจไม่ต้องการให้ทุกคนเข้าถึงพื้นที่ที่สร้างโดยปลั๊กอินของคุณโดยเฉพาะอย่างยิ่งกับปลั๊กอินที่ดำเนินการหลายอย่างที่ซับซ้อนการตรวจสอบความสามารถ hardcoded เพียงครั้งเดียวอาจไม่เพียงพอ

อย่างน้อยที่สุดมีการตรวจสอบความสามารถที่เหมาะสมสำหรับโพรซีเดอร์ประเภทต่างๆทั้งหมดที่ปลั๊กอินของคุณสามารถใช้งานได้

นำเข้า / ส่งออกการตั้งค่าปลั๊กอิน

มันไม่ได้ว่าร่วมกันทั่วปลั๊กอิน แต่ถ้าคุณมีปลั๊กอิน (พอใช้) การตั้งค่าก็ควร ให้นำเข้า / ส่งออกของข้อมูลเช่นการตั้งค่าและการป้อนข้อมูลของผู้ใช้

นำเข้า / ส่งออกปรับปรุงการใช้งานของปลั๊กอิน

ตัวอย่างปลั๊กอินที่มีฟังก์ชั่นการนำเข้าและส่งออก (และกลไกการยกเลิก) เช่นBreadcrumb NavXT (ปลั๊กอิน Wordpress) (การเปิดเผยอย่างเต็มรูปแบบ: ฉันมีรหัสเล็ก ๆ น้อย ๆ ส่วนใหญ่ทำโดย mtekk)

ที่เกี่ยวข้อง

• การถอนการติดตั้งควรลบข้อมูลปลั๊กอินทั้งหมด
• การเลิกใช้งานไม่ควรกระตุ้นการสูญเสียข้อมูล

จัดระเบียบรหัสของคุณ

มันยากที่จะอ่านโค้ดที่ไม่ได้เขียนตามลำดับที่ได้รับการเรียกใช้ อันดับแรก ได้แก่ / require, define, wp_enqueue_style & _script ฯลฯ จากนั้นฟังก์ชั่นที่ปลั๊กอิน / ชุดรูปแบบต้องการและในที่สุดตัวสร้าง (เช่นหน้าจอผู้ดูแลระบบสิ่งที่รวมอยู่ในชุดรูปแบบ ฯลฯ )

พยายามแยกสิ่งต่าง ๆ เช่น css และ js ในโฟลเดอร์ของตนเอง ลองใช้วิธีนี้กับฟังก์ชั่นที่เป็นตัวช่วยเท่านั้นเช่น flatteners แบบอาเรย์และแบบเดียวกัน การรักษาไฟล์ "หลัก" ให้สะอาดและอ่านง่ายที่สุดเป็นวิธีที่ช่วยให้ผู้ใช้ผู้พัฒนาและคุณเมื่อคุณพยายามอัปเดตในหนึ่งปีและไม่เห็นรหัสเป็นเวลานาน

นอกจากนี้ยังเป็นการดีที่จะมีโครงสร้างที่คุณพูดซ้ำบ่อยๆดังนั้นคุณจึงหาทางผ่านได้เสมอ การพัฒนาโครงสร้างที่รู้จักในโครงการต่าง ๆ จะทำให้คุณมีเวลาที่จะทำให้ดีขึ้นและแม้ว่าลูกค้าของคุณจะเปลี่ยนไปใช้นักพัฒนาคนอื่นคุณจะไม่เคยได้ยิน "เขาละทิ้งความโกลาหล" สิ่งนี้สร้างชื่อเสียงของคุณและควรเป็นเป้าหมายระยะยาว

ตายอย่างมีสไตล์

ตายอย่างเหมาะสม ฟังก์ชั่นปลั๊กอิน (และธีม) ทั้งหมดควรใช้wp_die()ในสถานที่สำคัญเพื่อให้ผู้ใช้ทราบข้อมูลเล็กน้อยเกี่ยวกับสิ่งที่เกิดขึ้น ข้อผิดพลาดของ php นั้นน่ารำคาญและwp_dieสามารถให้ข้อความที่มีสไตล์แก่ผู้ใช้เกี่ยวกับสิ่งที่ปลั๊กอิน (หรือพวกเขา) ทำผิด นอกจากนี้หากผู้ใช้ปิดการใช้งานการดีบักปลั๊กอินจะเพิ่งแตก

ใช้wp_die()ยังช่วยว่าปลั๊กอินของคุณ / มีธีมที่เข้ากันได้กับTestSuite WordPress

• ใช้การจัดการข้อผิดพลาด WP

จัดเตรียมหน้าจอความช่วยเหลือสำหรับผู้ใช้

มันดีกว่าที่จะพูด RTFM (คลิกช่วย) เป็นคำตอบมากกว่าที่จะต้องตอบคำถามครั้งแล้วครั้งเล่า

/**
  * Add contextual help for this screen
  * 
  * @param $rtfm
  * @uses get_current_screen
  */ 
  function ContextualHelp( /*string*/ $rtfm) 
  { 
     $current_screen = get_current_screen();
     if ($current_screen->id == $this->_pageid) 
     {
        $rtfm .= '<h3>The WordPress Plugin - Screen A</h3>';
        $rtfm .= '<p>Here are some tips: donate to me ' .
     }
     return $rtfm; 
  }
add_action('contextual_help', array($this,'ContextualHelp'),1,1);

update / note: (ดูความคิดเห็นจากไกเซอร์): ตัวอย่างข้างต้นจะใช้ในชั้นเรียน

เสนอแบบฟอร์มที่ขยายได้

เมื่อปลั๊กอินมีความเป็นไปได้ในการป้อนข้อมูลควรมีตะขอที่ส่วนท้ายเสมอก่อนปุ่ม "ส่ง" และ / หรือ "รีเซ็ต" เพื่อให้นักพัฒนาสามารถขยายฟอร์มได้อย่างง่ายดายโดยไม่เพียง แต่ฟิลด์เท่านั้น

โปรดดู: การตั้งค่า API

ที่เกี่ยวข้อง

• ใช้การกระทำและตัวกรอง
• ใช้ฟังก์ชั่นที่มีอยู่อีกครั้ง
• รองรับ I18n

รวมฟังก์ชั่นเสมอผ่าน Hook ไม่ได้โดยตรง

ตัวอย่าง:

• อย่าใช้สำหรับรวมคลาสของปลั๊กอินผ่านทางใหม่โดยไม่ต้องขอ

• ใช้ Hook plugins_loaded

  // add the class to WP                                   
  function my_plugin_start() {                                                               
      new my_plugin();   
  }                                                        
  add_action( 'plugins_loaded', 'my_plugin_start' );

อัปเดต: ตัวอย่างสดขนาดเล็ก: Plugin-svn-trunk-page และตัวอย่างเทียม

//avoid direct calls to this file where wp core files not present
if (!function_exists ('add_action')) {
        header('Status: 403 Forbidden');
        header('HTTP/1.1 403 Forbidden');
        exit();
}

if ( !class_exists( 'plugin_class' ) ) {
    class plugin_class {

        function __construct() {
        }

    } // end class

    function plugin_start() {

        new plugin_class();
    }

    add_action( 'plugins_loaded', 'plugin_start' );
} // end class_exists

คุณยังสามารถโหลดผ่าน mu_plugins_loaded บน multisite-install ดู codex สำหรับการอ้างอิงการดำเนินการ: http://codex.wordpress.org/Plugin_API/Action_Reference นอกจากนี้ที่นี่คุณจะเห็นวิธีการใช้ wP พร้อมตะขอนี้: http: // adambrown info / p / wp_hooks / hook / plugins_loaded? version = 2.1 & file = wp-settings.php ฉันใช้มันบ่อยมากและมันก็ไม่ได้ยากและเร็วกว่าดีกว่าคลาสใหม่ยาก ();

ปลั๊กอินสิทธิ์การใช้งานภายใต้ลิขสิทธิ์ที่ใช้งานได้กับ GPL

ปลั๊กอินและธีมควรได้รับอนุญาตภายใต้ลิขสิทธิ์ที่เข้ากันได้กับ WordPress สิ่งนี้ทำให้พวกเขาสามารถแจกจ่ายซ้ำกับ WordPress ในฐานะ "โปรแกรม" ใบอนุญาตที่แนะนำคือจีพี โปรดระวังว่าไลบรารีโค้ดทั้งหมดที่มาพร้อมกับปลั๊กอินสามารถใช้งานได้กับสิทธิ์ใช้งานเดียวกัน

(นี่เป็นปัญหาและเป็นประเด็นถกเถียงอย่างจริงจังทั้งในอดีตและปัจจุบัน )

คำอธิบายปลั๊กอินของคุณควรมีรายละเอียดการทำงานของปลั๊กอินของคุณอย่างถูกต้อง มีปลั๊กอินโพสต์เด่น 10 รายการ พวกเขาทั้งหมดแสดงโพสต์ที่โดดเด่น แต่ส่วนมากมีคุณสมบัติที่แตกต่างกัน ควรเปรียบเทียบปลั๊กอินของคุณกับปลั๊กอินที่คล้ายกันโดยง่ายโดยการอ่านคำอธิบาย

คุณควรหลีกเลี่ยงการคุยโม้ว่าปลั๊กอินของคุณนั้นเรียบง่ายเพียงใดเว้นแต่ว่ามันเป็นพื้นฐานที่แท้จริง คุณควรรวมลิงค์ที่มีประโยชน์ไว้ในคำอธิบายเช่นลิงค์ไปยังการตั้งค่า

ลดผลข้างเคียงของ Remote Datasources และ Webservices

ปลั๊กอินควร แคช / โล่ Webserviceและ / หรือการร้องขอ XMLRPC / SOAP ผ่านชั้นแคช / ข้อมูลผู้ให้บริการถ้าคุณใช้พวกเขาเพื่อที่จะไม่ได้ทำคำขอด้านหน้ารอให้ (ช้า) การตอบสนองเว็บเซอร์

ซึ่งรวมถึงการดาวน์โหลดฟีด RSS และหน้าอื่น ๆ ออกแบบปลั๊กอินของคุณที่พวกเขาขอข้อมูลในพื้นหลัง

หนึ่งในขั้นตอนที่เป็นไปได้คือ (นำการโพสต์ไปที่ ping.fm เป็นตัวอย่าง): สร้างตารางบัฟเฟอร์สมมติว่า: ping_fm_buffer_post (วันที่, เวลา, ข้อความ, submitted_time, สถานะ)

1. ทุกครั้งที่คุณต้องการส่งการอัปเดตไปยัง ping.fm ให้เพิ่มลงในตารางนี้
2. ตอนนี้เราต้องสร้างปลั๊กอินเพื่อจัดการข้อมูลนี้ ปลั๊กอินนี้จะทำงานผ่าน crontab เพื่อตรวจสอบทุกการปรับปรุงที่ยังไม่ได้ส่ง
3. เนื่องจากเรามีตารางนี้เราจึงสามารถแสดงรายการทุกข้อความที่ส่งไปยัง ping.fm และตรวจสอบสถานะของแต่ละโพสต์ ในกรณีที่มีปัญหาทางด้าน ping.fm เราสามารถส่งได้อีกครั้ง

ทดสอบปลั๊กอินของคุณ

เราควรมีเครื่องมือทดสอบบางอย่างในสภาพแวดล้อมการพัฒนาปลั๊กอินของเรา

จากคำตอบนี้โดยEthan Seifertกับคำถามทดสอบนี่เป็นแนวทางปฏิบัติที่ดีที่ควรปฏิบัติตาม:

• การทดสอบหน่วยของคุณควรทดสอบจำนวนพฤติกรรมที่น้อยที่สุดที่คลาสสามารถทำได้
• เมื่อคุณได้รับการทดสอบการทำงานถึงระดับนี้เป็นที่ที่คุณสามารถทดสอบโค้ดของคุณด้วยการขึ้นต่อกันของ Wordpress
• ขึ้นอยู่กับปลั๊กอินของคุณ - พิจารณาใช้การทดสอบที่ใช้ซีลีเนียมซึ่งทดสอบว่ามีข้อมูลใน DOM โดยใช้ ID หรือไม่