انتشار بلاک سفارشی در مخزن وردپرس چطور انجام می‌شود؟

انتشار بلاک سفارشی در مخزن وردپرس یک فرآیند چندمرحله‌ای است که از آماده‌سازی ساختار افزونه و رعایت استانداردهای کدنویسی آغاز می‌شود و با ارسال به SVN (Subversion) و عبور از فرآیند بازبینی تیم Plugin Review به انتشار عمومی می‌رسد. هر بلاک سفارشی که با `registerBlockType` ساخته می‌شود، تا زمانی که در مخزن رسمی WordPress.org منتشر نشود، فقط در سایت توسعه‌دهنده قابل استفاده است و میلیون‌ها کاربر وردپرس به آن دسترسی ندارند. انتشار در مخزن، نه فقط یک اقدام توزیعی، بلکه یک تعهد مهندسی است: کد باید امن، سازگار، قابل به‌روزرسانی و مطابق با GPL (General Public License) باشد. این مقاله چارچوب کامل انتشار بلاک سفارشی — از آماده‌سازی Metadata و block.json تا SVN، Readme.txt، و فرآیند بازبینی — را با تمرکز بر جزئیات فنی ارائه می‌دهد.

اولین بلاک سفارشی که برای انتشار در مخزن آماده کردم، در همان مرحله اول بازبینی رد شد. دلیلش نه یک باگ امنیتی، بلکه یک جزئیات به‌ظاهر ساده بود: نام‌گذاری Namespace (فضای نام) با پیشوند نادرست. تجربه‌ای که نشان داد انتشار در WordPress.org بیش از آنکه یک اقدام فنی باشد، یک تعهد به استانداردها و انضباط مهندسی است.

چرا انتشار بلاک در مخزن وردپرس اهمیت دارد؟

مخزن رسمی وردپرس (WordPress.org Plugin Directory) بیش از ۶۰,۰۰۰ افزونه فعال دارد و به‌عنوان بزرگ‌ترین اکوسیستم افزونه‌های وب در جهان شناخته می‌شود. بلاک‌های سفارشی که در این مخزن منتشر می‌شوند، از چند مزیت کلیدی بهره‌مند می‌شوند: دسترسی به میلیون‌ها نصب‌کننده وردپرس، به‌روزرسانی خودکار از طریق پنل مدیریت، پشتیبانی از فرآیند ترجمه در translate.wordpress.org، و اعتبار فنی ناشی از عبور از بازبینی تیم Plugin Review.

از منظر معماری، انتشار در مخزن رسمی یک تعهد به سه اصل است: امنیت (کد باید در برابر XSS، CSRF، SQL Injection و سایر حملات مقاوم باشد)، سازگاری (باید با نسخه‌های مختلف وردپرس، PHP و سایر افزونه‌های محبوب کار کند)، و نگهداشت‌پذیری (کد باید قابل به‌روزرسانی، خوانا و مستند باشد). اگر با راهنمای توسعه افزونه وردپرس از صفر آشنا شده باشید، می‌دانید که این سه اصل، پایه تمام توسعه حرفه‌ای هستند.

«انتشار در مخزن وردپرس، امضای مهندسی شماست: کدی که با نام شما منتشر می‌شود، نماینده سطح فنی و انضباط شماست.»

مزیت دیگر، به‌روزرسانی خودکار است. وقتی افزونه شما در مخزن رسمی باشد، وردپرس به‌طور خودکار به کاربران اطلاع می‌دهد که نسخه جدید در دسترس است. این مکانیزم، مبتنی بر SVN (Subversion) و API مخزن رسمی است. بدون این یکپارچگی، هر به‌روزرسانی نیازمند توزیع دستی و اطلاع‌رسانی جداگانه است. اگر با راهنمای نصب و فعال‌سازی افزونه وردپرس آشنا باشید، می‌دانید که کاربران وردپرس به به‌روزرسانی خودکار عادت کرده‌اند و افزونه‌های خارج از مخزن، در معرض بی‌توجهی قرار می‌گیرند.

مزیت سوم، اعتبار و اعتماد است. کاربران وردپرس به افزونه‌هایی که از مخزن رسمی نصب می‌شوند، اعتماد بیشتری دارند. این اعتماد ناشی از چند عامل است: عبور از بازبینی امنیتی، امکان گزارش مشکلات به تیم پشتیبانی وردپرس، و شفافیت کد از طریق SVN. اگر با روش دانلود ایمن افزونه وردپرس آشنا باشید، می‌دانید که مخزن رسمی یکی از معدود منابع قابل اعتماد برای دریافت افزونه است.

پیش‌نیازها و آماده‌سازی اولیه

قبل از شروع فرآیند انتشار، چند پیش‌نیاز باید فراهم شود:

حساب کاربری WordPress.org. برای ارسال افزونه، باید یک حساب کاربری در WordPress.org داشته باشید. این حساب، همان حسابی است که برای مشارکت در انجمن‌ها و ترجمه استفاده می‌شود. پس از ساخت حساب، باید درخواست ارسال افزونه را از طریق فرم مخصوص ثبت کنید.

گواهی GPL. تمام کدهای ارسالی به مخزن باید تحت مجوز GPLv2 یا بالاتر منتشر شوند. این یعنی نمی‌توانید کدی با مجوز MIT، Apache یا Proprietary در مخزن رسمی منتشر کنید. مجوز GPL در فایل readme.txt و در هدر افزونه باید صریحاً ذکر شود. اگر با استانداردهای کدنویسی وردپرس آشنا باشید، می‌دانید که GPL بخشی جدایی‌ناپذیر از فلسفه وردپرس است.

ساختار افزونه. بلاک سفارشی باید در قالب یک افزونه وردپرس سازماندهی شود. بلاک‌ها نمی‌توانند به‌تنهایی در مخزن منتشر شوند؛ آن‌ها بخشی از یک افزونه هستند. اگر با ساختار فایل‌های یک افزونه استاندارد وردپرس آشنا شده باشید، این ساختار برای شما آشناست.

نسخه PHP و وردپرس. بلاک سفارشی باید حداقل با PHP 7.4 و وردپرس ۵.۸ سازگار باشد. در فایل readme.txt باید مشخص کنید که افزونه با چه نسخه‌هایی سازگار است. اگر با بررسی سازگاری افزونه‌های وردپرس آشنا باشید، می‌دانید که این موضوع یکی از معیارهای اصلی بازبینی است.

تست کامل. قبل از ارسال، افزونه باید در محیط‌های مختلف تست شود: PHP 7.4، 8.0، 8.1، 8.2، و 8.3؛ وردپرس 5.8، 6.0، 6.4 و آخرین نسخه؛ و با افزونه‌های محبوب مثل WooCommerce، Elementor و Yoast SEO. اگر با تست بلاک‌های وردپرس با Jest و Playwright آشنا شده باشید، می‌دانید که این سطح از تست، پیش‌نیاز انتشار حرفه‌ای است.

ساختار افزونه و فایل‌های ضروری

ساختار یک افزونه بلاک سفارشی باید از الگوی استاندارد پیروی کند. ساختار پیشنهادی به این شکل است:

my-custom-block/
├── my-custom-block.php          # فایل اصلی افزونه
├── readme.txt                   # فایل Readme مخزن
├── LICENSE                       # مجوز GPL
├── package.json                  # وابستگی‌های npm
├── src/
│   ├── index.js                  # نقطه ورود بلاک
│   ├── edit.js                   # کامپوننت ویرایشگر
│   ├── save.js                   # کامپوننت ذخیره‌سازی
│   └── block.json                # Metadata بلاک
├── build/                        # خروجی Build
│   ├── index.js
│   ├── index.asset.php
│   └── style-index.css
├── includes/                     # کدهای PHP
│   ├── class-block-registrar.php
│   └── class-rest-controller.php
├── languages/                    # فایل‌های ترجمه
└── assets/                       # تصاویر و فایل‌های استاتیک

فایل اصلی افزونه (my-custom-block.php) باید شامل هدر استاندارد وردپرس باشد:

<?php
/**
 * Plugin Name:       My Custom Block
 * Plugin URI:        https://example.com/my-custom-block
 * Description:       A custom Gutenberg block for displaying prices.
 * 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-custom-block
 * Domain Path:       /languages
 *
 * @package MyCustomBlock
 */

if ( ! defined( 'ABSPATH' ) ) {
    exit;
}

require_once __DIR__ . '/includes/class-block-registrar.php';

function my_custom_block_init() {
    register_block_type( __DIR__ . '/build' );
}
add_action( 'init', 'my_custom_block_init' );

این هدر، اطلاعات حیاتی افزونه را در اختیار وردپرس قرار می‌دهد. اگر با مراحل ساخت افزونه اختصاصی وردپرس آشنا شده باشید، این ساختار برای شما آشناست. نکته مهم این است که Text Domain باید با اسلاگ افزونه در مخزن یکسان باشد تا ترجمه‌ها به‌درستی بارگذاری شوند.

نوشتن readme.txt استاندارد

فایل readme.txt یکی از مهم‌ترین فایل‌های یک افزونه است. این فایل، صفحه افزونه را در مخزن رسمی می‌سازد و شامل اطلاعاتی مثل توضیحات، نصب، تغییرات، و پرسش‌های پرتکرار است. فرمت این فایل، استاندارد Markdown است و باید دقیقاً از الگوی مخزن پیروی کند:

=== My Custom Block ===
Contributors: yourusername
Tags: block, gutenberg, price
Requires at least: 5.8
Tested up to: 6.4
Requires PHP: 7.4
Stable tag: 1.0.0
License: GPLv2 or later
License URI: https://www.gnu.org/licenses/gpl-2.0.html

A custom Gutenberg block for displaying prices with currency formatting.

== Description ==

My Custom Block adds a price block to the Gutenberg editor.
Features include:

* Currency formatting
* Multiple currency support
* Responsive design
* Translation-ready

== Installation ==

1. Upload the plugin files to `/wp-content/plugins/my-custom-block/`
2. Activate the plugin through the Plugins screen
3. Insert the block in the Gutenberg editor

== Frequently Asked Questions ==

= Does this block support multiple currencies? =

Yes, it supports USD, EUR, GBP, and more.

== Changelog ==

= 1.0.0 =
* Initial release

== Upgrade Notice ==

= 1.0.0 =
Initial release.

نکات مهم در نوشتن readme.txt:

نام افزونه در خط اول باید با نام پوشه SVN یکسان باشد.
مقدار Contributors باید نام کاربری شما در WordPress.org باشد.
Stable tag باید با آخرین نسخه در پوشه tags/ SVN مطابقت داشته باشد.
بخش Changelog باید برای هر نسخه توضیح تغییرات داشته باشد.
تگ‌ها باید حداکثر ۵ عدد باشند و از فهرست مجاز انتخاب شوند.

اگر با ساخت افزونه حرفه‌ای وردپرس آشنا شده باشید، می‌دانید که readme.txt نه یک فایل جانبی، بلکه بخشی جدایی‌ناپذیر از تجربه کاربری افزونه است. کاربران قبل از نصب، این فایل را می‌خوانند و بر اساس آن تصمیم می‌گیرند.

block.json و Metadata بلاک

فایل block.json استاندارد رسمی برای تعریف Metadata بلاک است که از وردپرس ۵.۸ به بعد پشتیبانی می‌شود. این فایل، جایگزین فراخوانی مستقیم registerBlockType با تمام پارامترها می‌شود و مزایای متعددی دارد:

{
  "$schema": "https://schemas.wp.org/trunk/block.json",
  "apiVersion": 3,
  "name": "my-plugin/price-block",
  "version": "1.0.0",
  "title": "Price Block",
  "category": "widgets",
  "icon": "money-alt",
  "description": "Display a formatted price with currency.",
  "keywords": [ "price", "currency", "money" ],
  "supports": {
    "html": false,
    "align": true,
    "color": {
      "text": true,
      "background": true
    }
  },
  "attributes": {
    "amount": {
      "type": "number",
      "default": 0
    },
    "currency": {
      "type": "string",
      "default": "USD"
    }
  },
  "textdomain": "my-custom-block",
  "editorScript": "file:./index.js",
  "editorStyle": "file:./index.css",
  "style": "file:./style-index.css",
  "render": "file:./render.php"
}

مزایای استفاده از block.json:

ثبت سمت سرور: بلاک به‌صورت خودکار در PHP ثبت می‌شود، بدون نیاز به فراخوانی جداگانه.
کارایی بهتر: وردپرس فقط بلاک‌هایی را بارگذاری می‌کند که در صفحه استفاده شده‌اند.
سازگاری با ابزارها: ابزارهای توسعه مثل @wordpress/scripts این فایل را به‌عنوان منبع اصلی می‌شناسند.
Metadata متمرکز: تمام تنظیمات بلاک در یک فایل واحد تعریف می‌شوند.

پارامتر apiVersion: 3 نسخه سوم API بلاک را فعال می‌کند که از وردپرس ۶.۳ به بعد پشتیبانی می‌شود. این نسخه، امکان استفاده از iframe برای جداسازی استایل ویرایشگر و فرانت‌اند را فراهم می‌کند. اگر با ساخت بلاک سفارشی گوتنبرگ از صفر آشنا شده باشید، می‌دانید که این پارامتر یکی از مهم‌ترین تصمیمات در ساخت بلاک است.

پارامتر render به فایل render.php اشاره می‌کند که برای بلاک‌های داینامیک استفاده می‌شود. اگر بلاک شما نیاز به رندر سمت سرور دارد (مثلاً برای دریافت داده‌های لحظه‌ای)، این پارامتر حیاتی است. در این حالت، فایل save.js نباید تعریف شود.

استانداردهای کدنویسی و امنیت

استانداردهای کدنویسی وردپرس (WordPress Coding Standards) مجموعه‌ای از قواعد برای نوشتن کد PHP، JavaScript، CSS و HTML است که خوانایی، سازگاری و امنیت را تضمین می‌کند. رعایت این استانداردها در فرآیند بازبینی مخزن، یک الزام است. اگر با استفاده از استانداردهای کدنویسی وردپرس در پروژه‌ها آشنا شده باشید، این قواعد برای شما آشناست.

مهم‌ترین نکات امنیتی که در بازبینی مخزن بررسی می‌شوند:

Sanitization (پاک‌سازی ورودی). تمام داده‌های ورودی کاربر باید با توابع مناسب پاک‌سازی شوند:

$title   = sanitize_text_field( $_POST['title'] );
$content = wp_kses_post( $_POST['content'] );
$email   = sanitize_email( $_POST['email'] );
$url     = esc_url_raw( $_POST['url'] );

Escaping (فرار دادن خروجی). تمام داده‌های خروجی باید Escaped شوند:

echo esc_html( $title );
echo esc_attr( $class );
echo esc_url( $link );
echo wp_kses_post( $content );

Nonce Verification. تمام فرم‌ها و درخواست‌های AJAX باید Nonce داشته باشند:

if ( ! wp_verify_nonce( $_POST['nonce'], 'my_action' ) ) {
    wp_die( 'Security check failed' );
}

Capability Checks. تمام عملیات مدیریتی باید سطح دسترسی کاربر را بررسی کنند:

if ( ! current_user_can( 'edit_posts' ) ) {
    wp_die( 'Insufficient permissions' );
}

Direct File Access. تمام فایل‌های PHP باید از دسترسی مستقیم محافظت شوند:

if ( ! defined( 'ABSPATH' ) ) {
    exit;
}

Prefixing. تمام توابع، کلاس‌ها و متغیرهای سراسری باید با پیشوند یکتا (معمولاً نام افزونه) تعریف شوند تا با سایر افزونه‌ها تداخل نکنند:

function my_custom_block_render( $attributes ) { /* ... */ }
class My_Custom_Block_Registrar { /* ... */ }

«بازبینی مخزن، به‌دنبال باگ نیست؛ به‌دنبال الگوهای نادرست است. کدی که در یک نقطه امن باشد اما در ده نقطه دیگر امن نباشد، رد می‌شود.»

برای بررسی خودکار استانداردها، از ابزار PHP_CodeSniffer با استاندارد WordPress استفاده کنید:

composer require --dev wp-coding-standards/wpcs
vendor/bin/phpcs --standard=WordPress my-custom-block.php

این ابزار، خطاهای استاندارد را قبل از ارسال به مخزن کشف می‌کند و از رد شدن در بازبینی جلوگیری می‌نماید.

فرآیند Build و بهینه‌سازی خروجی

بلاک‌های سفارشی معمولاً با ابزارهایی مثل @wordpress/scripts ساخته می‌شوند که از Webpack برای Build استفاده می‌کنند. قبل از انتشار، باید فرآیند Build اجرا شود تا خروجی بهینه در پوشه build/ تولید گردد:

npm install
npm run build

خروجی Build شامل چند فایل است:

index.js: کد JavaScript بلاک (minified)
index.asset.php: فایل وابستگی‌ها (Dependencies)
index.css: استایل ویرایشگر
style-index.css: استایل فرانت‌اند
render.php: فایل رندر سمت سرور (اگر وجود داشته باشد)

فایل index.asset.php به‌صورت خودکار توسط @wordpress/scripts تولید می‌شود و شامل آرایه‌ای از وابستگی‌ها (مثل wp-blocks، wp-element، wp-i18n) و نسخه (Version Hash) است. وردپرس از این فایل برای بارگذاری بهینه اسکریپت‌ها استفاده می‌کند.

نکته مهم در فرآیند Build، حذف فایل‌های غیرضروری از خروجی نهایی است. فایل‌های .map (Source Map)، پوشه node_modules/ و فایل‌های .git/ نباید در نسخه نهایی افزونه باشند. برای این کار، از فایل .distignore استفاده کنید:

/.git
/.github
/node_modules
/tests
/.eslintrc.js
/.stylelintrc.js
/phpunit.xml
/playwright.config.js
/src
/package.json
/package-lock.json
/composer.json
/composer.lock
/.distignore
/README.md

این فایل، به ابزارهایی مثل wp-scripts plugin-zip می‌گوید که چه فایل‌هایی را در بسته نهایی حذف کنند. اگر با اشتباهات رایج هنگام نصب افزونه وردپرس آشنا شده باشید، می‌دانید که حجم بسته نهایی یکی از معیارهای مهم کیفیت است.

گردش کار SVN و ارسال به مخزن

مخزن وردپرس از SVN (Subversion) برای مدیریت نسخه‌ها استفاده می‌کند. SVN یک سیستم کنترل نسخه متمرکز است که با Git تفاوت‌های اساسی دارد. درک این تفاوت‌ها برای انتشار موفق حیاتی است.

ساختار SVN مخزن به این شکل است:

my-custom-block/
├── trunk/          # نسخه در حال توسعه
├── tags/           # نسخه‌های منتشرشده
│   ├── 1.0.0/
│   └── 1.0.1/
├── branches/       # شاخه‌های توسعه
└── assets/         # تصاویر و بنرهای مخزن

پوشه trunk/ نسخه اصلی افزونه را نگه می‌دارد. پوشه tags/ نسخه‌های منتشرشده را به‌صورت Snapshot ذخیره می‌کند. پوشه assets/ تصاویر و بنرهای صفحه افزونه در مخزن را نگه می‌دارد (نه فایل‌های افزونه). اگر با مراحل ساخت افزونه اختصاصی وردپرس آشنا شده باشید، این ساختار برای شما آشناست.

گام اول: دریافت SVN Checkout

پس از تأیید درخواست ارسال افزونه، یک ایمیل با URL SVN مخزن اختصاصی دریافت می‌کنید:

svn checkout https://plugins.svn.wordpress.org/my-custom-block/ my-custom-block-svn

این دستور، پوشه‌های trunk/، tags/، branches/ و assets/ را در سیستم شما کپی می‌کند.

گام دوم: کپی فایل‌ها به trunk

فایل‌های افزونه (نه پوشه node_modules/، نه src/) را به trunk/ کپی کنید:

cp -r build/* my-custom-block-svn/trunk/
cp my-custom-block.php my-custom-block-svn/trunk/
cp readme.txt my-custom-block-svn/trunk/
cp LICENSE my-custom-block-svn/trunk/
cp -r includes/ my-custom-block-svn/trunk/
cp -r languages/ my-custom-block-svn/trunk/

گام سوم: افزودن فایل‌های جدید

فایل‌های جدید باید با svn add اضافه شوند:

cd my-custom-block-svn
svn add trunk/* --force

گزینه --force باعث می‌شود که فایل‌های موجود در SVN دوباره اضافه نشوند و فقط فایل‌های جدید Add شوند.

گام چهارم: Commit اولیه

پس از افزودن فایل‌ها، Commit اولیه انجام می‌شود:

svn commit -m "Initial release of My Custom Block v1.0.0"

این Commit، فایل‌ها را به مخزن ارسال می‌کند. توجه داشته باشید که Commit اول ممکن است چند دقیقه طول بکشد، چون فایل‌ها به سرور مخزن آپلود می‌شوند.

گام پنجم: ساخت Tag نسخه

پس از Commit در trunk، باید یک Tag برای نسخه بسازید:

svn copy trunk/ tags/1.0.0/
svn commit -m "Tag version 1.0.0"

این دستور، یک کپی از trunk در پوشه tags/1.0.0/ ایجاد می‌کند. Tagها در SVN، برخلاف Git، شاخه‌های فیزیکی هستند و نه اشاره‌گر. این یعنی هر Tag، یک کپی کامل از فایل‌هاست و فضای دیسک را افزایش می‌دهد.

گام ششم: آپلود بنر و آیکن

بنر و آیکن افزونه در پوشه assets/ قرار می‌گیرند:

cp icon-128x128.png my-custom-block-svn/assets/
cp icon-256x256.png my-custom-block-svn/assets/
cp banner-772x250.png my-custom-block-svn/assets/
cp banner-1544x500.png my-custom-block-svn/assets/
cd my-custom-block-svn
svn add assets/* --force
svn commit -m "Add plugin assets"

اندازه‌های استاندارد برای تصاویر مخزن:

نوع	ابعاد	فرمت
آیکن کوچک	128×128	PNG
آیکن بزرگ	256×256	PNG
بنر کوچک	772×250	PNG یا JPG
بنر بزرگ	1544×500	PNG یا JPG
اسکرین‌شات	حداکثر ۱۲۸۰ عرض	PNG یا JPG

گام هفتم: به‌روزرسانی‌های آینده

برای هر نسخه جدید، مراحل زیر تکرار می‌شوند:

# Update files in trunk
cp -r build/* my-custom-block-svn/trunk/
svn add trunk/* --force
svn commit -m "Update to v1.0.1"

# Create new tag
svn copy trunk/ tags/1.0.1/
svn commit -m "Tag version 1.0.1"

پس از Commit Tag، وردپرس به‌طور خودکار نسخه جدید را در پنل مدیریت کاربران نمایش می‌دهد. این فرآیند معمولاً در عرض چند دقیقه انجام می‌شود.

فرآیند بازبینی تیم Plugin Review

پس از ارسال اولیه درخواست افزونه، تیم Plugin Review وردپرس بررسی می‌کند که افزونه با دستورالعمل‌های مخزن سازگار است. این فرآیند معمولاً بین ۱ تا ۱۰ روز طول می‌کشد، بسته به حجم صف بازبینی. بازبینی شامل چند مرحله است:

مرحله اول: بررسی خودکار. یک اسکنر خودکار، فایل‌ها را برای موارد زیر بررسی می‌کند: هدر GPL، وجود فایل readme.txt، نام‌گذاری نامعتبر، فایل‌های باینری بزرگ، و کدهای مشکوک. اگر افزونه در این مرحله رد شود، یک ایمیل با جزئیات ارسال می‌شود.

مرحله دوم: بازبینی دستی. یک بازبین انسانی، کد را بررسی می‌کند. موارد بررسی‌شده عبارتند از:

امنیت: Sanitization، Escaping، Nonce، Capability Check
سازگاری: استفاده از توابع منسوخ (Deprecated Functions)
استانداردها: Prefixing، Text Domain، License Headers
تجربه کاربری: نصب ساده، عدم تبلیغ اجباری، عدم ارسال داده بدون رضایت
کیفیت کد: خوانایی، مستندسازی، ساختار منطقی

مرحله سوم: بازخورد و اصلاح. اگر بازبین نکاتی داشته باشد، یک ایمیل با لیست تغییرات موردنیاز ارسال می‌کند. شما باید تغییرات را اعمال کنید و پاسخ دهید. این چرخه ممکن است چند بار تکرار شود. اگر با اشتباهات رایج در توسعه قالب و افزونه وردپرس آشنا شده باشید، می‌دانید که بیشتر این اشتباهات در بازبینی کشف می‌شوند.

«بازبینی مخزن، یک دیالوگ است، نه یک آزمون. هدف، رسیدن به کیفیت است، نه رد کردن افزونه.»

مرحله چهارم: تأیید نهایی. پس از رفع تمام نکات، افزونه تأیید می‌شود و URL SVN در اختیار شما قرار می‌گیرد. از این لحظه، می‌توانید با SVN افزونه را منتشر کنید.

نکته مهم این است که بازبینی فقط برای نسخه اولیه انجام می‌شود. به‌روزرسانی‌های بعدی نیازی به بازبینی کامل ندارند، اما ممکن است به‌صورت نمونه‌ای بررسی شوند. اگر تخلفی گزارش شود، افزونه ممکن است موقتاً غیرفعال یا حذف شود.

پس از انتشار: نگهداری و به‌روزرسانی

انتشار، پایان کار نیست؛ آغاز تعهد به کاربران است. پس از انتشار، چند وظیفه مستمر دارید:

پشتیبانی از کاربران. بخش پشتیبانی مخزن، محل تعامل با کاربران است. باید به سؤالات پاسخ دهید، باگ‌ها را بررسی کنید، و بازخوردها را در نسخه‌های بعدی اعمال نمایید. زمان پاسخ، معیاری مهم در امتیاز افزونه است.

به‌روزرسانی منظم. افزونه باید با نسخه‌های جدید وردپرس، PHP و کتابخانه‌های وابسته سازگار بماند. حداقل هر شش ماه یک به‌روزرسانی منتشر کنید، حتی اگر تغییر جزئی باشد. اگر با بررسی سازگاری افزونه‌های وردپرس آشنا شده باشید، می‌دانید که این موضوع یکی از معیارهای اصلی اعتماد کاربران است.

مدیریت نسخه. از Semantic Versioning (نسخه‌بندی معنایی) استفاده کنید: MAJOR.MINOR.PATCH. نسخه 1.0.0 نسخه اولیه است. تغییرات ناسازگار (Breaking Changes) نسخه MAJOR را افزایش می‌دهند. ویژگی‌های جدید نسخه MINOR. رفع باگ نسخه PATCH.

پیگیری آمار. مخزن وردپرس آمار نصب، دانلود و امتیاز را نمایش می‌دهد. این آمار، بازخورد مستقیم کاربران است و باید در تصمیمات توسعه لحاظ شود.

ترجمه. با استفاده از translate.wordpress.org، می‌توانید افزونه را به زبان‌های مختلف ترجمه کنید. این کار، دامنه کاربران را چند برابر می‌کند و به رشد افزونه کمک می‌نماید.

اشتباهات رایج در انتشار بلاک

اشتباه اول: فراموش کردن Prefixing. اگر توابع، کلاس‌ها یا متغیرهای سراسری با نام‌های عمومی مثل init() یا $options تعریف شوند، با سایر افزونه‌ها تداخل می‌کنند و افزونه رد می‌شود. همیشه از پیشوند یکتا مثل my_custom_block_ استفاده کنید.

اشتباه دوم: نادیده گرفتن Text Domain. اگر Text Domain در هدر افزونه با اسلاگ SVN یکسان نباشد، ترجمه‌ها بارگذاری نمی‌شوند. این یکی از شایع‌ترین دلایل رد شدن در بازبینی است.

اشتباه سوم: استفاده از توابع منسوخ. توابعی مثل create_function()، each() (در PHP 8)، و برخی توابع وردپرسی منسوخ شده‌اند و نباید در کد جدید استفاده شوند. بازبین‌ها این موارد را بررسی می‌کنند.

اشتباه چهارم: ارسال داده بدون رضایت کاربر. اگر افزونه شما داده‌ای به سرور خارجی ارسال می‌کند (مثل آمار استفاده یا لایسنس)، باید رضایت صریح کاربر را بگیرید و در readme.txt شفاف توضیح دهید. ارسال پنهانی داده، دلیل فوری حذف افزونه است.

اشتباه پنجم: قرار دادن فایل‌های حجیم در SVN. فایل‌های ویدئویی، PSD یا بسته‌های npm نباید در SVN باشند. این کار، حجم مخزن را بی‌دلیل افزایش می‌دهد و ممکن است منجر به رد شدن شود.

اشتباه ششم: تست نکردن در نسخه‌های قدیمی وردپرس. اگر افزونه به‌عنوان سازگار با وردپرس ۵.۸ معرفی شده، باید واقعاً با آن نسخه تست شود. بازبین‌ها این موضوع را بررسی می‌کنند. اگر با تست بلاک‌های وردپرس با Jest و Playwright آشنا شده باشید، می‌دانید که این تست‌ها باید در محیط‌های مختلف اجرا شوند.

اشتباه هفتم: تبلیغ درون‌افزونه‌ای. افزونه‌های مخزن رسمی نباید کاربر را به نسخه Pro یا سرویس خارجی مجبور کنند. هرچند ارجاع اختیاری مجاز است، اما تبلیغ اجباری، دلیل رد شدن است.

پرسش‌های پرتکرار درباره انتشار بلاک سفارشی

چگونه می‌توانم بلاک سفارشی خود را در مخزن وردپرس منتشر کنم؟

فرآیند شامل پنج گام است: اول، آماده‌سازی افزونه با ساختار استاندارد و فایل readme.txt. دوم، ثبت درخواست ارسال در wordpress.org/plugins/developers/. سوم، انتظار برای تأیید تیم Plugin Review (معمولاً ۱ تا ۱۰ روز). چهارم، دریافت URL SVN و ارسال فایل‌ها با svn commit. پنجم، ساخت Tag نسخه و آپلود بنر و آیکن در پوشه assets/.

آیا بلاک سفارشی می‌تواند به‌تنهایی در مخزن منتشر شود؟

خیر. بلاک‌ها بخشی از یک افزونه هستند و نمی‌توانند به‌تنهایی منتشر شوند. باید ابتدا یک افزونه بسازید که بلاک را ثبت کند، سپس افزونه را در مخزن منتشر نمایید. بلاک فقط یک ویژگی از افزونه است.

چقدر طول می‌کشد تا افزونه تأیید شود؟

زمان بازبینی به حجم صف و پیچیدگی افزونه بستگی دارد. معمولاً بین ۱ تا ۱۰ روز. اگر افزونه پیچیده باشد یا نکات متعددی داشته باشد، ممکن است چند هفته طول بکشد. برای تسریع، اطمینان حاصل کنید که کد با استانداردهای وردپرس مطابقت دارد.

آیا استفاده از SVN اجباری است یا می‌توان از Git استفاده کرد؟

مخزن رسمی وردپرس فقط از SVN پشتیبانی می‌کند. با این حال، می‌توانید از Git برای توسعه محلی استفاده کنید و سپس فایل‌ها را با svn commit به مخزن ارسال نمایید. ابزارهایی مثل git-svn این فرآیند را ساده می‌کنند، اما امروزه بیشتر توسعه‌دهندگان از یک Workflow دوگانه استفاده می‌کنند: Git برای توسعه و SVN برای انتشار.

چگونه می‌توانم نسخه جدید را منتشر کنم؟

سه گام اصلی: اول، فایل‌های به‌روزرسانی‌شده را در trunk/ کپی کنید و با svn commit ارسال نمایید. دوم، با svn copy trunk/ tags/1.0.1/ یک Tag جدید بسازید. سوم، با svn commit Tag را منتشر کنید. پس از این، وردپرس به‌طور خودکار نسخه جدید را به کاربران اطلاع می‌دهد.

آیا می‌توانم افزونه را بعد از انتشار حذف کنم؟

بله، اما نه به‌طور کامل. می‌توانید افزونه را از مخزن حذف کنید یا آن را Closed کنید تا در جستجو نمایش داده نشود. اما سابقه آن باقی می‌ماند. حذف کامل افزونه از SVN، فقط توسط تیم وردپرس انجام می‌شود.

آیا افزونه‌های رایگان می‌توانند مدل Freemium داشته باشند؟

بله، با شرایط. افزونه رایگان باید به‌تنهایی کار کند و کاربر را به خرید نسخه Pro مجبور نکند. می‌توانید نسخه Pro را در وب‌سایت خودتان بفروشید، اما نباید در افزونه رایگان، قابلیت‌هایی را پنهان کنید یا کاربر را به خرید مجبور نمایید. اگر با مقایسه افزونه رایگان و پولی وردپرس آشنا شده باشید، این مدل را به‌عنوان Freemium می‌شناسید.

چگونه از تداخل با سایر افزونه‌ها جلوگیری کنم؟

سه اصل: اول، از Prefixing برای تمام توابع، کلاس‌ها و متغیرهای سراسری استفاده کنید. دوم، از Namespaceهای PHP استفاده کنید. سوم، در فرآیند توسعه، افزونه را با افزونه‌های محبوب تست کنید. اگر با پیدا کردن افزونه مشکل‌ساز وردپرس آشنا شده باشید، می‌دانید که تداخل، یکی از شایع‌ترین دلایل نارضایتی کاربران است.

نگاه نهایی به انتشار بلاک سفارشی

انتشار بلاک سفارشی در مخزن وردپرس، یک فرآیند مهندسی چندلایه است که از ساختار افزونه و استانداردهای کدنویسی آغاز می‌شود و با SVN، Tag و بازبینی به انتشار عمومی می‌رسد. این فرآیند، نه فقط یک اقدام توزیعی، بلکه یک تعهد به امنیت، سازگاری و نگهداشت‌پذیری است. سه معیار کلیدی برای موفقیت در این مسیر:

۱. آماده‌سازی دقیق. افزونه باید ساختار استاندارد، فایل readme.txt کامل، و Metadata صحیح داشته باشد. block.json به‌عنوان منبع اصلی Metadata بلاک، باید دقیق و مطابق با استانداردهای جدید باشد.

۲. رعایت استانداردها. Sanitization، Escaping، Nonce، Capability Check، و Prefixing از الزامات بازبینی هستند. استفاده از PHP_CodeSniffer با استاندارد WordPress، این موارد را قبل از ارسال کشف می‌کند.

۳. تعهد بلندمدت. انتشار، آغاز یک رابطه است، نه پایان یک پروژه. پشتیبانی، به‌روزرسانی منظم، و تعامل با کاربران، معیارهای اصلی موفقیت بلندمدت در مخزن هستند.

اگر در حال ساخت بلاک سفارشی هستید، پیشنهاد می‌کنم از همان روز اول، ساختار افزونه را با هدف انتشار در مخزن طراحی کنید. این رویکرد، از بازنویسی‌های پرهزینه در آینده جلوگیری می‌کند و کیفیت کد را از ابتدا تضمین می‌نماید. برای آشنایی بیشتر با توسعه افزونه و بلاک، ساخت بلاک سفارشی گوتنبرگ و ساخت افزونه حرفه‌ای وردپرس می‌توانند نقاط شروع خوبی باشند.

نگاه مهندسی سطح بالا

از منظر معماری نرم‌افزار، انتشار در مخزن وردپرس یک نمونه جالب از Distributed Governance است: به‌جای یک کنترل مرکزی سخت‌گیرانه، یک فرآیند بازبینی مبتنی بر استانداردها و اعتماد توزیع‌شده شکل گرفته است. تیم Plugin Review نه به‌عنوان یک Gatekeeper (دروازه‌بان) بلکه به‌عنوان یک Facilitator (تسهیل‌گر) عمل می‌کند که کیفیت را در سطح اکوسیستم تضمین می‌نماید. این مدل، در مقایسه با مدل‌های کنترل متمرکز (مثل Apple App Store)، انعطاف‌پذیری بیشتری دارد اما نیازمند بلوغ بالاتر توسعه‌دهندگان است. چالش اصلی این مدل، مقیاس‌پذیری بازبینی است: با بیش از ۶۰,۰۰۰ افزونه و صدها ارسال جدید در هر ماه، بازبینی دستی به گلوگاه تبدیل می‌شود. راه‌حل تکاملی، حرکت به سمت Automated Compliance است: اسکنرهای خودکار که الگوهای ناامن یا ناسازگار را در سطح AST (Abstract Syntax Tree) کشف می‌کنند. برای بلاک‌های گوتنبرگ، این چالش پیچیده‌تر می‌شود چون هم کد PHP و هم کد JavaScript باید بررسی شوند و هر کدام AST، استانداردها و ابزارهای تحلیلی متفاوتی دارند. اگر با استانداردهای کدنویسی وردپرس آشنا باشید، می‌دانید که این استانداردها نه فقط یک انتخاب سلیقه‌ای، بلکه یک زبان مشترک برای همکاری در مقیاس میلیونی هستند. در نهایت، انتشار بلاک سفارشی در مخزن، یک تصمیم معمارانه است: شما کد خود را به‌عنوان بخشی از یک اکوسیستم جهانی معرفی می‌کنید و تعهد می‌دهید که در چارچوب استانداردهای آن، به میلیون‌ها کاربر خدمت کنید. این تعهد، هم فرصت است و هم مسئولیت، و توسعه‌دهندگانی که آن را جدی می‌گیرند، در بلندمدت موفق‌تر هستند.

اگر این مسیر را در یک پروژه واقعی تجربه کرده‌اید، جالب است بدانید کدام بخش آن بیشترین زمان را از شما گرفت. تجربه خودتان را در دیدگاه‌ها بنویسید؛ به‌خصوص اگر راه‌حل دیگری پیدا کرده‌اید که می‌تواند برای خواننده بعدی مفید باشد. 🚀

همچنین اگر می‌خواهید در مورد پیاده‌سازی عملی بلاک‌های گوتنبرگ بیشتر بدانید، ساخت بلاک سفارشی گوتنبرگ از صفر و ساختار فایل‌های یک افزونه استاندارد وردپرس می‌توانند نقاط شروع خوبی باشند.