WordPress Playground وردپرس را در محیط ایزوله مرورگر یا Runtime آزمایشی اجرا میکند. اتصال MCP به Agent اجازه میدهد نمونه بسازد، افزونه را آزمایش کند و نتیجه را بدون دستزدن به سایت اصلی نشان دهد.
چرا Playground برای Agent مهم است؟
AI ممکن است چند فایل و تنظیم را همزمان تغییر دهد. Sandbox موقت، محدوده آسیب را کوچک میکند و Preview قابل مشاهده میسازد. Playground جای Backup سایت اصلی نیست، اما مرحله آزمایش را سریعتر میکند.
جریان پیشنهادی
- Blueprint یا سایت نمونه با نسخه دقیق WordPress بسازید.
- افزونه و داده غیرحساس را وارد کنید.
- MCP Client را فقط به محیط Playground وصل کنید.
- تغییر را اجرا و خروجی Desktop و Mobile را بررسی کنید.
- Patch تأییدشده را از مسیر انتشار معمول به Stage منتقل کنید.
Agent آزمایشی را با کلید محدود اجرا کنید.
مدل، سقف هزینه و Tool Calling را روی داده غیرحساس بسنجید.
مرز داده و امنیت
اطلاعات مشتری، Cookie واقعی و Secret production را وارد Playground نکنید. ابزارهای نوشتن را محدود و اجرای فرمان را ثبت کنید. منبع رسمی قابلیت در یادداشت توسعهدهندگان WordPress Playground MCP معرفی شده است.
مدل موردنیاز
Agent برای تصمیمگیری به مدل نیاز دارد. اگر Client شما endpoint سازگار میپذیرد، در API پاستا کلید محدود بسازید و Tool Calling را با پروژه نمونه بسنجید.
انتقال به محیط پایدار
پس از تأیید، تغییر را روی Stage دارای MySQL و فایل ماندگار اجرا کنید. هاست وردپرس برای سایت پایدار است؛ Playground محیط آزمایش کوتاهعمر باقی میماند.
Playground در معماری توسعه کجا قرار میگیرد؟
Playground محیط ساخت و آزمایش کوتاهعمر است. Stage نسخه نزدیک به production و Production سایت واقعی است. Agent باید ابتدا روی Playground تغییر را کشف کند، سپس Patch یا بسته افزونه را به Stage ببرد. انتقال مستقیم دیتابیس موقت Playground به سایت اصلی معمولاً مسیر قابل حسابرسی و قابل بازگشت نمیسازد.
| محیط | کاربرد | داده مجاز |
|---|---|---|
| Playground | نمونهسازی و تست سریع | داده ساختگی |
| Stage | آزمون سازگاری و پذیرش | نسخه ناشناسشده |
| Production | سرویس واقعی | داده مشتری با کنترل کامل |
ساخت Workflow تکرارپذیر
- نسخه WordPress، PHP، Theme و Pluginها را در Blueprint ثابت کنید.
- داده نمونهای بسازید که حالت عادی و مرزی را پوشش دهد.
- Agent را فقط به همان instance وصل کنید و Task دقیق بدهید.
- خروجی را با آزمون خودکار، Screenshot موبایل و دسکتاپ و بررسی دسترسپذیری بسنجید.
- تغییر پذیرفتهشده را به فایل، Patch یا نسخه افزونه تبدیل کنید.
- همان Artifact را در Stage نصب کنید؛ Agent نباید تغییر را از حافظه بازسازی کند.
اتصال مدل با API پاستا
برای آزمایش Agent یک کلید جدا در پنل AI پاستا بسازید. سقف مصرف پایینتری برای Playground بگذارید و مدل را در Playground مدلها با Task واقعی بسنجید. این محیط مدل با WordPress Playground یکی نیست: اولی برای آزمون API مدل است و دومی WordPress را ایزوله اجرا میکند. ترکیب آنها یک مسیر امن برای تست Agent میسازد.
انتقال به هاست وردپرس پاستا
Stage و production را روی هاست وردپرس پاستا با MySQL و Volume پایدار نگه دارید. Secretهای production فقط در محیط مقصد تعریف شوند. Artifact تأییدشده را منتشر کنید، Migration لازم را ثبت کنید و پیش از تغییر دیتابیس Backup بگیرید. نتیجه را با Smoke Test ورود، ویرایش، فرم و مسیر خرید بررسی کنید.
محدودیتهایی که باید بپذیرید
رفتار فایل، شبکه و extensionهای PHP در Playground ممکن است دقیقاً مانند سرور نباشد. آزمون مرورگر جای آزمون Stage را نمیگیرد. عملکرد و Core Web Vitals را هم باید روی زیرساخت نزدیک به production اندازه گرفت. Playground ریسک نمونهسازی را کم میکند، نه اینکه همه تفاوتهای محیط را حذف کند.
خطایابی
- اگر Blueprint اجرا نمیشود، نسخه و URL منبع را Pin و خطا را بدون Agent تکرار کنید.
- اگر تغییر بعد از Reload از بین میرود، آن را به Artifact خروجی تبدیل نکردهاید.
- اگر MCP Client ابزار اشتباه را میزند، Toolها را کم و نام و Schema را دقیق کنید.
- اگر Stage متفاوت است، فهرست نسخهها و تنظیمات دو محیط را Diff کنید.