ज़्यादातर WordPress डेवलपर एक ही तरह शुरुआत करते हैं। आपको कोई काम का स्निपेट मिलता है, आप उसे अपनी थीम की functions.php में पेस्ट करते हैं, और वह चल जाता है। फिर दूसरा स्निपेट, फिर तीसरा। एक साल बाद functions.php 900 लाइनों की हो जाती है, और जिस दिन कोई नई थीम पर स्विच करता है, साइट के आधे फ़ीचर उसके साथ ग़ायब हो जाते हैं।
प्लगइन लिखना इसी आदत का परिपक्व रूप है, और यह जितना सुनने में लगता है उससे कहीं कम डरावना है। प्लगइन बस एक फ़ाइल हो सकती है जिसके ऊपर एक कमेंट हो। यह गाइड ख़ाली फ़ोल्डर से लेकर अपने सेटिंग पेज वाले साफ़, सुरक्षित प्लगइन तक ले जाती है, जिसमें हेडर, hooks, नामकरण, Settings API, और वे आदतें शामिल हैं जो मज़बूत प्लगइन को कमज़ोर प्लगइन से अलग करती हैं।
functions.php की जगह प्लगइन क्यों?
- थीम बदलने पर भी फ़ीचर बचे रहते हैं। नए डिज़ाइन से आपका बुकिंग फ़ॉर्म या custom post type नहीं टूटना चाहिए।
- आप फ़ीचर बंद कर सकते हैं एक प्लगइन को deactivate करके, जिससे समस्या ढूँढना बहुत आसान हो जाता है।
- कोड व्यवस्थित रहता है एक जगह, एक साफ़ मक़सद के साथ।
- यह दोबारा इस्तेमाल हो सकता है कई साइटों पर, और टीम के साथ शेयर करना आसान है।
एक अच्छा नियम: जो कोड बदलता है कि साइट कैसी दिखती है, वह थीम में जाता है; जो कोड बदलता है कि साइट क्या करती है, वह प्लगइन में जाता है।
क़दम 1: सबसे छोटा संभव प्लगइन
wp-content/plugins/ में एक फ़ोल्डर बनाएँ, जैसे acme-tweaks, और उसके अंदर acme-tweaks.php नाम की फ़ाइल:
<?php
/**
* Plugin Name: Acme Tweaks
* Description: Small site-specific features for Acme.
* Version: 1.0.0
* Author: Acme Studio
* Requires at least: 6.0
* Requires PHP: 7.4
* License: GPL v2 or later
* Text Domain: acme-tweaks
*/
if ( ! defined( 'ABSPATH' ) ) {
exit;
}यह एक वैध प्लगइन है। WordPress हेडर कमेंट पढ़ता है और इसे Plugins में दिखाता है, जहाँ आप इसे activate कर सकते हैं। ABSPATH जाँच फ़ाइल को WordPress के बाहर सीधे चलने से रोकती है।
Requires at least और Requires PHP लाइनें मायने रखती हैं: पुराने वर्शन पर WordPress प्लगइन activate करने से मना कर देता है, जिससे उन साइटों पर fatal error नहीं आते जो आपका कोड नहीं चला सकतीं।
क़दम 2: Hooks, हर प्लगइन का दिल
प्लगइन लगभग सब कुछ hooks के ज़रिए करते हैं। Actions आपका कोड किसी ख़ास पल पर चलाते हैं; filters किसी वैल्यू को बदलकर लौटाते हैं।
// Action: add a line to the footer.
function acme_footer_note() {
echo '<p class="acme-note">' . esc_html__( 'Thanks for visiting!', 'acme-tweaks' ) . '</p>';
}
add_action( 'wp_footer', 'acme_footer_note' );
// Filter: shorten excerpts to 30 words.
function acme_excerpt_length( $length ) {
return 30;
}
add_filter( 'excerpt_length', 'acme_excerpt_length' );सही hook चुनना आधा हुनर है। Post type init पर रजिस्टर करें, स्क्रिप्ट wp_enqueue_scripts पर लोड करें, एडमिन पेज admin_menu पर जोड़ें, और सेटिंग admin_init पर रजिस्टर करें।
क़दम 3: हर चीज़ पर prefix लगाएँ
हर WordPress साइट कई लेखकों का कोड एक ही global जगह में चलाती है। अगर आपका प्लगइन get_settings() नाम का फ़ंक्शन बनाता है और कोई दूसरा प्लगइन भी, तो साइट fatal error के साथ क्रैश हो जाती है।
हर फ़ंक्शन, constant, option नाम और hook पर कोई अनोखा prefix लगाएँ, जैसे acme_। ध्यान दें कि PHP नामों में hyphen नहीं हो सकता, इसलिए acme-tweaks जैसा slug, prefix acme_tweaks_ बन जाता है। बड़े प्लगइन के लिए PHP class या namespace यही काम ज़्यादा सलीक़े से करते हैं।
क़दम 4: एसेट WordPress के तरीक़े से लोड करें
स्क्रिप्ट या स्टाइल टैग कभी hard-code न करें। उन्हें enqueue करें ताकि WordPress dependencies संभाल सके और एक ही फ़ाइल दो बार लोड होने से बचे:
function acme_enqueue_assets() {
wp_enqueue_style(
'acme-tweaks',
plugin_dir_url( __FILE__ ) . 'assets/css/frontend.css',
array(),
'1.0.0'
);
}
add_action( 'wp_enqueue_scripts', 'acme_enqueue_assets' );एडमिन में, admin_enqueue_scripts को मिलने वाली $hook वैल्यू जाँचकर अपनी CSS और JavaScript सिर्फ़ अपने प्लगइन की स्क्रीन पर लोड करें। हर एडमिन पेज पर एसेट लोड करने से पूरा डैशबोर्ड धीमा हो जाता है।
क़दम 5: Settings API से सेटिंग पेज
Settings API आपके लिए सेव करना, sanitize करना और सुरक्षा जाँचें संभालता है। admin_init पर एक setting, एक section और एक field रजिस्टर करें:
function acme_register_settings() {
register_setting( 'acme_tweaks', 'acme_tweaks_options', array(
'type' => 'array',
'sanitize_callback' => 'acme_sanitize_options',
'default' => array( 'enabled' => 1 ),
) );
add_settings_section( 'acme_main', __( 'Settings', 'acme-tweaks' ), '__return_false', 'acme_tweaks' );
add_settings_field( 'acme_enabled', __( 'Enable features', 'acme-tweaks' ), 'acme_render_enabled', 'acme_tweaks', 'acme_main' );
}
add_action( 'admin_init', 'acme_register_settings' );फिर अपने एडमिन पेज पर settings_fields(), do_settings_sections() और submit_button() से फ़ॉर्म दिखाएँ। Settings API nonce जोड़ता है और options.php के ज़रिए सेव करता है, और आपका sanitize callback वैल्यू को स्टोर होने से पहले साफ़ करता है।
क़दम 6: पहले दिन से सुरक्षा की बुनियादी बातें
चार आदतें प्लगइन की ज़्यादातर कमज़ोरियाँ रोकती हैं: इनपुट sanitize करें, आउटपुट escape करें, nonce verify करें, और current_user_can() से capabilities जाँचें। WordPress सुरक्षा फ़ंक्शन की हमारी गाइड हर एक को उदाहरणों के साथ समझाती है, और WordPress Functions Reference में कॉपी करने लायक़ स्निपेट हैं।
Boilerplate छोड़ें
यह सब हाथ से सेट करना एक बार सीखने का बढ़िया तरीक़ा है, लेकिन उसके बाद हर बार उबाऊ है। WordPress Plugin Generator आपकी जानकारी भरकर इंस्टॉल के लिए तैयार ZIP बनाता है: वैध हेडर, मुख्य प्लगइन class, prefix वाले फ़ंक्शन और options, text-domain लोडिंग, फ़्रंट-एंड एसेट, WordPress.org फ़ॉर्मेट में readme.txt, और वैकल्पिक अतिरिक्त चीज़ें: टैब वाला एडमिन पेज, चालू Settings API फ़ॉर्म, एक उदाहरण widget, और दस्तावेज़ किए hooks जिन्हें दूसरे डेवलपर इस्तेमाल कर सकें। एडमिन CSS सिर्फ़ प्लगइन के अपने पेज पर लोड होती है।
क़दम 7: Activation, deactivation और uninstall
- Activation hook: डिफ़ॉल्ट options सेट करें या rewrite rules एक बार flush करें, जैसे custom post type रजिस्टर करने के बाद।
- Deactivation hook: cron events unschedule करें और अस्थायी डेटा साफ़ करें, लेकिन यूज़र की सेटिंग रहने दें।
- uninstall.php: प्लगइन डिलीट होने पर अपने options और डेटा डिलीट करें, ताकि कुछ पीछे न छूटे।
इसे अनुवाद के लिए तैयार बनाएँ
यूज़र को दिखने वाले हर टेक्स्ट को translation फ़ंक्शन में लपेटें, जैसे टेक्स्ट लौटाने के लिए __() और प्रिंट करने के लिए esc_html_e(), हमेशा अपने text domain के साथ: esc_html__( 'Settings saved.', 'acme-tweaks' )। अनुवाद load_plugin_textdomain() से लोड करें और प्लगइन में एक languages फ़ोल्डर रखें। शुरुआत में इसकी लगभग कोई क़ीमत नहीं है, और बाद में कोई भी आपके प्लगइन का अपनी भाषा में अनुवाद कर सकता है।
वर्शन ठीक से रखें
वर्शन नंबर एक constant में रखें और हर जगह उसी को इस्तेमाल करें: प्लगइन हेडर, एसेट वर्शन (ताकि अपडेट के बाद ब्राउज़र नई CSS लाएँ) और readme.txt में Stable tag। पहले commit से ही प्लगइन को Git में रखें, और हर रिलीज़ के लिए एक छोटी changelog एंट्री लिखें। जब कुछ टूटेगा और आपको जानना होगा कि क्या बदला, तब भविष्य का आप इसका शुक्रगुज़ार होगा।
क़दम 8: भरोसा करने से पहले टेस्ट करें
- लोकल या staging साइट पर
WP_DEBUGचालू करें और हर चेतावनी ठीक करें। - डिफ़ॉल्ट थीम के साथ और दूसरे आम प्लगइन चालू रखकर टेस्ट करें।
- इसे deactivate और फिर से activate करके पक्का करें कि कुछ न टूटे।
- मोबाइल पर फ़्रंट एंड और एडमिन जाँचें।
- लाइव जाने से पहले साइट को WordPress Security Checker से गुज़ारें।
आगे कहाँ जाएँ
एक आम अगला क़दम अपना content type जोड़ना है। WordPress custom post types की हमारी गाइड इसे ठीक से रजिस्टर करना सिखाती है, और वह कोड ठीक उसी तरह के प्लगइन में जाता है जो आपने अभी बनाया है।
आपके पहले प्लगइन को प्रभावशाली होने की ज़रूरत नहीं है। उसे एक साफ़ हेडर, prefix वाले नाम, सही hooks और सुरक्षा की कुछ आदतें चाहिए। इन्हें एक बार सही कर लें, और उसके बाद हर प्लगइन बस एक नया विचार है, उस ढाँचे में जिस पर आप पहले से भरोसा करते हैं।



