ข้อผิดพลาดในการพัฒนาธีม WordPress ที่พบบ่อยที่สุด (และวิธีแก้ไข)

การส่งธีมไปยังไดเร็กทอรีธีมของ WordPress.org เป็นวิธีที่ยอดเยี่ยมในการแบ่งปันงานของคุณและมีส่วนร่วมในชุมชน WordPress ปัจจุบัน มีมากกว่า 7000 ธีมในไดเร็กทอรี ซึ่งเป็นที่นิยมมากที่สุดซึ่งมีการติดตั้งที่ใช้งานอยู่มากกว่า 300,000 รายการ (ไม่รวม Twenty____ Themes ที่มาพร้อมกับ WordPress และมีจำนวนการติดตั้งนับล้าน)

ก่อนส่งธีมของคุณไปยังไดเร็กทอรี สิ่งสำคัญคือต้องเข้าใจกระบวนการตรวจทานก่อน เพราะหากธีมของคุณไม่ตรงตามข้อกำหนด ธีมของคุณอาจถูกปฏิเสธทันที

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

https://make.wordpress.org/themes/handbook/review/required/

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

ขออภัย หากธีมของคุณมีปัญหามากเกินไป ธีมนั้นจะถูกปิดโดยไม่ได้รับอนุมัติ หากคุณตัดสินใจที่จะแก้ไขปัญหา คุณสามารถอัปโหลดธีมได้อีกครั้ง แต่จะเข้าร่วมที่ด้านหลังของคิว

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

กำลังอัปโหลดธีมของคุณ

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

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

หมายเหตุ: ผู้เขียนธีมที่มีประวัติการส่งธีมที่ไม่มีปัญหาสามารถสมัครเป็น "ผู้เขียนที่เชื่อถือได้" ได้

ปัญหาการตั้งชื่อ

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

เป็นไปได้อย่างไร? เหตุผลก็คือการทดสอบไม่ได้ตรวจสอบกับไดเร็กทอรีเพียงอย่างเดียว แต่เป็นการตรวจสอบกับระบบนิเวศของ WordPress ทั้งหมด หากมีการเปิดตัวธีมที่ใดก็ได้ (Github, ThemeForest เป็นต้น) และมีการติดตั้งที่ใช้งานอยู่มากกว่า 50 รายการ ชื่อนั้นจะไม่สามารถใช้งานได้

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

เอาต์พุตที่ไม่มีการหลีกเลี่ยง

ผู้ตรวจสอบธีมให้ความสำคัญกับความปลอดภัยเป็นอย่าง มาก แม้กระทั่งแหล่งข้อมูลเฉพาะ สามารถเขียนบทความทั้งบทความเกี่ยวกับการเขียนธีมที่ปลอดภัย แต่ในส่วนนี้ เราจะมาสำรวจแง่มุมหนึ่ง: การหลบหนีจากผลลัพธ์

Unescaped output ทำให้ผู้ใช้ธีมของคุณตกอยู่ในความเสี่ยง ต่อไปนี้คือตัวอย่างค่าที่ไม่ใช้ Escape ($title):

 $title = get_option( 'my_custom_title' );
เสียงสะท้อน '<h2>' $ชื่อ '</h2>';

ปัญหาข้างต้นคือในขณะที่เรารู้ว่าค่า $title ควร เป็นประเภทใด แต่เรายังไม่ได้ตรวจสอบว่าเป็นกรณีนี้หรือไม่

หากแฮ็กเกอร์จัดการเปลี่ยนค่าของ 'my_custom_title' ในฐานข้อมูล ธีมของคุณจะแสดงค่านั้นออกมา สิ่งนี้ทำให้เกิดความเสี่ยงอย่างมากเนื่องจากสามารถแทนที่ผลลัพธ์ที่ต้องการด้วย Javascript แบบอินไลน์:

 alert('สิ่งนี้เป็นอันตราย'); 

วิธีแก้ไขคือหลีกเลี่ยงเอาต์พุตทั้งหมดเพื่อให้แน่ใจว่ามีเฉพาะประเภทข้อมูลที่เราคาดหวังเท่านั้น

ตัวอย่างของเราสามารถแก้ไขได้ดังนี้:

 $title = get_option( 'my_custom_title' );
เสียงสะท้อน '<h2>' esc_html( $หัวเรื่อง ) '</h2>';

ข้อเสียของการใช้ esc_html คือการตัดแท็ก HTML ทั้งหมด หาก $title มีตัวหนาหรือตัวเอียง เช่น

 $title = 'บทความนี้ <strong>มีประโยชน์มาก</strong> มาก';
echo esc_html( $ชื่อ );

คำว่า 'very' จะไม่เป็นตัวหนาที่ส่วนหน้า แต่จะส่งออกรหัส <strong>มาก</strong> แทน

นี่แสดงให้เห็นว่าเหตุใดการใช้ฟังก์ชันการหลบหนีที่ถูกต้องสำหรับบริบทจึงเป็นสิ่งสำคัญ หากเราคาดหวัง HTML บางส่วนในผลลัพธ์ เราควรใช้ wp_kses_post() หรือ wp_kses() และตั้งค่าพารามิเตอร์ $allowed_html

ฟังก์ชันที่เอาต์พุตยังต้องถูกหลีกเลี่ยง:

 <a href="<?php echo esc_url( get_permalink() ); ?>">

ข้อยกเว้นคือฟังก์ชันหลักของ WordPress ที่มี 'the_' อยู่ในชื่อ ซึ่งมักจะใช้ Escape ไปแล้ว

 ฟังก์ชั่น the_permalink( $post = 0) {
    /**
     * กรองการแสดงลิงก์ถาวรสำหรับโพสต์ปัจจุบัน
     *
     * @ตั้งแต่ 1.5.0
     * @ตั้งแต่ 4.4.0 เพิ่มพารามิเตอร์ `$post'
     *
     * @param string $permalink ลิงก์ถาวรสำหรับโพสต์ปัจจุบัน
     * @param int|WP_Post $post Post ID, วัตถุ WP_Post หรือ 0 ค่าเริ่มต้น 0
     */
    echo esc_url( Apply_filters( 'the_permalink', get_permalink( $post ), $post ) );
}

ข้อความที่แปลไม่ได้

ธีมทั้งหมดจะต้อง 'พร้อมสำหรับการแปล' 100% จึงจะได้รับการยอมรับในไดเร็กทอรี ซึ่งหมายความว่าแต่ละสตริงข้อความที่เอาต์พุตธีมของคุณต้องสามารถแปลได้

WordPress มีระบบและฟังก์ชันสำหรับจัดการกระบวนการแปลอยู่แล้ว คุณเพียงแค่ต้องแน่ใจว่าสตริงของคุณใช้ฟังก์ชันที่ถูกต้อง

แม้ว่าจะใช้งานได้ง่าย แต่สิ่งนี้มักถูกมองข้าม เนื่องจากมันขัดกับวิธีที่ผู้คนเขียน HTML

โดยปกติ คุณอาจทำสิ่งนี้:

 <h1>404 - ไม่พบ</h1>

เพื่อให้แปลได้ คุณต้องเพิ่ม PHP บางตัว:

 // ฟังก์ชัน __ เป็นพื้นฐานของการแปล
<h1><?php echo __( '404', 'text-domain' ); ?>

// ฟังก์ชัน _e สะท้อนค่า
<h1><?php _e( '404', 'โดเมนข้อความ' ); ?>

// หนีและสะท้อนสตริง
<h1><?php esc_html_e( '404', 'โดเมนข้อความ' ); ?>

// การแปลเป็นภาษาท้องถิ่นและตัวแปร
<h1><?php _n( 'หนึ่งโพสต์', '%s โพสต์', $count, 'text-domain' ); ?>

สตริงที่ส่งออกโดยฟังก์ชันจะต้องพร้อมสำหรับการแปลด้วย:

 // ไม่พร้อมแปล :-(
<?php next_posts_link( 'รายการเก่า' ); ?>

// พร้อมแปล :-)
<?php next_posts_link( esc_html__( 'รายการเก่า', 'text-domain' ) ); ?>

เคล็ดลับ: ตัวอย่างโค้ดจำนวนมากใน codex.wordpress.org ไม่ได้ใช้ฟังก์ชันการแปล ดังนั้นควรระมัดระวังเมื่อคัดลอกและวาง

การจัดคิวทรัพยากรอย่างไม่ถูกต้อง

ไฟล์ .css และ .js ที่ธีมของคุณใช้ต้องจัดคิวโดยใช้ฟังก์ชันที่ถูกต้อง: wp_enqueue_style() สำหรับ CSS และ wp_enqueue_script() สำหรับ Javascript

ข้อผิดพลาดทั่วไปคือการฮาร์ดโค้ดสคริปต์และรูปแบบลงใน <head> หรือก่อนหน้า </body> โดยตรง มีปัญหาสองประการสำหรับแนวทางนี้:

1. ไม่สามารถลบออกได้

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

 /**
 * Dequeue จาวาสคริปต์ของธีม
 *
 * เชื่อมต่อกับการกระทำ wp_enqueue_scripts โดยมีลำดับความสำคัญล่าช้า (100)
 * เพื่อให้เป็นหลังจากที่สคริปต์ถูกจัดคิว
 */
ฟังก์ชั่น wptavern_dequeue_script () {
   wp_dequeue_script( 'ธีม-สคริปต์' );
}
add_action( 'wp_enqueue_scripts', 'wptavern_dequeue_script', 100 );

2. โหลดซ้ำ

หากคุณจัดคิวทรัพยากร เช่น jQuery และปลั๊กอินจัดคิวทรัพยากรด้วย WordPress ก็ฉลาดพอที่จะโหลดเพียงครั้งเดียว

 /**
 * เข้าคิว jQuery
 *
 * jQuery จะถูกโหลดเพียงครั้งเดียว แม้ว่าจะมีสอง enqueues
 * jQuery ถูกรวมเข้ากับ WordPress ดังนั้นเราจึงไม่จำเป็นต้องระบุ src 
 */
ฟังก์ชั่น wptavern_enqueue_script () {
   wp_enqueue_script( 'jquery' );
   wp_enqueue_script( 'jquery' );
}
add_action( 'wp_enqueue_scripts', 'wptavern_enqueue_script' );

หากคุณใส่ฮาร์ดโค้ด jQuery ลงใน <head> ของคุณแล้ว ไม่มีทางที่ WordPress จะรู้ และมันจะถูกโหลดสองครั้ง

ฟังก์ชันปลั๊กอินดินแดน

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

ในความพยายามที่จะเพิ่มมูลค่าให้กับธีมของพวกเขา ผู้เขียนธีมมักจะพยายามรวมฟังก์ชันพิเศษ เช่น การควบคุม SEO หรือประเภทโพสต์ที่กำหนดเอง

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

ตัวอย่างการใช้งานปลั๊กอิน-อาณาเขต:

• การวิเคราะห์/การติดตาม
• การควบคุม SEO
• แบบฟอร์มการติดต่อ
• รหัสย่อ
• Gutenberg Blocks

เคล็ดลับ: หากโค้ดของคุณเขียนลงในฐานข้อมูล มีความเป็นไปได้สูงที่จะเป็นพื้นที่ของปลั๊กอิน ข้อยกเว้นจะเป็นการตั้งค่าที่เกี่ยวข้องกับการออกแบบ (ตำแหน่งของแถบด้านข้าง สี ฯลฯ)

ไม่นำหน้า

คำนำหน้าเป็นวิธีที่ทำให้มั่นใจว่าโค้ดของคุณจะไม่ขัดแย้งกับโค้ดจากปลั๊กอิน Namespacing ใน PHP เป็นวิธีที่ดีกว่าในการบรรลุผลเช่นเดียวกัน อย่างไรก็ตาม ผู้ใช้บางคนยังคงใช้ PHP เวอร์ชันเก่า (5.2) ซึ่งไม่สนับสนุนคุณลักษณะดังกล่าว

Justin Tadlock แบ่งปันรายการของสิ่งทั่วไปที่ควรนำหน้า:

• ชื่อฟังก์ชัน PHP
• ชื่อคลาส PHP
• ตัวแปรทั่วโลกของ PHP
• แอคชั่น/ตะขอกรอง.
• สคริปต์จัดการ
• สไตล์ที่จับ
• ชื่อขนาดภาพ

ที่มา: https://themereview.co/prefix-all-the-things/

 // ตัวอย่างฟังก์ชัน
my_prefix_example();

// ตัวอย่างคลาส
คลาส My_Prefix_Example { … }

// ตัวอย่างการดำเนินการและตัวกรอง
do_action( 'my_prefix_action' );
Apply_filters( 'my_prefix_filter', $values ​​);

// ลำดับตัวอย่าง
wp_enqueue_script( 'my_prefix_script', get_template_directory_uri() . '/js/custom-script.js' );
wp_enqueue_style( 'my_prefix_style', get_template_directory_uri() . '/css/styles.css' );

// ตัวอย่างขนาดภาพ
add_image_size( 'my_prefix_image_size', 220, 180 ); // กว้าง 220 พิกเซล สูง 180 พิกเซล

ข้อยกเว้น: เมื่อจัดคิวทรัพยากรบุคคลที่สาม อย่าเพิ่มคำนำหน้า:

 // การจัดคิวสคริปต์บุคคลที่สาม (chosen.js)
 wp_enqueue_script( 'เลือก', get_template_directory_uri() . '/js/chosen.js' );

ปัญหาการออกใบอนุญาต

ธีมของคุณและไฟล์ทั้งหมดต้องเข้ากันได้กับ GPL 100% ซึ่งรวมถึงรูปภาพ ไลบรารี สคริปต์ และฟอนต์

ทรัพยากรของบุคคลที่สามทั้งหมดต้องระบุแหล่งที่มาและข้อมูลใบอนุญาต

ข้อกำหนดนี้อาจมีความยุ่งยากเป็นพิเศษ เนื่องจากใบอนุญาตบางประเภทไม่เหมาะกับ GPL ใบอนุญาต Unsplash มีข้อ จำกัด เพียงข้อเดียว:

“ใบอนุญาตนี้ไม่รวมถึงสิทธิ์ในการรวบรวมภาพถ่ายจาก Unsplash เพื่อทำซ้ำบริการที่คล้ายกันหรือแข่งขันกัน”

อย่างไรก็ตาม ข้อจำกัดเพียงอย่างเดียวก็เพียงพอแล้วที่จะทำให้มันไม่รองรับ GPL และด้วยเหตุนี้ คุณจะไม่เห็นรูปภาพ Unsplash รวมอยู่ในธีม wordpress.org

รายการใบอนุญาตที่เข้ากันได้กับ GPL มีให้ที่นี่ – https://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses

ล่าสุด, stocksnap.io เป็นแหล่งที่มาของรูปภาพที่พบบ่อยที่สุดในไดเร็กทอรี เนื่องจากรูปภาพ ทั้งหมด ที่อยู่ในรายการได้รับอนุญาตเป็น CC0 (เข้ากันได้กับ GPL)

ภาพหน้าจอข้อผิดพลาด

ข้อกำหนดระบุว่าภาพหน้าจอของคุณควรเป็นตัวแทนธีมของคุณที่ไม่มีการแก้ไขซึ่งดูไม่เหมือนโฆษณา นั่นหมายถึงไม่มีโฟโต้ชอป โอเวอร์เลย์ เส้นขอบ หรือเอฟเฟกต์แฟนซี

รูปภาพต้องเป็นไปตามข้อกำหนดสิทธิ์การใช้งานเดียวกันกับที่เราสำรวจด้านบน

โบนัส: ใช้มาตรฐานการเข้ารหัส

โค้ดที่อ่านและเข้าใจได้ง่ายสำหรับคุณ อาจเป็นสิ่งที่ตรงกันข้ามสำหรับผู้ตรวจทานที่มีเวลาเพียง 10-15 นาทีในการตรวจสอบโค้ดของคุณ

แม้ว่าจะไม่มีข้อกำหนดเกี่ยวกับมาตรฐานการเข้ารหัส แต่การปฏิบัติตามมาตรฐานจะทำให้อ่าน ทำความเข้าใจ และบำรุงรักษาโค้ดของคุณได้ง่ายขึ้น ผมเองใช้และแนะนำ 'มาตรฐานการเข้ารหัส WordPress' แม้ว่าจะมีอย่างอื่น

การใช้ PHP_CodeSniffer และชุดกฎของ WordPress ในตัวแก้ไขโค้ดของคุณสามารถทำให้การปฏิบัติตามมาตรฐานง่ายขึ้นมาก – https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards

บทสรุป

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