فرض کنید یک سایت فروشگاهی دارید و فقط یک قابلیت کوچک میخواهید به آن اضافه کنید. مثلاً میخواهید هنگام ثبت هر محصول، مدت گارانتی را وارد کنید و همان مقدار زیر قیمت محصول نمایش داده شود.
در ظاهر خواسته پیچیدهای نیست؛ یک فیلد برای مدیر سایت و چند کلمه برای کاربر.
مشکل زمانی شروع میشود که میخواهید همین قابلیت کوچک را اجرا کنید. بین افزونههای وردپرس جستجو میکنید؛ یکی یک سیستم کامل برای مدیریت گارانتی است و دهها قابلیتی دارد که اصلاً به آنها نیاز ندارید، دیگری نسخه پولی میخواهد، افزونه بعدی مدت زیادی است بهروزرسانی نشده و یکی هم دقیقاً همان رفتاری را که میخواهید ایجاد نمیکند.
در نهایت برای اضافهکردن یک قابلیت کوچک، یا باید افزونهای بزرگتر از نیازتان نصب کنید، یا کار را به برنامهنویس بسپارید، یا خودتان وارد PHP، Hookهای وردپرس و ساختار Plugin Development شوید.
یعنی گاهی پیچیدگی راهحل از خود مسئله بیشتر میشود.
حالا فرض کنید همین نیاز را به زبانی که برای دوستتان شرح میدهید، به یک ابزار هوش مصنوعی بدهید:
«یک افزونه وردپرس بساز که در صفحه ویرایش محصولات WooCommerce یک فیلد مدت گارانتی اضافه کند و اگر برای محصول مقداری ثبت شده بود، آن را زیر قیمت محصول نمایش دهد.»
ابزارهای AI Coding میتوانند درخواستهای نوشتهشده با زبان طبیعی را دریافت کنند و براساس آن کد تولید یا فایلهای پروژه را تغییر دهند. Coding Agentهای جدید حتی میتوانند Context پروژه را بررسی کنند، روی چند فایل کار کنند و برای انجام Task از ابزارهای محیط توسعه استفاده کنند.[۴]
در نتیجه نقطه شروع برای برطرف کردن نیازتان تغییر میکند. لازم نیست خودتان تمام کد را خطبهخط بنویسید؛ میتوانید نیاز را تعریف کنید، نسخه اولیه را ایجاد کنید و تغییرات بعدی را نیز با توضیح نتیجهای که میخواهید جلو ببرید.
این روش با منطق توسعه WordPress نیز تضادی ندارد. WordPress در Plugin Developer Handbook به صراحت با این موضوع اشاره میکند که:
«قابلیتهایی که میخواهید به WordPress اضافه کنید یا در آن تغییر انجام دهید، باید از طریق افزونه انجام شوند نه از طریق ویرایش کدهای هسته وردپرس.»
بنابراین سؤال اصلی این نیست که آیا برای یک قابلیت اختصاصی میتوان افزونه ساخت؛ سؤال این است که چقدر از مسیر ساخت همان افزونه را میتوان به هوش مصنوعی سپرد، بدون اینکه خودتان از ابتدا وارد کدنویسی شوید؟
در این راهنما از مدیروب ابتدا مشخص میکنیم Plugin وردپرس چیست، چه افزونههایی را میتوان با AI ساخت و سپس یک افزونه واقعی WooCommerce را از ایده تا فایل قابل نصب جلو میبریم.
Plugin مجموعهای از کدهاست که قابلیت WordPress را بیشتر میکند یا رفتار بخشی از آن را تغییر میدهد، بدون اینکه لازم باشد فایلهای اصلی WordPress ویرایش شوند. مستندات رسمی WordPress توضیح میدهند که افزونهها میتوانند بسته به نیاز بسیار ساده یا بسیار پیچیده باشند و سادهترین Plugin حتی میتواند فقط یک فایل PHP باشد.[۱]
این فایل برای اینکه بهعنوان Plugin توسط WordPress شناسایی شود، باید Plugin Header داشته باشد. طبق مستندات رسمی، حداقل اطلاعات اجباری این Header، نام افزونه یا Plugin Name است.[۲]
پس هر Plugin الزاماً یک نرمافزار بزرگ با دهها صفحه تنظیمات نیست.
گاهی فقط میخواهید:
اگر افزونه معتبر و آمادهای دقیقاً همین نیاز را پوشش میدهد، الزاماً دلیلی برای ساخت Plugin جدید وجود ندارد. اما زمانی که نیاز شما بسیار اختصاصی است، ساخت یک افزونه کوچک میتواند بهجای نصب سیستمی با قابلیتهای غیرضروری تصمیم منطقیتری باشد.
بله؛ اما بدون کدنویسی در اینجا به این معنی نیست که Plugin بدون کد ساخته میشود. بلکه به این معناست که شما کد را خطبهخط نمینویسید؛ هوش مصنوعی آن را تولید میکند. خود افزونه همچنان میتواند شامل PHP، JavaScript، CSS یا هر کد دیگری باشد که برای قابلیت موردنظر لازم است.
GitHub در مستندات Copilot توضیح میدهد که ورودی کاربر میتواند زبان طبیعی باشد( یعنی شما نیازتان را حتی به زبان فارسی برای هوش مصنوعی بگویید) و سیستم براساس Prompt و Context مرتبط پاسخ یا کد تولید کند. Agentهای کدنویسی نیز میتوانند علاوه بر تولید کد، فایلها را تغییر دهند و Command اجرا کنند.[۴]
به همین دلیل بهجای اینکه ابتدا مشخص کنید کدام Hook ووکامرس باید استفاده شود، داده در کدام Meta ذخیره شود و چه Functionی خروجی را نمایش دهد، میتوانید ابتدا رفتار موردنظر را توضیح دهید، به مثال زیر توجه کنید:
«برای هر محصول یک مدت گارانتی ثبت شود و اگر مقدار وجود داشت زیر قیمت نمایش داده شود.»
بعد نتیجه را مشاهده و درخواست بعدی را مطرح کنید:
«اگر گارانتی خالی بود هیچ چیزی نمایش نده.»
یا:
«فیلد را داخل بخش اطلاعات محصول قرار بده.»
این شکل از توسعه به روشی که با عنوان وایب کدینگ شناخته میشود نزدیک است؛ یعنی پروژه را بیشتر با توضیح نتیجه و اصلاح مرحلهبهمرحله خروجی هدایت میکنید.
AI محدود به ساخت یک نوع خاص Plugin نیست. اگر یک قابلیت از طریق APIها، Hookها و قابلیتهای توسعه WordPress قابل پیادهسازی باشد، میتوان از هوش مصنوعی برای تولید بخشی یا تمام کد اولیه آن کمک گرفت. در پروژههای واقعی، نوع افزونه بیشتر به نیازی که تعریف میکنید وابسته است.
فرض کنید تیم فروش برای هر سفارش باید یک یادداشت یا وضعیت داخلی ثبت کند که مشتری نباید آن را ببیند.
میتوان Plugin کوچکی طراحی کرد که فیلدی به صفحه سفارش اضافه کند و مقدار آن فقط در مدیریت WordPress قابل مشاهده باشد. یا تیم محتوا ممکن است برای هر محصول یک اطلاعات داخلی داشته باشد که نباید در Front-end نمایش داده شود. این نوع نیازها معمولاً کوچک هستند اما به Workflow یک مجموعه وابستگی زیادی دارند؛ به همین دلیل ممکن است افزونه آماده دقیقاً متناسب با آنها پیدا نشود.
WooCommerce بهصورت رسمی امکان توسعه Extension را فراهم میکند و مستندات مستقلی برای طراحی، ساخت و توزیع افزونههای WooCommerce دارد.[۳]
برای مثال میتوان افزونهای ساخت که:
خود WooCommerce نیز Extensionهای آن را از نظر ساختار، Pluginهای WordPress میداند و توصیه میکند چنین افزونههایی از استانداردها و Best Practiceهای توسعه WordPress و WooCommerce پیروی کنند.[۳]
بعضی نیازها اصلاً به صفحه جدید یا قابلیت بزرگی احتیاج ندارند. مثلاً بعد از انتشار یک نوشته، عملیاتی مشخص اجرا شود؛ پس از تغییر وضعیت سفارش، اطلاعاتی در سیستم دیگری ثبت شود یا وقتی محصولی ناموجود شد، یک Event مشخص اتفاق بیفتد.
در این سناریو Plugin میتواند یک عملیات تکراری را به فرایندی خودکار تبدیل کند.
WordPress از طریق HTTP API و سایر ابزارهای توسعه میتواند با سرویسهای خارجی ارتباط برقرار کند.[۸]
به همین دلیل Plugin میتواند واسط میان سایت و سیستم دیگری باشد؛ داده دریافت کند، اطلاعات ارسال کند یا نتیجه یک درخواست را در WordPress نمایش دهد. همین منطق در ساخت ربات تلگرام با هوش مصنوعی نیز وجود دارد: هوش مصنوعی بهخودیخود به سرویسهای کسبوکار دسترسی ندارد و برای انجام کار واقعی، باید API و دسترسی مناسب برای سیستم تعریف شود.
همه Pluginها قرار نیست برای هزاران سایت منتشر شوند و فقط برای سایت شما ساخته میشود.
برای مثال تیم شما هر هفته یک فایل دریافت میکند و اطلاعات آن باید داخل WordPress پردازش شود، مدیر سایت یک گزارش اختصاصی میخواهد یا تیم فروش نیاز دارد اطلاعات خاصی را کنار سفارشها ببیند.
اینجا هدف ساخت یک محصول عمومی نیست؛ Plugin فقط برای حل یک مسئله مشخص کسبوکار ساخته میشود.
برای شروع ساخت یک Plugin کوچک، مسئله اصلی داشتن مجموعه بزرگی از ابزارهای توسعه نیست. چیزی که بیشترین تأثیر را روی خروجی دارد، تعریف روشن نیاز و Context مناسب برای AI است.
سه چیز برای شروع اهمیت اصلی دارند.
«یک افزونه برای سایتم میخواهم» تعریف دقیقی نیست.
اما جمله زیر مشخص است:
«میخواهم برای هر محصول WooCommerce مدت گارانتی وارد کنم و مقدار آن زیر قیمت محصول نمایش داده شود.»
در اینجا مشخص شده چه دادهای دریافت میشود و نتیجه کجا باید دیده شود.
میتوانید از ابزارهایی مانند ChatGPT، Claude، Coding Agent یا Google Gemini استفاده کنید.
نام ابزار تنها بخشی از تصمیم است. مهمتر این است که سیستم بتواند درخواست شما را همراه با Context مناسب دریافت و کد یا فایلهای لازم را تولید کند.
GitHub نیز در توضیح Coding Agentهای خود به همین ارتباط میان Prompt، Context، تولید کد و اعمال تغییرات روی Codebase اشاره میکند.[۴]
قبل از Prompt، مسئله را به سه بخش تقسیم کنید:
ورودی ← عملیات ← خروجی
برای Plugin این مقاله:
مدیر مدت گارانتی را وارد میکند ← مقدار برای همان محصول ذخیره میشود ← مدت گارانتی زیر قیمت محصول نمایش داده میشود.
این ساختار Context درخواست را برای هوش مصنوعی روشنتر میکند.
اگر مشخص نباشد ورودی چیست، قرار است روی آن چه اتفاقی بیفتد و خروجی کجا قرار است نمایش داده شود، مدل مجبور میشود بخشی از نیاز را حدس بزند.
در نتیجه قبل از فکرکردن به کد، ابتدا رفتار افزونه را ترسیم کنید.
یکی از سادهترین مسیرها برای کاربری که نمیخواهد ابتدا وارد آموزش کامل PHP و Plugin Development شود، توسعه مرحلهای با زبان طبیعی (حتی زبان مادری) است.
مسیر را میتوان اینطور نمایش داد:
ایده ← توضیح نیاز ← تولید افزونه ← نصب ← مشاهده نتیجه ← توضیح تغییر ← نسخه جدید
این الگو با Workflow ابزارهای Coding Agent هماهنگ است؛ Prompt و Context به مدل داده میشود، کد ایجاد یا تغییر میکند و سپس براساس نتیجه، Iteration بعدی انجام میشود.[۴]
برای مثال، درخواست اول میتواند این باشد:
«یک افزونه WordPress برای WooCommerce بساز که یک فیلد مدت گارانتی به صفحه ویرایش محصول اضافه کند و مقدار آن را زیر قیمت محصول نمایش دهد.»
نسخه اولیه ایجاد میشود.
بعد میگویید:
«فیلد را داخل قسمت اطلاعات محصول قرار بده.»
بعد:
«اگر گارانتی خالی است چیزی نمایش نده.»
و در مرحله بعد:
«امکان انتخاب مدت گارانتی از یک لیست را اضافه کن.»
بهجای تعریف دهها قابلیت در نسخه اول، افزونه براساس نتیجه واقعی هر مرحله توسعه پیدا میکند.
همین رویکرد در مسیر شروع برنامه نویسی از صفر نیز کاربرد دارد: پروژه کوچک انتخاب شود، نسخه اولیه ساخته شود و مفاهیم موردنیاز هنگام توسعه همان پروژه یاد گرفته شوند.
برای اینکه آموزش این راهنما فقط به توضیح نظری محدود نشود، یک نیاز واقعی را به Plugin تبدیل میکنیم.
هدف پروژه این است:
برای هر محصول WooCommerce مدت گارانتی ثبت شود و مقدار آن در صفحه محصول نمایش داده شود.
اول Workflow را مینویسیم.
مدیر وارد صفحه ویرایش محصول میشود و یک فیلد با عنوان مدت گارانتی در اختیارش قرار میگیرد.
مثلاً وارد میکند:
۱۸ ماه
هنگام ذخیره محصول، مقدار برای همان محصول ذخیره میشود.
کاربر در صفحه محصول میبیند:
مدت گارانتی: ۱۸ ماه
اگر مقداری ثبت نشده باشد، هیچ عبارت اضافهای نمایش داده نمیشود.
حالا AI مجبور نیست هدف پروژه را حدس بزند و شما به راحتی تمام نیازتان را به Ai گفتهاید.
Prompt میتواند به این شکل نوشته شود:
یک افزونه مستقل برای WordPress و WooCommerce بساز. افزونه باید در صفحه ویرایش هر محصول یک فیلد متنی با عنوان مدت گارانتی اضافه کند. مقدار واردشده برای هر محصول جداگانه ذخیره شود. اگر مقدار فیلد خالی نبود، در صفحه محصول زیر قیمت عبارت مدت گارانتی: [مقدار] نمایش داده شود. اگر مقدار وجود نداشت چیزی نمایش داده نشود. فایلهای کامل افزونه را ایجاد کن و ساختار را طوری تحویل بده که پوشه افزونه قابل ZIP و نصب از بخش Plugins وردپرس باشد. فایلهای Core وردپرس و WooCommerce را تغییر نده.
این Prompt چند اطلاعات مشخص دارد:
در یک افزونه ساده ممکن است خروجی اولیه فقط یک پوشه و یک فایل PHP اصلی باشد.
WordPress در مستندات Plugin Development توضیح میدهد که یک افزونه حتی میتواند فقط یک فایل PHP باشد و Plugin Header اطلاعات لازم برای شناسایی آن را در اختیار WordPress قرار میدهد.[۱]
برای مثال:
product-warranty/
└── product-warranty.phpفایل اصلی باید Header معتبر داشته باشد. حداقل فیلد اجباری طبق مستندات WordPress، Plugin Name است.[۲]
در این مرحله هدف آموزش خطبهخط PHP نیست؛ هدف رسیدن به نسخهای است که WordPress بتواند آن را بهعنوان Plugin شناسایی و اجرا کند.
پوشه نهایی افزونه را ZIP کنید.
در مدیریت WordPress وارد بخش افزونهها شوید، گزینه افزودن افزونه جدید و سپس بارگذاری افزونه را انتخاب کنید.
فایل ZIP را بارگذاری و Plugin را فعال کنید.
WordPress هنگام نمایش افزونههای نصبشده، فایلهای PHP دارای Plugin Header را در پوشه Plugins شناسایی میکند.[۲]
یکی از محصولات WooCommerce را ویرایش کنید.
اگر نسخه اول براساس Workflow تعریفشده تولید شده باشد، فیلد مدت گارانتی باید در بخش تعیینشده نمایش داده شود.
مثلاً مقدار زیر را وارد کنید:
۲۴ ماه
محصول را ذخیره و صفحه آن را باز کنید.
انتظار پروژه این است که خروجی زیر نمایش داده شود:
مدت گارانتی: ۲۴ ماه
اگر چنین اتفاقی افتاده باشد، نسخه اول قابلیت موردنظر ساخته شده است.
نسخه اول قرار نیست نسخه نهایی باشد.
میتوانید درخواست کنید:
«فیلد متنی گارانتی را به Select تبدیل کن و گزینههای بدون گارانتی، ۶ ماه، ۱۲ ماه، ۱۸ ماه و ۲۴ ماه داشته باشد.»
بعد:
«اگر محصول گارانتی ندارد هیچ عبارتی در Front-end نمایش نده.»
بعد:
«در تنظیمات افزونه امکان تغییر عبارت “مدت گارانتی” را برای مدیر سایت ایجاد کن.»
هر درخواست یک تغییر مشخص دارد و نتیجه آن قابل مشاهده است.
این Iteration مرحلهای باعث میشود هنگام بروز مشکل نیز راحتتر مشخص شود مشکل بعد از کدام تغییر ایجاد شده است.
فرض کنید بعداً مشخص شود بعضی محصولات گارانتی فروشگاهی و بعضی گارانتی شرکتی دارند.
Workflow جدید میشود:
نوع گارانتی + مدت گارانتی ← ذخیره اطلاعات ← نمایش نوع و مدت در صفحه محصول
حالا همین تغییر به AI داده میشود.
به این ترتیب Plugin براساس نیاز واقعی سایت رشد میکند؛ نه براساس فهرستی از قابلیتهایی که شاید هیچوقت استفاده نشوند.
مستندات GitHub درباره بررسی و استفاده از کد تولیدشده با AI روی اهمیت Context و Intent تأکید میکنند؛ یعنی مدل باید بداند کد قرار است چه مسئلهای را حل کند و چه محدودیتهایی در پروژه وجود دارد.[۵]
برای هر قابلیت، چند سؤال ساده را قبل از Prompt پاسخ دهید.
مدیر سایت، اپراتور، مشتری یا کاربر واردشده؟
متن، عدد، انتخاب از فهرست، فایل یا اطلاعات یک Product یا Order؟
ذخیره شود، محاسبه شود، برای API ارسال شود یا وضعیت دیگری را تغییر دهد؟
متنی در سایت، گزارشی در مدیریت، ایمیل یا دادهای برای سرویس دیگر؟
این سؤال در Pluginهایی که داده دریافت میکنند اهمیت بیشتری دارد.
در نتیجه بهجای:
«یک افزونه گارانتی بساز.»
درخواست زیر Context بسیار بیشتری دارد:
«در صفحه ویرایش محصول WooCommerce یک فیلد برای مدت گارانتی اضافه کن. مدیر مقدار را وارد کند، مقدار برای همان محصول ذخیره شود و فقط اگر خالی نبود زیر قیمت محصول نمایش داده شود.»
هرچه منطق محصول برای شما روشنتر باشد، بخش کمتری از رفتار Plugin به حدس مدل واگذار میشود.
صرف اینکه کد Plugin توسط AI تولید شده باشد، به معنی ناامنبودن آن نیست. از طرف دیگر، انسانیبودن نویسنده کد نیز امنیت را تضمین نمیکند.
WordPress امنیت Plugin را براساس شیوه مدیریت داده و دسترسیها بررسی میکند و در مستندات خود روی Validation، Sanitization، Escaping و کنترل دسترسی تأکید دارد.[۶]
WordPress توصیه میکند دادههای ورودی قبل از استفاده بررسی شوند و خروجی دادههای غیرقابل اعتماد نیز متناسب با Context خود Escape شود.[۶]
برای عملیات مدیریتی نیز فقط وجود Nonce کافی نیست؛ مستندات رسمی WordPress توضیح میدهند که Nonce نباید جای Authentication یا Authorization را بگیرد و Capability کاربر نیز باید بررسی شود.[۶]
پس پرسش اصلی این نیست:
«کد را انسان نوشته یا AI؟»
پرسش دقیقتر این است:
«کد تولیدشده برای کاری که انجام میدهد، اصول امنیتی لازم WordPress را رعایت کرده است یا خیر؟»
به همین دلیل میتوانید بخشی از استانداردهای امنیتی را نیز داخل Prompt وارد کنید:
«ورودیها را متناسب با نوع داده Validate و Sanitize کن، خروجیهای داینامیک را Escape کن و برای عملیات مدیریتی Capability مناسب و Nonce در نظر بگیر.»
خود Prompt امنیت را تضمین نمیکند. GitHub نیز در راهنمای Review کدهای تولیدشده با AI تأکید میکند که خروجی AI باید از نظر عملکرد، Intent، کیفیت، Dependencyها و آسیبپذیریهای احتمالی بررسی شود.[۵]
برای افزونه کوچک مثال این مقاله، دامنه تغییر محدود است. اما هرچه Plugin به اطلاعات کاربران، سفارش، پرداخت، آپلود فایل یا سطح دسترسی مدیریتی نزدیکتر شود، کیفیت پیادهسازی امنیتی اهمیت بیشتری پیدا میکند.
AI بودن کد ≠ ناامنبودن کد
اما:
تولیدشدن کد توسط AI ≠ تأییدشدن امنیت کد
اگر سایت WordPress دارید، احتمالاً حداقل یک کار کوچک وجود دارد که بارها با خودتان گفتهاید:
«کاش WordPress این قابلیت را هم داشت.»
برای اولین Plugin لازم نیست سراغ سیستم بزرگی بروید.
یک نیاز کوچک انتخاب کنید:
بعد فقط سه سؤال را پاسخ دهید:
ورودی چیست؟
چه اتفاقی باید بیفتد؟
خروجی چیست؟
همین سه بخش را به یک درخواست دقیق تبدیل کنید و نسخه اول Plugin را بسازید.
ابزارهای AI فاصله میان تعریف یک نیاز و تولید اولین نسخه کد را کوتاه کردهاند، اما این موضوع مسئولیت تعریف درست مسئله را حذف نکرده است.[۴]
اگر میخواهید ابتدا تصویر کاملتری از شیوه استفاده AI در توسعه نرمافزار داشته باشید، مقاله برنامه نویسی با هوش مصنوعی نقطه شروع مناسبی است. برای تجربه شکل مکالمهایتر ساخت نرمافزار نیز میتوانید سراغ وایب کدینگ بروید.
اولین Plugin لازم نیست محصولی بزرگ باشد. یک نیاز واقعی سایتتان را انتخاب کنید، منطق آن را مشخص کنید و آن را به کوچکترین افزونه قابلاجرا تبدیل کنید.
بله. مدلهای AI Coding میتوانند براساس Prompt و Context، کد تولید کنند و در توسعه قابلیتهای نرمافزاری کمک کنند. کیفیت خروجی به تعریف مسئله، Context و پیچیدگی پروژه وابسته است.[۴]
میتوانید بدون اینکه خودتان PHP را خطبهخط بنویسید، از AI برای تولید کد Plugin استفاده کنید؛ اما خود افزونه WordPress در بسیاری از موارد همچنان شامل PHP است. سادهترین Plugin طبق مستندات WordPress نیز میتواند یک فایل PHP باشد.[۱]
ابزار واحدی برای تمام پروژهها بهترین نیست. ChatGPT، Gemini، Claude و Coding Agentهای مختلف میتوانند برای این کار استفاده شوند. معیار انتخاب باید نوع Workflow، امکان ارائه Context، توانایی کار روی فایلها و پیچیدگی Plugin باشد.
اگر خروجی AI یک پوشه کامل Plugin باشد، میتوان آن را به ZIP تبدیل و از بخش افزودن افزونه در WordPress بارگذاری کرد. فایل اصلی افزونه باید Plugin Header معتبر داشته باشد تا WordPress آن را بهعنوان Plugin شناسایی کند.[۲]
امنیت را نمیتوان فقط از روی اینکه نویسنده کد AI یا انسان بوده مشخص کرد. ورودیها، خروجیها، سطح دسترسی، Nonceها و سایر بخشهای امنیتی باید متناسب با عملکرد Plugin بررسی شوند.[۶]
بله. WooCommerce بهطور رسمی امکان ساخت Extension را فراهم میکند و مستندات توسعه آن شامل ساخت، معماری، امنیت و Best Practiceهای Extensionها است.[۳]
بله. Plugin مانند هر نرمافزار دیگری میتواند تغییر کند. در روش مرحلهای میتوان از نسخه کوچک شروع کرد و هر قابلیت جدید را بهصورت یک Task مستقل به پروژه اضافه کرد.
WordPress.org انتشار Plugin را به این وابسته نکرده که کد توسط انسان یا AI نوشته شده باشد. Plugin باید قوانین مخزن را رعایت کند؛ از جمله الزامات مربوط به مجوز، خوانابودن کد، امنیت، استفاده از کتابخانهها و مسئولیت توسعهدهنده در قبال محتوای Plugin.[۷]
این محتوا با روش گردآوری، بررسی، تطبیق و بازنویسی منابع معتبر انگلیسیزبان تدوین شده است و ترجمه مستقیم یک منبع یا بیان نظر شخصی نویسنده نیست.
برای تعریف Plugin، ساختار اولیه افزونه و فلسفه توسعه بدون تغییر Core از مستندات رسمی WordPress Plugin Developer Handbook استفاده شده است. اطلاعات مربوط به Plugin Header و نحوه شناسایی افزونه توسط WordPress نیز از مستندات رسمی WordPress گردآوری شدهاند.
بخش مربوط به توسعه افزونههای WooCommerce با مستندات رسمی WooCommerce Developer بررسی شده است. برای توضیح قابلیت Coding Agentها و رابطه Prompt، Context و تولید کد از مستندات رسمی GitHub استفاده شده و بخش امنیت نیز براساس مستندات Security خود WordPress تدوین شده است.
منابع زیر در زمان تدوین محتوا بررسی شدهاند و هر Footnote داخل متن به منبع مرتبط در همین فهرست ارجاع میدهد.