10 ข้อผิดพลาดที่พบบ่อยที่สุดที่นักพัฒนา WordPress ทำ

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

ข้อผิดพลาดทั่วไปหมายเลข 1: การปิดการดีบัก

เหตุใดฉันจึงควรใช้การดีบักเมื่อโค้ดของฉันทำงานได้ดี การดีบักเป็นคุณลักษณะที่สร้างขึ้นใน WordPress ซึ่งจะทำให้ข้อผิดพลาด คำเตือน และประกาศเกี่ยวกับ PHP ทั้งหมด (เกี่ยวกับฟังก์ชันที่เลิกใช้แล้ว ฯลฯ) ปรากฏขึ้น เมื่อปิดการดีบัก อาจมีการสร้างคำเตือนหรือการแจ้งเตือนที่สำคัญซึ่งเราไม่เคยเห็น แต่อาจทำให้เกิดปัญหาในภายหลังหากเราไม่จัดการกับปัญหาเหล่านั้นทันเวลา เราต้องการให้โค้ดของเราเล่นได้ดีกับองค์ประกอบอื่นๆ ทั้งหมดในไซต์ของเรา ดังนั้น เมื่อเพิ่มโค้ดที่กำหนดเองใหม่ลงใน WordPress คุณควรทำงานพัฒนาโดยเปิดการดีบักไว้เสมอ (แต่อย่าลืมปิดก่อนที่จะปรับใช้ไซต์ในเวอร์ชันที่ใช้งานจริง!)

ในการเปิดใช้งานคุณลักษณะนี้ คุณจะต้องแก้ไข wp-config.php ในไดเร็กทอรีรากของการติดตั้ง WordPress ของคุณ นี่คือตัวอย่างข้อมูลของไฟล์ทั่วไป:

 // Enable debugging define('WP_DEBUG', true); // Log all errors to a text file located at /wp-content/debug.log define('WP_DEBUG_LOG', true); // Don't display error messages write them to the log file /wp-content/debug.log define('WP_DEBUG_DISPLAY', false); // Ensure all PHP errors are written to the log file and not displayed on screen @ini_set('display_errors', 0);

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

ข้อผิดพลาดทั่วไปหมายเลข 2: การเพิ่มสคริปต์และรูปแบบโดยใช้ wp_head Hook

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

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

 wp_register_script( $handle, $src, $deps = array(), $ver = false, $in_footer = false ) wp_enqueue_script( $handle, $src = false, $deps = array(), $ver = false, $in_footer = false ) wp_register_style( $handle, $src, $deps = array(), $ver = false, $media = 'all' ) wp_enqueue_style( $handle, $src = false, $deps = array(), $ver = false, $media = 'all' )

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

ข้อผิดพลาดทั่วไปหมายเลข 3: หลีกเลี่ยงธีมลูกและการแก้ไขไฟล์หลักของ WordPress

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

ในการสร้างธีมลูก ให้วาง style.css ในไดเร็กทอรีย่อยของโฟลเดอร์ของธีมลูก โดยมีเนื้อหาดังต่อไปนี้:

 /* Theme Name: Twenty Sixteen Child Theme URI: http://example.com/twenty-fifteen-child/ Description: Twenty Fifteen Child Theme Author: John Doe Author URI: http://example.com Template: twentysixteen Version: 1.0.0 License: GNU General Public License v2 or later License URI: http://www.gnu.org/licenses/gpl-2.0.html Tags: light, dark, two-columns, right-sidebar, responsive-layout, accessibility-ready Text Domain: twenty-sixteen-child */

ตัวอย่างข้างต้นสร้างธีมลูกตามธีม WordPress เริ่มต้น Twenty Sixteen บรรทัดที่สำคัญที่สุดของโค้ดนี้คือบรรทัดที่มีคำว่า "เทมเพลต" ซึ่งต้องตรงกับชื่อไดเร็กทอรีของธีมหลักที่คุณกำลังลอกแบบมาจากเด็ก

หลักการเดียวกันนี้ใช้กับไฟล์หลักของ WordPress: อย่าใช้เส้นทางที่ง่ายโดยการแก้ไขไฟล์หลัก ใช้ความพยายามเป็นพิเศษโดยใช้ฟังก์ชันและตัวกรองที่เสียบได้ของ WordPress เพื่อป้องกันไม่ให้การเปลี่ยนแปลงของคุณถูกเขียนทับหลังจากการอัปเกรด WordPress ฟังก์ชันที่เสียบได้จะให้คุณแทนที่ฟังก์ชันหลักบางอย่างได้ แต่วิธีนี้ค่อยๆ ค่อยๆ เลิกใช้และแทนที่ด้วยตัวกรอง ตัวกรองให้ผลลัพธ์ที่เหมือนกันและถูกแทรกที่ส่วนท้ายของฟังก์ชัน WordPress เพื่อให้สามารถแก้ไขผลลัพธ์ได้ เคล็ดลับคือการห่อฟังก์ชันของคุณด้วย if ( !function_exists() ) เสมอเมื่อใช้ฟังก์ชันที่เสียบได้ เนื่องจากปลั๊กอินหลายตัวที่พยายามแทนที่ฟังก์ชัน pluggable เดียวกันโดยไม่มี wrapper นี้จะทำให้เกิดข้อผิดพลาดร้ายแรง

ข้อผิดพลาดทั่วไปหมายเลข 4: ค่าฮาร์ดโค้ด

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

 // Get child theme directory uri stylesheet_directory_uri(); // Get parent theme directory get_template_directory_uri(); // Retrieves url for the current site site_url();

อีกตัวอย่างที่ไม่ดีของฮาร์ดโค้ดคือเมื่อเขียนข้อความค้นหาที่กำหนดเอง ตัวอย่างเช่น เพื่อเป็นมาตรการด้านความปลอดภัย เราเปลี่ยนคำนำหน้าตารางข้อมูลของ WordPress เริ่มต้นจาก wp_ เป็นสิ่งที่พิเศษกว่าเล็กน้อย เช่น wp743_ การสืบค้นข้อมูลของเราจะล้มเหลวหากเราย้ายการติดตั้ง WordPress เนื่องจากคำนำหน้าตารางสามารถเปลี่ยนแปลงได้ระหว่างสภาพแวดล้อม เพื่อป้องกันไม่ให้สิ่งนี้เกิดขึ้น เราสามารถอ้างอิงคุณสมบัติของตารางของคลาส wpdb :

 global $wpdb; $user_count = $wpdb->get_var( "SELECT COUNT(*) FROM $wpdb->users" );

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

ข้อผิดพลาดทั่วไปหมายเลข 5: ไม่หยุดเว็บไซต์ของคุณจากการจัดทำดัชนี

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

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

โปรดทราบว่าเครื่องมือค้นหามัก ไม่ ปฏิบัติตามคำขอนี้ ดังนั้น หากคุณต้องการ ป้องกัน ไม่ให้เครื่องมือค้นหาสร้างดัชนีไซต์ของคุณ ให้แก้ไขไฟล์ . .htaccess และแทรกบรรทัดต่อไปนี้:

 Header set X-Robots-Tag "noindex, nofollow"

ข้อผิดพลาดทั่วไปหมายเลข 6: ไม่ตรวจสอบว่าปลั๊กอินทำงานอยู่หรือไม่

เหตุใดฉันจึงควรตรวจสอบว่ามีฟังก์ชันปลั๊กอินอยู่หรือไม่ หากปลั๊กอินของฉันเปิดอยู่เสมอ แน่นอนว่า 99% ของเวลาที่ปลั๊กอินของคุณจะเปิดใช้งาน อย่างไรก็ตาม 1% ของเวลาที่มันถูกปิดการใช้งานด้วยเหตุผลบางอย่างล่ะ? หากและเมื่อสิ่งนี้เกิดขึ้น เว็บไซต์ของคุณอาจแสดงข้อผิดพลาด PHP ที่น่าเกลียด เพื่อป้องกันสิ่งนี้ เราสามารถตรวจสอบเพื่อดูว่าปลั๊กอินทำงานอยู่หรือไม่ ก่อนที่เราจะเรียกใช้ฟังก์ชัน หากมีการเรียกใช้ฟังก์ชันปลั๊กอินผ่านทางส่วนหน้า เราจำเป็นต้องรวมไลบรารี plugin.php เพื่อเรียกใช้ฟังก์ชัน is_plugin_active() :

 include_once( ABSPATH . 'wp-admin/includes/plugin.php' ); if ( is_plugin_active( 'plugin-folder/plugin-main-file.php' ) ) { // Run plugin code }

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

 if( class_exists( 'WooCommerce' ) ) { // The plugin WooCommerce is turned on }

ผู้เขียนมักไม่ค่อยเปลี่ยนชื่อคลาสของปลั๊กอิน ดังนั้นโดยทั่วไปฉันขอแนะนำให้ใช้วิธีนี้

ข้อผิดพลาดทั่วไปหมายเลข 7: การโหลดทรัพยากรมากเกินไป

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

 function load_woo_scripts_styles(){ if( function_exists( 'is_woocommerce' ) ){ // Only load styles/scripts on Woocommerce pages if(! is_woocommerce() && ! is_cart() && ! is_checkout() ) { // Dequeue scripts. wp_dequeue_script('woocommerce'); wp_dequeue_script('wc-add-to-cart'); wp_dequeue_script('wc-cart-fragments'); // Dequeue styles. wp_dequeue_style('woocommerce-general'); wp_dequeue_style('woocommerce-layout'); wp_dequeue_style('woocommerce-smallscreen'); } } } add_action( 'wp_enqueue_scripts', 'load_woo_scripts_styles');

สคริปต์สามารถลบออกได้ด้วยฟังก์ชัน wp_dequeue_script($handle) ผ่านทางหมายเลขอ้างอิงที่ลงทะเบียนไว้ ในทำนองเดียวกัน wp_dequeue_style($handle) จะป้องกันไม่ให้โหลดสไตล์ชีต อย่างไรก็ตาม หากสิ่งนี้ยากเกินไปสำหรับคุณในการติดตั้ง คุณสามารถติดตั้ง Plugin Organizer ที่ให้ความสามารถในการโหลดปลั๊กอินแบบเลือกสรรตามเกณฑ์บางอย่าง เช่น ประเภทโพสต์หรือชื่อเพจ เป็นความคิดที่ดีที่จะปิดการใช้งานปลั๊กอินแคช เช่น W3Cache ที่คุณอาจเปิดไว้เพื่อหยุดคุณจากการรีเฟรชแคชอย่างต่อเนื่องเพื่อแสดงการเปลี่ยนแปลงใดๆ ที่คุณทำ

ข้อผิดพลาดทั่วไปหมายเลข 8: การรักษาแถบผู้ดูแลระบบ

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

 add_action('after_setup_theme', 'remove_admin_bar'); function remove_admin_bar() { if (!current_user_can('administrator') && !is_admin()) { show_admin_bar(false); } }

โค้ดด้านบนเมื่อคัดลอกลงในไฟล์ functions.php ของธีมของคุณจะแสดงเฉพาะแถบผู้ดูแลระบบสำหรับผู้ดูแลระบบของไซต์เท่านั้น คุณสามารถเพิ่มบทบาทหรือความสามารถของผู้ใช้ WordPress ลงในฟังก์ชัน current_user_can($capability) เพื่อแยกผู้ใช้จากการเห็นแถบผู้ดูแลระบบ

ข้อผิดพลาดทั่วไปหมายเลข 9: ไม่ใช้ GetText Filter

ฉันสามารถใช้ CSS หรือ JavaScript เพื่อเปลี่ยนป้ายกำกับของปุ่มได้ เกิดอะไรขึ้นกับมัน ใช่คุณสามารถ อย่างไรก็ตาม คุณกำลังเพิ่มโค้ดฟุ่มเฟือยและเวลาเพิ่มเติมในการแสดงผลปุ่ม เมื่อคุณสามารถใช้ตัวกรองที่ใช้งานง่ายที่สุดใน WordPress ที่เรียกว่า gettext ร่วมกับ textdomain ของปลั๊กอิน ซึ่งเป็นตัวระบุเฉพาะที่ช่วยให้ WordPress สามารถแยกแยะระหว่างการแปลที่โหลดทั้งหมด เราสามารถใช้ตัวกรอง gettext เพื่อแก้ไขข้อความก่อนที่จะแสดงผลหน้า หากคุณค้นหาซอร์สโค้ดสำหรับฟังก์ชัน load_plugin_textdomain($domain) มันจะให้ชื่อโดเมนที่เราจำเป็นต้องแทนที่ข้อความที่เป็นปัญหา ปลั๊กอินที่มีชื่อเสียงใดๆ จะช่วยให้แน่ใจว่า textdomain สำหรับปลั๊กอินได้รับการตั้งค่าเมื่อเริ่มต้นปลั๊กอิน หากเป็นข้อความในธีมที่คุณต้องการเปลี่ยน ให้ค้นหาบรรทัดโค้ด load_theme_textdomain($domain) การใช้ WooCommerce เป็นตัวอย่างอีกครั้ง เราสามารถเปลี่ยนข้อความที่ปรากฏสำหรับหัวข้อ "ผลิตภัณฑ์ที่เกี่ยวข้อง" ใส่โค้ดต่อไปนี้ลงในไฟล์ functions.php ของธีมของคุณ:

 function translate_string( $translated_text, $untranslated_text, $domain ) { if ( $translated_text == 'Related Products') { $translated_text = __( 'Other Great Products', 'woocommerce' ); } return $translated_text; } add_filter( 'gettext', 'translate_string', 15, 3 );

ตะขอตัวกรองนี้ใช้กับข้อความที่แปลโดยฟังก์ชันการทำให้เป็นสากล __() และ _e() ตราบใดที่ textdomain ถูกตั้งค่าผ่านฟังก์ชันดังกล่าว

 _e( 'Related Products', 'woocommerce' );

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

ข้อผิดพลาดทั่วไปหมายเลข 10: การรักษาลิงก์ถาวรเริ่มต้น

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

บทสรุป

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