معماری OOP در افزونه‌نویسی وردپرس

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

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

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

معماری OOP در وردپرس

معماری OOP در وردپرس یعنی طراحی کد افزونه بر اساس کلاس‌ها، اشیا و مسئولیت‌های مشخص، به‌جای اینکه تمام قابلیت‌ها در قالب توابع پراکنده نوشته شوند. OOP مخفف Object-Oriented Programming یا برنامه‌نویسی شی‌گراست. در این روش، داده‌ها و رفتارهای مرتبط درون کلاس قرار می‌گیرند و هر کلاس وظیفه‌ای روشن دارد.

وردپرس ذاتاً یک سیستم کاملاً شی‌گرا نیست و در هسته آن هنوز توابع procedural زیادی دیده می‌شود؛ بااین‌حال، توسعه‌دهنده افزونه می‌تواند از کلاس‌ها برای ساخت کدی تمیزتر استفاده کند. این ترکیب باعث می‌شود افزونه با اکوسیستم وردپرس، هوک‌ها، توابع داخلی و APIهای آن سازگار بماند و در عین حال ساختار حرفه‌ای خود را حفظ کند.

فهرست مطالب

• OOP در افزونه‌نویسی وردپرس چیست؟
• چرا باید از معماری شی‌گرا استفاده کنیم؟
• ساختار پیشنهادی افزونه OOP
• مدیریت هوک‌ها و چرخه اجرای افزونه
• وابستگی‌ها و تزریق Dependency
• امنیت و استانداردهای کدنویسی
• مثال عملی ساخت افزونه
• مزایا و معایب معماری OOP
• سؤالات متداول

OOP در افزونه‌نویسی وردپرس چیست؟

کلاس، شیء و متد چه نقشی دارند؟

کلاس را می‌توان مانند نقشه‌ای برای ساخت یک شیء در نظر گرفت. برای نمونه، اگر افزونه‌ای وظیفه مدیریت تنظیمات را بر عهده دارد، کلاسی با نامی مانند Settings می‌تواند متدهای ثبت صفحه تنظیمات، نمایش فیلدها و ذخیره داده‌ها را در خود جای دهد.

شیء، نمونه‌ای ساخته‌شده از کلاس است و متد، تابعی است که درون کلاس قرار دارد. در معماری OOP، به‌جای نوشتن چند تابع عمومی با نام‌های طولانی، رفتار مرتبط با هر بخش در کلاس مناسب قرار می‌گیرد. این کار احتمال برخورد نام توابع را هم کاهش می‌دهد؛ مسئله‌ای که در وردپرس به دلیل وجود افزونه‌ها و قالب‌های متعدد کاملاً جدی است.

تفاوت کدنویسی رویه‌ای و شی‌گرا

در کدنویسی رویه‌ای ممکن است تمام منطق در فایل اصلی افزونه قرار بگیرد:

function register_plugin_settings() {

// ثبت تنظیمات
}
function render_plugin_page() {
// نمایش صفحه
}
add_action('admin_menu', 'register_plugin_settings');

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

class Plugin_Settings {

public function register() {
add_action('admin_menu', [$this, 'add_menu']);
}
public function add_menu() {
// ثبت منوی تنظیمات
}
}
$settings = new Plugin_Settings();
$settings->register();

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

چرا باید از معماری OOP در وردپرس استفاده کنیم؟

کاهش تداخل بین بخش‌های مختلف

نام‌گذاری توابع در وردپرس اهمیت زیادی دارد. اگر دو افزونه تابعی با نام یکسان تعریف کنند، خطای «Cannot redeclare» رخ می‌دهد. کلاس‌ها و فضای نام‌ها این مشکل را تا حد زیادی کنترل می‌کنند. استفاده از namespace باعث می‌شود کلاس‌ها با نام‌های عمومی سایر افزونه‌ها تداخل نداشته باشند.

برای مثال، به‌جای تعریف کلاسی با نام عمومی Settings می‌توان از ساختار زیر استفاده کرد:

namespace AcmePluginAdmin;

class Settings {
}

این کلاس حتی اگر افزونه دیگری نیز کلاسی با نام Settings داشته باشد، به دلیل فضای نام متفاوت دچار تداخل نخواهد شد.

توسعه‌پذیری بهتر

در یک افزونه حرفه‌ای، قابلیت‌ها معمولاً به‌مرور اضافه می‌شوند: ثبت نوع نوشته سفارشی، ساخت شورت‌کد، افزودن REST API، ایجاد صفحه تنظیمات و اتصال به ووکامرس. اگر هر قابلیت کلاس جداگانه داشته باشد، توسعه‌دهنده بدون دستکاری گسترده کدهای قبلی می‌تواند ویژگی جدیدی اضافه کند.

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

تست و خطایابی ساده‌تر

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

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

ساختار پیشنهادی افزونه OOP

ساختار پوشه‌ها

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

my-plugin/

├── my-plugin.php
├── src/
│   ├── Admin/
│   │   └── SettingsPage.php
│   ├── Frontend/
│   │   └── Shortcode.php
│   ├── Core/
│   │   └── Plugin.php
│   └── Infrastructure/
│       └── Loader.php
├── templates/
├── assets/
│   ├── css/
│   └── js/
├── languages/
├── tests/
└── composer.json

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

فایل اصلی افزونه

<?php

/**
* Plugin Name: My OOP Plugin
*/
defined('ABSPATH') || exit;
require_once __DIR__ . '/vendor/autoload.php';
$plugin = new AcmePluginCorePlugin();
$plugin->run();

استفاده از defined('ABSPATH') || exit; مانع دسترسی مستقیم به فایل می‌شود. همچنین اگر از Composer استفاده می‌کنید، بارگذاری کلاس‌ها از طریق autoload باعث می‌شود نیازی به include و require دستی همه فایل‌ها نداشته باشید.

Autoload و Composer

در پروژه‌های کوچک می‌توان از autoloader ساده استفاده کرد، اما Composer انتخاب استانداردتری است. در فایل composer.json می‌توانید PSR-4 را تعریف کنید:

{

"autoload": {
"psr-4": {
"Acme\Plugin\": "src/"
}
}
}

بعد از اجرای دستور composer dump-autoload، کلاس‌ها بر اساس فضای نام و مسیر فایل به‌صورت خودکار بارگذاری می‌شوند. این روش نظم پروژه را بیشتر می‌کند و احتمال خطای مسیر فایل‌ها را کاهش می‌دهد.

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

مدیریت هوک‌ها و چرخه اجرای افزونه

ثبت هوک‌ها در یک محل مشخص

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

class Shortcode {

public function register() {
add_shortcode('product_notice', [$this, 'render']);
}
public function render($atts) {
return '<div class="notice">پیام محصول</div>';
}
}

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

مدیریت فعال‌سازی و غیرفعال‌سازی

عملیات فعال‌سازی افزونه باید فقط برای کارهایی مانند ساخت جدول، ثبت گزینه اولیه یا flush کردن rewrite rules استفاده شود. اجرای عملیات سنگین در هر بار بارگذاری وردپرس اشتباه است و می‌تواند سرعت سایت را کاهش دهد.

register_activation_hook(__FILE__, function () {

add_option('acme_plugin_version', '1.0.0');
});
register_deactivation_hook(__FILE__, function () {
// پاک‌سازی موقت، بدون حذف اطلاعات مهم کاربر
});

وابستگی‌ها و تزریق Dependency

وابستگی مستقیم چه مشکلی ایجاد می‌کند؟

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

در روش تزریق وابستگی، سرویس موردنیاز از بیرون به کلاس داده می‌شود:

class OrderService {

private $mailer;
public function __construct($mailer) {
$this->mailer = $mailer;
}
public function notify_customer($email, $message) {
return $this->mailer->send($email, $message);
}
}

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

Container یا هسته مرکزی افزونه

برای پروژه‌های متوسط و بزرگ، بهتر است یک کلاس مرکزی وظیفه ساخت و اجرای سرویس‌ها را بر عهده بگیرد. این کلاس می‌تواند Admin، Frontend، REST API و سرویس‌های داده را ثبت کند. نکته مهم این است که کلاس مرکزی نباید به یک «کلاس همه‌کاره» تبدیل شود؛ وظیفه آن هماهنگی است، نه اجرای تمام منطق افزونه.

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

اعتبارسنجی، پاک‌سازی و Escape

شی‌گرا نوشتن به‌تنهایی افزونه را امن نمی‌کند. هر داده ورودی باید بر اساس کاربردش اعتبارسنجی یا پاک‌سازی شود. داده‌ای که در HTML نمایش داده می‌شود باید با esc_html یا esc_attr خروجی‌گری شود. اطلاعاتی که در URL قرار می‌گیرد، به توابعی مانند esc_url نیاز دارد.

برای فرم‌های مدیریت نیز nonce و بررسی سطح دسترسی الزامی است:

if (

! isset($_POST['acme_nonce']) ||
! wp_verify_nonce(
sanitize_text_field(wp_unslash($_POST['acme_nonce'])),
'acme_save_settings'
)
) {
return;
}
if (!current_user_can('manage_options')) {
return;
}

نام‌گذاری و استاندارد WordPress Coding Standards

کلاس‌ها، متدها و متغیرها باید نام‌هایی توصیفی داشته باشند. از نام‌هایی مانند Data، Helper یا Manager بدون توضیح دقیق پرهیز کنید؛ این نام‌ها معمولاً مسئولیت واقعی کلاس را پنهان می‌کنند.

همچنین استفاده از WordPress Coding Standards، PHP CodeSniffer و ابزارهای بررسی استاتیک مانند PHPStan می‌تواند خطاهایی را پیش از انتشار پیدا کند. در پروژه‌هایی که قرار است به‌صورت مداوم به‌روزرسانی شوند، این ابزارها بخش مهمی از فرایند کیفیت کد هستند.

مثال عملی ساخت افزونه با معماری OOP در وردپرس

سناریو: نمایش پیام در انتهای نوشته‌ها

در این مثال، افزونه‌ای می‌سازیم که در پایان نوشته‌های وبلاگ یک پیام قابل تنظیم نمایش می‌دهد. برای ساده نگه‌داشتن نمونه، سه کلاس در نظر می‌گیریم: کلاس اصلی افزونه، کلاس تنظیمات و کلاس نمایش پیام.

<?php

namespace AcmeNotice;
class Plugin {
private $settings;
private $frontend;
public function __construct() {
$this->settings = new Settings();
$this->frontend = new Frontend();
}
public function run() {
$this->settings->register();
$this->frontend->register();
}
}

کلاس تنظیمات فقط مسئول ثبت گزینه و صفحه تنظیمات است:

class Settings {

public function register() {
add_action('admin_init', [$this, 'register_options']);
}
public function register_options() {
register_setting(
'acme_notice_group',
'acme_notice_text',
[
'sanitize_callback' => 'sanitize_text_field'
]
);
}
}

کلاس سمت کاربر نیز تنها به فیلتر محتوای نوشته متصل می‌شود:

class Frontend {

public function register() {
add_filter('the_content', [$this, 'append_notice']);
}
public function append_notice($content) {
if (!is_singular('post') || !in_the_loop() || !is_main_query()) {
return $content;
}
$notice = get_option('acme_notice_text', '');
if (!$notice) {
return $content;
}
return $content . '<div class="acme-notice">' .
esc_html($notice) .
'</div>';
}
}

مزیت این ساختار روشن است: اگر بعداً بخواهیم پیام را فقط برای دسته خاصی نمایش دهیم، کلاس Frontend تغییر می‌کند؛ اگر بخواهیم فیلد تنظیمات را توسعه دهیم، کلاس Settings را ویرایش می‌کنیم. این جداسازی، احتمال اثرگذاری ناخواسته تغییرات را پایین می‌آورد.

در پروژه واقعی، بهتر است HTML را در فایل template جدا قرار دهید و CSS را با wp_enqueue_style بارگذاری کنید. همچنین خروجی را با یک کلاس CSS مشخص بسازید تا با استایل قالب تداخل نداشته باشد. اگر افزونه قابلیت‌های پیچیده‌تری مانند اتصال به ووکامرس یا پرداخت دارد، استفاده از معماری سرویس‌محور و طراحی افزونه وردپرس حرفه‌ای اهمیت بیشتری پیدا می‌کند.

مزایا و معایب معماری OOP در وردپرس

مزایا

• کاهش تداخل نام توابع و کلاس‌ها.
• تفکیک مسئولیت‌ها و خوانایی بهتر کد.
• توسعه ساده‌تر قابلیت‌های جدید.
• امکان تست واحد و خطایابی دقیق‌تر.
• مناسب برای همکاری چند توسعه‌دهنده روی یک پروژه.
• آمادگی بهتر برای استفاده از namespace، Composer و استانداردهای مدرن PHP.

معایب و محدودیت‌ها

• برای افزونه‌های بسیار کوچک ممکن است بیش از نیاز پروژه پیچیدگی ایجاد کند.
• نیازمند آشنایی با اصول SOLID، namespace و مدیریت وابستگی‌هاست.
• اگر کلاس‌ها بیش از حد بزرگ شوند، ظاهر شی‌گرا بدون مزیت واقعی ایجاد می‌شود.
• استفاده نادرست از الگوهای طراحی می‌تواند کد را از حالت ساده و قابل فهم خارج کند.

راهکار عملی این است که از همان ابتدا همه‌چیز را بیش از حد مهندسی نکنید. ابتدا قابلیت‌ها را شناسایی کنید، سپس بخش‌هایی را که مسئولیت مستقل دارند به کلاس تبدیل کنید. یک افزونه کوچک با چهار کلاس واضح، بهتر از پروژه‌ای است که برای هر تابع ساده، چند لایه غیرضروری دارد.

اشتباهات رایج در معماری OOP وردپرس

کلاس‌های غول‌پیکر

نام‌گذاری کلاس با عنوانی مانند PluginManager و قرار دادن تمام منطق افزونه در آن، شی‌گرایی واقعی نیست. اگر یک کلاس هم تنظیمات را ذخیره کند، هم شورت‌کد بسازد، هم درخواست AJAX را پردازش کند و هم فایل CSS را بارگذاری کند، اصل مسئولیت واحد نقض شده است.

استفاده افراطی از Singleton

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

ترکیب منطق تجاری با نمایش

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

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

چه زمانی استفاده از OOP انتخاب مناسبی نیست؟

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

اما اگر افزونه قرار است در چند سایت استفاده شود، با ووکامرس یا سرویس‌های خارجی ارتباط داشته باشد، صفحه تنظیمات داشته باشد یا چند توسعه‌دهنده روی آن کار کنند، استفاده از معماری OOP در وردپرس تصمیم منطقی‌تری است. در چنین شرایطی، نظم کد مستقیماً روی هزینه نگهداری و سرعت توسعه اثر می‌گذارد.

جمع‌بندی معماری OOP در وردپرس

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

برای شروع، افزونه خود را به بخش‌های اصلی مانند هسته، مدیریت، سمت کاربر و زیرساخت تقسیم کنید. سپس از namespace، autoload، نام‌گذاری روشن، اعتبارسنجی ورودی و خروجی‌گری امن استفاده کنید. معماری OOP در وردپرس زمانی موفق است که کد را برای توسعه‌دهنده بعدی قابل فهم‌تر و تغییرات آینده را کم‌ریسک‌تر کند، نه اینکه صرفاً ظاهر پروژه را پیچیده‌تر نشان دهد.

سؤالات متداول

آیا همه افزونه‌های وردپرس باید با OOP نوشته شوند؟

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

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

خود کلاس به‌تنهایی باعث افزایش سرعت نمی‌شود. مزیت اصلی OOP، نظم، نگهداری و توسعه‌پذیری است. سرعت بیشتر معمولاً از کوئری‌های بهینه، کش، بارگذاری شرطی فایل‌ها و کاهش پردازش‌های غیرضروری به دست می‌آید.

آیا می‌توان در افزونه OOP از توابع وردپرس استفاده کرد؟

بله. معماری شی‌گرا قرار نیست توابع وردپرس را حذف کند. کلاس‌ها می‌توانند از توابعی مانند get_option، wp_insert_post، add_action و register_setting استفاده کنند.

بهترین روش برای ثبت هوک‌ها در کلاس چیست؟

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

آیا استفاده از Composer برای هر افزونه‌ای ضروری است؟

ضروری نیست، اما برای افزونه‌های متوسط و بزرگ بسیار مفید است. Composer مدیریت وابستگی‌ها و autoload را ساده می‌کند. برای یک افزونه کوچک بدون کتابخانه خارجی، autoloader ساده نیز می‌تواند پاسخ‌گو باشد.

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

امنیت به ساختار OOP وابسته نیست. بررسی دسترسی کاربر، استفاده از nonce، پاک‌سازی ورودی، اعتبارسنجی داده و escape کردن خروجی باید در هر معماری رعایت شود.