چگونه گام‌به‌گام یک افزونه WordPress بسازیم؟
ساخت افزونه وردپرس از صفر چطور انجام می‌شود؟ راهنمای فنی گام‌به‌گام از ساختار پوشه و هدر افزونه تا هوک‌ها، پنل تنظیمات، امنیت و انتشار در مخزن رسمی.
ساخت افزونه وردپرس، اولین قدمی است که یک کاربر وردپرس را از مرحله‌ی «استفاده‌کننده» به مرحله‌ی «توسعه‌دهنده» منتقل می‌کند. اولین افزونه‌ای که خودم نوشتم، یک قطعه‌کد کوچک برای تغییر متن فوتر بود که در همان روز اول با خطای Parse error سایتم را سفید کرد. از آن تجربه یاد گرفتم که ساخت افزونه، بیش از آنکه نوشتن کد باشد، رعایت اصول و ساختار است. این مقاله، مسیر گام‌به‌گام همان تجربه و چندین افزونه‌ی بعدی است که در پروژه‌های واقعی نوشتم.
چرا افزونه بنویسیم و چه زمانی به آن نیاز داریم؟
پرسشی که در جلسات مشاوره زیاد می‌شنوم این است: چه زمانی باید یک قابلیت را در قالب پیاده‌سازی کرد و چه زمانی باید یک افزونه‌ی اختصاصی نوشت؟ تجربه‌ی من در پروژه‌های متعدد، پاسخ روشنی برای این پرسش پیدا کرده است. قاعده‌ی طلایی این است: اگر قابلیت به «منطق» مربوط است، جای آن در افزونه است؛ اگر به «ظاهر» مربوط است، جای آن در قالب یا چایلد تم است. این تفکیک، همان چیزی است که سال‌ها پیش در اصول معماری وردپرس نیز به آن اشاره شده است.
ساخت افزونه‌ی اختصاصی در سه سناریو منطقی است. نخست، وقتی می‌خواهید قابلیتی را پیاده‌سازی کنید که افزونه‌ی آماده‌ای برای آن وجود ندارد یا افزونه‌های موجود، نیاز شما را پوشش نمی‌دهند. دوم، وقتی می‌خواهید قطعه‌کدهایی را که در فایل functions.php قالب دارید، به یک بسته‌ی مستقل و قابل‌انتقال تبدیل کنید. سوم، وقتی می‌خواهید آن قابلیت را بین چند سایت به اشتراک بگذارید یا آن را با دیگران به‌عنوان یک محصول عرضه کنید. اگر با مفهوم کلی افزونه و جایگاه آن در معماری وردپرس آشنایی ندارید، راهنمای افزونه وردپرس چیست نقطه‌ی شروع مناسبی است.
نکته‌ای که در پرونده‌های واقعی دیده‌ام این است که بعضی توسعه‌دهندگان، افزونه‌نویسی را برای همه‌چیز انتخاب می‌کنند، حتی موارد کوچکی که یک اسنیپت ساده در چایلد تم کافی است. برای کارهای کوچک، ساخت افزونه‌ی کامل ممکن است بیش از حد باشد. مفهوم اسنیپت و تفاوت آن با افزونه‌ی کامل را در راهنمای قطعه کد وردپرس چیست توضیح داده‌ام و توصیه می‌کنم پیش از هر تصمیمی، آن را مرور کنید.
هر افزونه‌ای که می‌سازید، یک قطعه کد نیست؛ یک قطعه از معماری سایت شماست. آن را با همان دقتی بنویسید که یک کلاس در پروژه‌ی سازمانی می‌نویسید.
پیش‌نیازهای فنی برای ساخت افزونه
پیش از نوشتن اولین خط کد افزونه، باید سه پیش‌نیاز فنی را داشته باشید. نخست، تسلط پایه به زبان PHP؛ شما باید با توابع، آرایه‌ها، کلاس‌ها و ارث‌بری آشنا باشید. دوم، درک مکانیزم هوک‌های وردپرس (اکشن‌ها و فیلترها)؛ چون افزونه‌ها بدون هوک‌ها عملاً کار نمی‌کنند. سوم، آشنایی با اصول امنیت در وردپرس، شامل nonce و sanitize و escape.
اگر با PHP آشنایی کافی ندارید، راهنمای آموزش PHP از صفر نقطه‌ی شروع مناسبی است. برای درک هوک‌ها، راهنمای هوک‌های وردپرس چیست مسیر گام‌به‌گام این مکانیزم را باز کرده است. همچنین درک ساختار داخلی وردپرس که در ساختار هسته وردپرس توضیح داده‌ام، به شما کمک می‌کند که در کد افزونه، از توابع و مکانیزم‌های درست استفاده کنید.
ابزارهای مورد نیاز
برای توسعه‌ی حرفه‌ای افزونه، سه ابزار ضروری است: یک ویرایشگر کد حرفه‌ای مثل Visual Studio Code یا PHPStorm، یک محیط تست محلی مثل Local یا XAMPP، و یک ابزار اشکال‌زدایی که در وردپرس با WP_DEBUG فعال می‌شود. اگر با محیط لوکال آشنا نیستید، راهنمای توسعه وردپرس با محیط لوکال این مسیر را به‌طور کامل توضیح داده است.
گام اول: ساختار پوشه و فایل اصلی افزونه
هر افزونه‌ی وردپرس، از یک ساختار پوشه‌ی مشخص تبعیت می‌کند. نام پوشه‌ی افزونه، باید انگلیسی، کوتاه و با hyphen جدا شده باشد؛ مثلاً my-first-plugin. داخل این پوشه، حداقل یک فایل اصلی وجود دارد که همان فایل نقطه‌ی ورود افزونه است. نام این فایل می‌تواند هر چیزی باشد، اما معمولاً با نام پوشه یکسان یا نزدیک به آن انتخاب می‌شود.
ساختار پیشنهادی برای افزونه‌های حرفه‌ای
در پروژه‌های جدی، ساختاری که استفاده می‌کنم این شکل است:
my-first-plugin/
├── my-first-plugin.php (فایل اصلی)
├── includes/ (کلاس‌ها و توابع کمکی)
│ ├── class-admin.php
│ ├── class-frontend.php
│ └── class-activator.php
├── admin/ (فایل‌های مرتبط با پیشخوان)
│ ├── css/
│ ├── js/
│ └── views/
├── languages/ (فایل‌های ترجمه)
│ └── my-first-plugin-fa_IR.po
├── assets/ (فایل‌های استاتیک)
└── readme.txt (توضیحات افزونه)این ساختار، هم استاندارد است و هم مقیاس‌پذیر؛ می‌توانید در هر لحظه، کلاس‌های جدیدی به پوشه‌ی includes اضافه کنید بدون اینکه فایل اصلی افزونه شلوغ شود. اگر با استانداردهای کدنویسی وردپرس آشنایی ندارید، راهنمای استانداردهای کدنویسی وردپرس تمام این موارد را به‌تفصیل باز کرده است.
اجتناب از اسامی رزرو شده
در انتخاب نام پوشه و فایل اصلی افزونه، از اسامی رزرو شده‌ی وردپرس مثل wp- یا wordpress- در ابتدای نام پرهیز کنید. همچنین از نام‌های عمومی مثل plugin.php یا functions.php که ممکن است با سایر افزونه‌ها تعارض کنند، استفاده نکنید. تجربه‌ی من نشان می‌دهد که استفاده از یک پیشوند یکتا (مثلاً سه حرف اول نام تجاری شما)، بسیاری از مشکلات آینده را پیشگیری می‌کند.
گام دوم: هدر افزونه و استانداردهای اجباری
هدر افزونه، همان بلوک کامنتی است که در ابتدای فایل اصلی افزونه قرار می‌گیرد و وردپرس از طریق آن، اطلاعات افزونه را در پیشخوان نمایش می‌دهد. این هدر، اجباری است؛ بدون آن، وردپرس افزونه‌ی شما را نمی‌شناسد. حداقل هدر یک افزونه باید شامل نام، توضیحات، نسخه و نویسنده باشد. نمونه‌ی استاندارد این هدر:
<?php
/**
* Plugin Name: My First Plugin
* Plugin URI: https://example.com/my-first-plugin
* Description: A simple plugin to demonstrate WordPress plugin development.
* Version: 1.0.0
* Requires at least: 5.8
* Requires PHP: 7.4
* Author: Your Name
* Author URI: https://example.com
* License: GPL-2.0-or-later
* License URI: https://www.gnu.org/licenses/gpl-2.0.html
* Text Domain: my-first-plugin
* Domain Path: /languages
*/نکات مهم درباره‌ی هدر
چند نکته‌ی ظریف در نوشتن هدر، تفاوت بین افزونه‌ی آماتور و حرفه‌ای را می‌سازد. نخست، Text Domain باید با نام پوشه‌ی افزونه یکسان باشد؛ این شرط، برای ترجمه‌ی درست افزونه ضروری است. دوم، Requires at least و Requires PHP حداقل نسخه‌ی وردپرس و PHP را مشخص می‌کنند و در مخزن رسمی وردپرس نیز نمایش داده می‌شوند. سوم، لایسنس افزونه باید GPL باشد؛ چون وردپرس خودش GPL است و افزونه‌های وردپرسی نیز باید از همین لایسنس تبعیت کنند.
دلایل اهمیت این گام
در پرونده‌های متعدد دیده‌ام که توسعه‌دهنده‌ی تازه‌کار، هدر افزونه را جدی نمی‌گیرد و در مخزن رسمی وردپرس با رد شدن مواجه می‌شود. تیم بررسی مخزن، این هدر را به‌عنوان اولین فیلتر بررسی می‌کند و اگر اطلاعات ناقص یا ناسازگار باشد، افزونه را رد می‌کند. به همین دلیل، این گام به‌ظاهر ساده، در واقع اولین گام حرفه‌ای شدن افزونه است.
گام سوم: هوک فعال‌سازی و غیرفعال‌سازی
افزونه‌ی حرفه‌ای باید سه چرخه‌ی عمر مشخص داشته باشد: فعال‌سازی، اجرا و غیرفعال‌سازی. وردپرس برای هر یک از این چرخه‌ها، هوک اختصاصی دارد که در فایل اصلی افزونه ثبت می‌شود. هوک‌های فعال‌سازی و غیرفعال‌سازی با توابع register_activation_hook و register_deactivation_hook ثبت می‌شوند.
هوک فعال‌سازی
در هوک فعال‌سازی، معمولاً کارهایی مثل ساخت جداول دیتابیس، ثبت مقادیر پیش‌فرض در wp_options و پاک‌سازی کش انجام می‌شود. نمونه:
register_activation_hook( __FILE__, 'my_plugin_activate' );
function my_plugin_activate() {
// ساخت جداول، ثبت مقادیر پیش‌فرض، پاک‌سازی کش
add_option( 'my_plugin_version', '1.0.0' );
flush_rewrite_rules();
}هوک غیرفعال‌سازی
در هوک غیرفعال‌سازی، معمولاً کارهای موقتی مثل پاک‌سازی زمان‌بندی cron و flush رول‌های rewrite انجام می‌شود. نکته‌ی مهم این است که در این هوک، هرگز نباید داده‌های دیتابیس را پاک کنید؛ چون کاربر ممکن است افزونه را موقتاً غیرفعال کند و انتظار داشته باشد که داده‌هایش حفظ شود.
هوک حذف افزونه
وردپرس برای حذف کامل افزونه، فایل اختصاصی uninstall.php را پشتیبانی می‌کند. اگر این فایل در پوشه‌ی افزونه وجود داشته باشد، هنگام حذف افزونه اجرا می‌شود و می‌توانید جداول و گزینه‌های ذخیره‌شده را پاک کنید. این تفکیک بین غیرفعال‌سازی و حذف، یکی از اصول مهم افزونه‌نویسی حرفه‌ای است. جزئیات بیشتر درباره‌ی این چرخه‌ها را در راهنمای توسعه افزونه وردپرس از صفر آورده‌ام.
گام چهارم: استفاده از اکشن‌ها و فیلترها
قلب هر افزونه‌ی وردپرس، هوک‌های آن هستند. وردپرس از دو نوع هوک پشتیبانی می‌کند: اکشن‌ها که اجازه می‌دهند در نقطه‌ای از اجرا، کدی اضافه کنید، و فیلترها که اجازه می‌دهند مقدار یک متغیر یا خروجی را تغییر دهید. برای ساخت افزونه‌ی حرفه‌ای، باید با هر دو نوع هوک به‌طور fluent آشنا باشید.
افزودن اکشن سفارشی
برای اتصال به یک اکشن، از تابع add_action استفاده می‌کنید:
add_action( 'init', 'my_plugin_init' );
function my_plugin_init() {
// کد اجرایی در زمان init
}پارامتر سوم add_action مشخص می‌کند که کد شما در چه اولویتی نسبت به سایر توابع اجرا شود. اولویت پایین‌تر، اجرای زودتر. اگر با مفهوم اولویت در هوک‌ها آشنا نیستید، راهنمای اولویت هوک در وردپرس این مفهوم را باز کرده است.
افزودن فیلتر سفارشی
برای تغییر مقدار یک متغیر، از تابع add_filter استفاده می‌کنید:
add_filter( 'the_content', 'my_plugin_modify_content' );
function my_plugin_modify_content( $content ) {
// تغییر مقدار محتوا
return $content;
}نکته‌ی مهم در فیلترها این است که تابع شما باید یک مقدار را دریافت و یک مقدار بازگرداند. اگر این مقدار را بازنگردانید، مقدار اصلی از بین می‌رود. جزئیات فنی دقیق این دو نوع هوک در راهنمای تفاوت اکشن و فیلتر در وردپرس آمده است.
هوک‌های اختصاصی افزونه
افزونه‌ی حرفه‌ای خودش نیز باید هوک‌های اختصاصی داشته باشد که به سایر توسعه‌دهندگان امکان گسترش بدهد. مثلاً اگر افزونه‌ی شما یک فرم سفارش می‌سازد، می‌توانید در چند نقطه‌ی کلیدی، اکشن یا فیلتر سفارشی ثبت کنید تا افزونه‌های دیگر بتوانند به آن متصل شوند. این رویکرد، افزونه‌ی شما را از یک قطعه‌کد بسته، به یک ابزار قابل گسترش تبدیل می‌کند.
گام پنجم: ساخت صفحه‌ی تنظیمات در پیشخوان
افزونه‌ی حرفه‌ای معمولاً نیاز به یک صفحه‌ی تنظیمات در پیشخوان دارد تا کاربر بتواند پیکربندی‌های آن را مدیریت کند. وردپرس برای این کار، API استانداردی به نام Settings API ارائه می‌دهد که هم امنیت و هم یکپارچگی ظاهری را تضمین می‌کند.
افزودن منوی پیشخوان
اولین گام در ساخت صفحه‌ی تنظیمات، افزودن منو به پیشخوان است. این کار با تابع add_menu_page یا add_options_page انجام می‌شود:
add_action( 'admin_menu', 'my_plugin_add_admin_menu' );
function my_plugin_add_admin_menu() {
add_options_page(
'تنظیمات افزونه من',
'افزونه من',
'manage_options',
'my-first-plugin',
'my_plugin_settings_page'
);
}ثبت تنظیمات با Settings API
برای ثبت و ذخیره‌ی تنظیمات، از توابع register_setting، add_settings_section و add_settings_field استفاده می‌کنید. این توابع، فرآیند ذخیره‌سازی امن را تضمین می‌کنند:
add_action( 'admin_init', 'my_plugin_register_settings' );
function my_plugin_register_settings() {
register_setting( 'my_plugin_options', 'my_plugin_api_key' );
add_settings_section( 'my_plugin_main', 'تنظیمات اصلی', null, 'my-first-plugin' );
add_settings_field(
'my_plugin_api_key',
'API Key',
'my_plugin_api_key_render',
'my-first-plugin',
'my_plugin_main'
);
}استفاده از Settings API، به‌جای ذخیره‌ی مستقیم با $_POST، هم امنیت را بالا می‌برد و هم تجربه‌ی کاربری یکپارچه‌ای را با سایر افزونه‌ها فراهم می‌کند. جزئیات فنی و مثال‌های کامل این فرآیند را در راهنمای ساخت صفحه تنظیمات اختصاصی در وردپرس آورده‌ام.
گام ششم: ذخیره‌ی داده در دیتابیس
افزونه‌ها می‌توانند داده‌های خود را در سه محل ذخیره کنند: گزینه‌های وردپرس (wp_options) برای داده‌های پیکربندی، جداول اختصاصی برای داده‌های حجیم یا ساختاریافته، و post_meta برای متادیتای مرتبط با نوشته‌ها. انتخاب درست بین این سه، یکی از تصمیمات مهم در ساخت افزونه است.
ذخیره در wp_options
برای تنظیمات ساده مثل API Key یا گزینه‌های پیکربندی، wp_options انتخاب درست است. توابع add_option، get_option، update_option و delete_option تمام کارهای لازم را انجام می‌دهند.
ساخت جدول اختصاصی
اگر افزونه‌ی شما نیاز به ذخیره‌ی داده‌های ساختاریافته و حجیم دارد (مثل لاگ رویدادها، سفارش‌های اختصاصی یا نظرسنجی‌ها)، بهتر است یک جدول اختصاصی بسازید. این کار در هوک فعال‌سازی انجام می‌شود:
function my_plugin_create_table() {
global $wpdb;
$table_name = $wpdb->prefix . 'my_plugin_logs';
$charset_collate = $wpdb->get_charset_collate();
$sql = "CREATE TABLE $table_name (
id bigint(20) NOT NULL AUTO_INCREMENT,
event_type varchar(50) NOT NULL,
event_data longtext NOT NULL,
created_at datetime DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (id)
) $charset_collate;";
require_once ABSPATH . 'wp-admin/includes/upgrade.php';
dbDelta( $sql );
}استفاده از تابع dbDelta وردپرس، به‌جای کوئری خام CREATE TABLE، به شما امکان می‌دهد که در به‌روزرسانی‌های آینده‌ی افزونه، ساختار جدول را بدون از دست دادن داده تغییر دهید. این نکته، یکی از ظریف‌ترین مباحث معماری افزونه است. برای درک عمیق‌تر کار با دیتابیس در وردپرس، راهنمای بهینه‌سازی کوئری‌های وردپرس نقطه‌ی شروع مناسبی است.
گام هفتم: افزودن شورت‌کد و ویجت
بسیاری از افزونه‌ها، قابلیت‌های خود را از طریق شورت‌کد یا ویجت در اختیار کاربر قرار می‌دهند. شورت‌کد به کاربر امکان می‌دهد که در محتوای نوشته یا برگه، قابلیت افزونه را فراخوانی کند. ویجت به کاربر امکان می‌دهد که در ناحیه‌های کناری یا فوتر، قابلیت را اضافه کند.
ساخت شورت‌کد سفارشی
برای ثبت شورت‌کد، از تابع add_shortcode استفاده می‌کنید:
add_shortcode( 'my_plugin_box', 'my_plugin_box_render' );
function my_plugin_box_render( $atts ) {
$atts = shortcode_atts( array(
'title' => 'پیش‌فرض',
), $atts, 'my_plugin_box' );
return '<div class="my-box">' . esc_html( $atts['title'] ) . '</div>';
}نکته‌ی مهم در ساخت شورت‌کد، استفاده از shortcode_atts برای مدیریت پارامترهای ورودی و esc_html برای خروجی امن است. راهنمای کامل این فرآیند در ساخت شورت‌کد با کدنویسی وردپرس آمده است.
ساخت ویجت سفارشی
وردپرس برای ساخت ویجت، از کلاس WP_Widget استفاده می‌کند. برای افزونه‌های جدید، بهتر است از Block-based Widgetها استفاده کنید که در نسخه‌های جدید وردپرس استاندارد است. اگر می‌خواهید با روش کلاسیک ویجت آشنا شوید، راهنمای ساخت ویجت اختصاصی در وردپرس این مسیر را نشان می‌دهد.
گام هشتم: امنیت افزونه با nonce و sanitize
امنیت در افزونه‌نویسی، موضوعی نیست که بتوان آن را به بعد موکول کرد. تجربه‌ی من نشان می‌دهد که افزونه‌های ناامن، به‌سرعت به یک نقطه‌ی آسیب‌پذیری برای سایت تبدیل می‌شوند. سه اصل اساسی امنیت در افزونه‌ی وردپرسی عبارتند از: nonce، sanitize و escape.
Nonce برای تأیید درخواست‌ها
Nonce یک توکن امنیتی است که وردپرس برای هر درخواست تولید می‌کند و به شما امکان می‌دهد تأیید کنید که درخواست از یک کاربر مجاز آمده است. در فرم‌های پیشخوان افزونه، همیشه باید از wp_nonce_field استفاده کنید و در سمت پردازش، با wp_verify_nonce تأیید کنید:
// در فرم
wp_nonce_field( 'my_plugin_save_action', 'my_plugin_nonce' );
// در پردازش
if ( ! isset( $_POST['my_plugin_nonce'] ) ||
! wp_verify_nonce( $_POST['my_plugin_nonce'], 'my_plugin_save_action' ) ) {
return;
}Sanitize برای ورودی‌ها
قبل از ذخیره‌ی هر ورودی در دیتابیس، باید آن را با توابع sanitize پاک‌سازی کنید. توابع مختلفی مثل sanitize_text_field، sanitize_email، sanitize_url و absint برای انواع مختلف ورودی وجود دارد. انتخاب تابع درست، بسته به نوع داده‌ای است که انتظار دارید.
Escape برای خروجی‌ها
قبل از نمایش هر داده در HTML، باید آن را escape کنید تا از حملات XSS جلوگیری شود. توابع اصلی عبارتند از esc_html، esc_attr، esc_url و esc_js. قاعده‌ی طلایی این است: هر متغیری که در HTML چاپ می‌شود، باید escape شده باشد. جزئیات فنی کامل این سه اصل را در راهنمای نوشتن کد PHP امن برای وردپرس آورده‌ام.
در افزونه‌نویسی، امنیت یک لایه‌ی افزودنی نیست؛ بخشی از ساختار اصلی است. هر تابعی که ورودی می‌گیرد یا خروجی می‌دهد، باید sanitize و escape را در خود داشته باشد.
گام نهم: بین‌المللی‌سازی و پشتیبانی زبان
افزونه‌ی حرفه‌ای باید قابل ترجمه باشد. این یعنی تمام رشته‌های متنی افزونه، باید به‌جای نوشتن مستقیم، از توابع ترجمه‌ی وردپرس استفاده کنند. توابع اصلی عبارتند از: __()، _e()، esc_html__() و esc_html_e(). نمونه:
echo esc_html__( 'تنظیمات ذخیره شد', 'my-first-plugin' );پارامتر دوم این توابع، همان Text Domain است که در هدر افزونه تعریف کرده‌اید. اگر می‌خواهید افزونه‌ی شما به فارسی ترجمه شود، باید فایل .po و .mo را در پوشه‌ی languages قرار دهید و با ابزارهایی مثل Poedit آن را ترجمه کنید. این فرآیند را می‌توانید در راهنمای آماده‌سازی قالب برای فارسی نیز مطالعه کنید، چون همان اصول در افزونه‌ها هم برقرار است.
گام دهم: بارگذاری CSS و JavaScript
افزونه‌ی حرفه‌ای، CSS و JavaScript خود را با استفاده از توابع استاندارد wp_enqueue_style و wp_enqueue_script بارگذاری می‌کند، نه با تگ‌های مستقیم HTML. این رویکرد، تضمین می‌کند که فایل‌های شما به‌درستی در صف بارگذاری قرار گیرند و با سایر افزونه‌ها و قالب تداخل نکنند.
بارگذاری در فرانت‌اند
add_action( 'wp_enqueue_scripts', 'my_plugin_enqueue_assets' );
function my_plugin_enqueue_assets() {
wp_enqueue_style( 'my-plugin-style', plugin_dir_url( __FILE__ ) . 'assets/style.css', array(), '1.0.0' );
wp_enqueue_script( 'my-plugin-script', plugin_dir_url( __FILE__ ) . 'assets/script.js', array( 'jquery' ), '1.0.0', true );
}بارگذاری شرطی در صفحات مشخص
برای بهینه‌سازی عملکرد، فایل‌های CSS و JS افزونه را فقط در صفحاتی بارگذاری کنید که نیاز دارند. مثلاً اگر افزونه‌ی شما فقط در صفحه‌ی تنظیمات پیشخوان کار می‌کند، نباید فایل‌های آن در فرانت‌اند بارگذاری شوند:
add_action( 'admin_enqueue_scripts', 'my_plugin_admin_assets' );
function my_plugin_admin_assets( $hook ) {
if ( 'settings_page_my-first-plugin' !== $hook ) {
return;
}
wp_enqueue_style( 'my-plugin-admin', plugin_dir_url( __FILE__ ) . 'admin/css/style.css', array(), '1.0.0' );
}این نکته، یکی از ظریف‌ترین تفاوت‌ها بین افزونه‌ی آماتور و حرفه‌ای است. تجربه‌ی من در پروژه‌های بهینه‌سازی سرعت نشان می‌دهد که بارگذاری بی‌هدف فایل‌ها، یکی از عوامل اصلی کندی سایت‌های وردپرسی است. جزئیات بیشتر درباره‌ی این فرآیند را در راهنمای تأثیر افزونه‌ها بر سرعت سایت آورده‌ام.
گام یازدهم: تست افزونه در محیط staging
پیش از آنکه افزونه‌ی خود را روی سایت زنده فعال کنید، باید آن را در یک محیط staging کامل تست کنید. تجربه‌ی من این است که در این گام، بیش از ۸۰ درصد باگ‌های پنهان آشکار می‌شوند. حداقل مواردی که باید در تست بررسی شوند عبارتند از: نصب و فعال‌سازی در وردپرس خام، تعارض با افزونه‌های محبوب، تعارض با قالب‌های مختلف، رفتار افزونه در نسخه‌های مختلف PHP، و امنیت در برابر حملات XSS و CSRF.
تست تعارض با افزونه‌ها و قالب‌های محبوب
افزونه‌ی حرفه‌ای باید با قالب‌ها و افزونه‌های محبوب سازگار باشد. حداقل باید افزونه‌ی خود را با WooCommerce، Elementor، Yoast SEO و چند قالب محبوب تست کنید. اگر با تعارضی روبه‌رو شدید، باید در همان مرحله رفع شود، نه پس از انتشار. جزئیات فنی این تست را در راهنمای بررسی سازگاری قالب و افزونه‌ها آورده‌ام.
ابزارهای تست حرفه‌ای
برای تست عمیق افزونه، سه ابزار ضروری وجود دارد: افزونه‌ی Query Monitor برای بررسی کوئری‌ها و هوک‌ها، افزونه‌ی Debug Bar برای بررسی خطاهای PHP و ابزار Theme Check برای اطمینان از رعایت استانداردهای وردپرس. تجربه‌ی من نشان می‌دهد که این سه ابزار، در کنار هم، تصویر کاملی از کیفیت افزونه‌ی شما می‌دهند.
گام دوازدهم: انتشار در مخزن رسمی وردپرس
یکی از بزرگ‌ترین مزیت‌های افزونه‌نویسی برای وردپرس، امکان انتشار در مخزن رسمی است. مخزن رسمی وردپرس روی wordpress.org/plugins میزبانی می‌شود و به‌طور خودکار در پیشخوان میلیون‌ها سایت وردپرسی قابل جستجو است. فرآیند انتشار در این مخزن، چند گام مشخص دارد.
گام‌های ارسال افزونه به مخزن
نخست، باید یک حساب کاربری روی wordpress.org بسازید. سپس از طریق صفحه‌ی «Add Your Plugin»، درخواست انتشار ثبت کنید. تیم بررسی مخزن، افزونه‌ی شما را در چند مرحله بررسی می‌کند: بررسی کد، رعایت استانداردها، امنیت، و مطابقت با مجوز GPL. زمان بررسی معمولاً بین دو تا هشت هفته است.
نکات مهم برای قبولی در مخزن
سه نکته‌ی مهم برای قبولی در مخزن وردپرس وجود دارد. اول، رعایت کامل استانداردهای کدنویسی وردپرس. دوم، نداشتن هیچ نوع درخواست ارتقای پولی یا تبلیغ در نسخه‌ی رایگان. سوم، ارائه‌ی فایل readme.txt با ساختار استاندارد. اگر می‌خواهید مدل کسب‌وکار Freemium داشته باشید (نسخه‌ی رایگان و پولی)، حتماً باید نسخه‌ی مخزن کامل و مستقل باشد، نه نسخه‌ی محدودشده. جزئیات فنی این فرآیند در راهنمای توسعه افزونه وردپرس از صفر آمده است.
SVN و به‌روزرسانی پس از انتشار
پس از پذیرش افزونه، به یک مخزن SVN دسترسی خواهید داشت که از طریق آن، نسخه‌های جدید را منتشر می‌کنید. تجربه‌ی من این است که توسعه‌دهندگان تازه‌کار، SVN را پیچیده می‌یابند ولی با تمرین چند نسخه، این فرآیند ساده می‌شود. اگر می‌خواهید از Git برای توسعه استفاده کنید و به‌طور موازی با SVN مخزن منتشر کنید، ابزارهایی مثل git-svn یا سرویس‌های واسط وجود دارند.
گام سیزدهم: نگهداری و به‌روزرسانی افزونه
انتشار افزونه، پایان کار نیست؛ شروع مرحله‌ی نگهداری است. تجربه‌ی من نشان می‌دهد که افزونه‌های موفق، آن‌هایی هستند که در طول سال‌ها به‌طور فعال به‌روزرسانی می‌شوند. این نگهداری، سه لایه‌ی اصلی دارد.
به‌روزرسانی به‌موقع برای سازگاری
وردپرس هر چند ماه یک نسخه‌ی جدید منتشر می‌کند. افزونه‌ی شما باید با هر نسخه‌ی جدید سازگار باشد. همچنین، اگر افزونه‌ی شما با افزونه‌های دیگر کار می‌کند، باید سازگاری با نسخه‌های جدید آن‌ها را حفظ کنید. این فرآیند، نیازمند پایش مستمر است.
پاسخ به بازخورد کاربران
کاربران افزونه، در بخش پشتیبانی مخزن رسمی، سؤال می‌پرسند و باگ گزارش می‌دهند. تجربه‌ی من این است که پاسخ سریع و حرفه‌ای به این بازخوردها، هم کیفیت افزونه را بالا می‌برد و هم امتیاز افزونه را در مخزن حفظ می‌کند. افزونه‌هایی که پشتیبانی ضعیف دارند، به‌سرعت در رتبه‌بندی مخزن پایین می‌آیند.
پایش امنیت و وصله‌گذاری
امنیت افزونه، موضوعی نیست که یک بار برای همیشه حل شود. با گذشت زمان، حفره‌های امنیتی جدیدی کشف می‌شوند و افزونه‌ی شما نیز ممکن است در معرض آن‌ها باشد. پایش مستمر و به‌روزرسانی سریع، یکی از مسئولیت‌های اصلی نگهداری افزونه است.
پرسش‌های پرتکرار درباره ساخت افزونه وردپرس
در این بخش، پاسخ کوتاه و فنی به پرتکرارترین پرسش‌های این حوزه را جمع کرده‌ام؛ ساختاری که هم برای مخاطب شفاف است و هم مسیر دسترسی سریع‌تر به پاسخ را برای موتورهای پاسخ‌ده فراهم می‌کند.
آیا برای ساخت افزونه وردپرس باید کلاس و شی‌گرایی بلد باشم؟
برای افزونه‌های ساده، خیر؛ می‌توانید با توابع ساده شروع کنید. اما برای افزونه‌های حرفه‌ای و مقیاس‌پذیر، آشنایی با شی‌گرایی ضروری است. الگوی کلاس و فضای نام (namespace)، هم ساختار کد را تمیزتر می‌کند و هم از تعارض با سایر افزونه‌ها جلوگیری می‌کند. توصیه‌ی من این است که از همان ابتدا، حتی برای افزونه‌های کوچک، ساختار شی‌گرا را تمرین کنید.
تفاوت بین فایل functions.php قالب و افزونه‌ی اختصاصی چیست؟
هر دو می‌توانند کد PHP را در سایت اجرا کنند، اما تفاوت‌های اساسی دارند. کد در functions.php قالب، به قالب وابسته است؛ اگر قالب عوض شود، آن کد از بین می‌رود. افزونه‌ی اختصاصی، مستقل از قالب است و در هر قالبی کار می‌کند. همچنین، افزونه به‌طور مستقل قابل فعال و غیرفعال شدن است، ولی کد functions.php چنین قابلیتی ندارد. به همین دلیل، هر کدی که به «منطق» مربوط است، باید در افزونه باشد، نه در قالب.
چگونه افزونه‌ی خود را در مخزن رسمی وردپرس منتشر کنم؟
سه گام اصلی: نخست، افزونه را با استانداردهای وردپرس بنویسید و به‌طور کامل در محیط staging تست کنید. دوم، در wordpress.org ثبت‌نام کنید و از طریق صفحه‌ی Add Your Plugin، درخواست انتشار ثبت کنید. سوم، پس از پذیرش، با SVN نسخه‌ها را منتشر کنید. فرآیند بررسی معمولاً بین دو تا هشت هفته طول می‌کشد.
آیا افزونه‌ی من می‌تواند با سایر افزونه‌ها تعارض داشته باشد؟
بله، به‌ویژه اگر نام توابع یا کلاس‌ها را با پیشوند یکتا نام‌گذاری نکنید. یکی از اصول اصلی افزونه‌نویسی، استفاده از پیشوند یکتا برای تمام توابع، کلاس‌ها و ثابت‌هاست. اگر افزونه‌ای با پیشوند مشترک نام‌گذاری شود، احتمال تعارض با سایر افزونه‌ها وجود دارد. استفاده از namespace در PHP 5.3+، رویکرد حرفه‌ای‌تری است.
چگونه می‌توانم افزونه‌ی خود را به فارسی ترجمه کنم؟
برای ترجمه، ابتدا باید تمام رشته‌های متنی را با توابع ترجمه‌ی وردپرس نوشته باشید. سپس با ابزارهایی مثل Poedit، فایل .po را بسازید و ترجمه کنید. در نهایت، فایل .po و .mo را در پوشه‌ی languages قرار دهید. این فرآیند، امکان ترجمه‌ی افزونه به زبان‌های دیگر را هم فراهم می‌کند.
آیا افزونه‌ی من می‌تواند درآمد داشته باشد؟
بله. سه مدل رایج برای درآمدزایی از افزونه وجود دارد: مدل Freemium (نسخه‌ی رایگان در مخزن رسمی، نسخه‌ی پولی با امکانات بیشتر)، مدل پرداخت مستقیم از سایت خودتان، و مدل اشتراک سالانه. تجربه‌ی من این است که مدل Freemium، اگر به‌درستی پیاده شود، هم رشد سریع‌تر مخاطب دارد و هم درآمد پایدار. نکته‌ی کلیدی این است که نسخه‌ی رایگان باید کامل و مستقل باشد، نه نسخه‌ی محدودشده.
چگونه از افزونه‌ی خود در برابر حملات XSS و CSRF محافظت کنم؟
سه اصل اساسی: نخست، تمام ورودی‌ها را با توابع sanitize پاک‌سازی کنید. دوم، تمام خروجی‌ها را با توابع escape آماده کنید. سوم، تمام فرم‌ها را با nonce محافظت کنید. این سه اصل، بیش از ۹۰ درصد حملات رایج را دفع می‌کند. جزئیات فنی کامل را در راهنمای نوشتن کد PHP امن برای وردپرس آورده‌ام.
آیا افزونه‌ی من باید از کلاس‌ها و namespace استفاده کند؟
برای پروژه‌های جدی، بله. استفاده از کلاس‌ها و namespace، هم ساختار کد را تمیزتر می‌کند و هم از تعارض با سایر افزونه‌ها جلوگیری می‌کند. تجربه‌ی من این است که افزونه‌های حرفه‌ای، حتی اگر ساده باشند، از همان ابتدا با ساختار شی‌گرا نوشته می‌شوند تا در آینده گسترش‌پذیرتر باشند.
ایستگاه پایان مسیر: چه چیزی افزونه‌ی شما را حرفه‌ای می‌کند
ساخت افزونه وردپرس، یک مهارت فنی است، اما یک مهارت معماری هم هست. تجربه‌ی من در نوشتن ده‌ها افزونه‌ی اختصاصی نشان می‌دهد که افزونه‌ی حرفه‌ای، سه ویژگی مشترک دارد: کد تمیز با ساختار استاندارد، امنیت پیش‌فرض در تمام لایه‌ها، و قابلیت گسترش و نگهداری آسان. اگر این سه ویژگی را از همان ابتدا در ذهن داشته باشید، افزونه‌ی شما در سال دوم عمرش نیز به‌سرعت توسعه‌پذیر و قابل نگهداری خواهد بود.
اگر امروز می‌خواهید اولین افزونه‌ی خود را بنویسید، توصیه‌ی عملی من این است: با یک افزونه‌ی ساده شروع کنید، اما آن را با تمام استانداردها بنویسید — حتی اگر کارکردش کوچک است. سپس با هر پروژه، یک لایه به مهارت خود اضافه کنید: از ساخت صفحه‌ی تنظیمات تا ذخیره‌سازی در دیتابیس اختصاصی، از ساخت شورت‌کد تا انتشار در مخزن رسمی. این مسیر تدریجی، شما را در چند ماه به یک توسعه‌دهنده‌ی حرفه‌ای افزونه تبدیل می‌کند. 🧩
اگر در مسیر ساخت افزونه‌ی خودتان به چالشی برخوردید — مثلاً تعارض با افزونه‌ای دیگر، رفتار عجیب در نسخه‌های خاص وردپرس، یا رد شدن در بررسی مخزن رسمی — تجربه‌تان را در دیدگاه‌ها بنویسید. پرونده‌های واقعی، همیشه ارزشمندتر از توصیه‌های کلی برای خواننده‌ی بعدی هستند. 🛠️
نویسنده در وردپرس کار.