ساخت MCP شخصی برای مدیریت چند سایت وردپرسی با ChatGPT؛ تجربه واقعی از صفر تا Gateway

نوع محتوا: Case Study / Build Log — مستند واقعی ساخت یک زیرساخت شخصی MCP برای مدیریت چند سایت WordPress از داخل ChatGPT.

خلاصه پروژه

هدف ما ساخت یک اتصال ساده و قابل‌اعتماد بین ChatGPT و چند سایت WordPress بود؛ اتصالی که فقط «خواندن» نباشد، بلکه در صورت اجازه بتواند محتوا را بسازد یا ویرایش کند، Bricks را بخواند و patch کند، فایل‌های قالب را با Backup و Hash Verification تغییر دهد و در عین حال عملیات خطرناک را جداگانه کنترل کند.

این کار در یک مرحله انجام نشد. ابتدا یک مسیر محلی با WP MCP AI Client و یک MCP Server روی ویندوز ساختیم. بعد برای عیب‌یابی پروتکل، MCP Inspector را وارد کار کردیم. سپس Ali WordPress Connector را توسعه دادیم تا WordPress خودش REST/OpenAPI/MCP و OAuth 2.1 ارائه کند. در اتصال مستقیم ChatGPT با خطاهای OAuth discovery، مسیرهای .well-known و WAF هاست روبه‌رو شدیم. در نهایت برای اینکه هر سایت جداگانه مجبور به درگیر شدن با OAuth و تنظیمات هاست نباشد، یک Gateway مرکزی روی Cloudflare Worker + D1 ساختیم.

نتیجه نهایی در معماری نهایی، ChatGPT فقط به یک MCP مرکزی یعنی Ali MCP Gateway وصل است. هر سایت WordPress فقط افزونه Ali WordPress Connector و یک API Key دارد. اضافه کردن سایت جدید به‌جای ساخت یک MCP جدید در ChatGPT، تبدیل شد به «نصب افزونه → ساخت کلید → Add site در Gateway → Test».

فهرست مطالب

• ۱. چرا اصلاً MCP شخصی ساختیم؟
• ۲. معماری‌های مختلفی که امتحان کردیم
• ۳. فاز اول: Local MCP روی ویندوز
• ۴. تست پروتکل با MCP Inspector
• ۵. ساخت Ali WordPress Connector
• ۶. تلاش برای اتصال مستقیم به ChatGPT و OAuth
• ۷. مشکل .well-known و WAF هاست
• ۸. تصمیم معماری: Gateway مرکزی
• ۹. استقرار Ali MCP Gateway روی Cloudflare
• ۱۰. اتصال اولین سایت به Gateway
• ۱۱. اتصال Gateway به ChatGPT
• ۱۲. تست واقعی Read / Write / Bricks / Theme Files
• ۱۳. اضافه کردن DigiKhab، ApadanaSivand و Exir
• ۱۴. مدل امنیت و Permissionها
• ۱۵. خطاهای مهم و روش حل آن‌ها
• ۱۶. چک‌لیست کامل ساخت از صفر
• ۱۷. نگهداری و عملیات روزانه

۱) چرا اصلاً MCP شخصی ساختیم؟

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

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

چیزی که از اتصال شخصی می‌خواستیم

• خواندن وضعیت WordPress، PHP، قالب فعال و قابلیت‌های Connector.
• لیست، جستجو، خواندن، ساخت و ویرایش Post/Page/CPT.
• Exact Patch به‌جای ارسال مجدد کل محتوا.
• خواندن Bricks element data و patch کردن امن با element ID و hash.
• خواندن و patch کردن فایل‌های child theme با Backup خودکار.
• تفکیک عملیات عادی از عملیات Destructive.
• قابلیت مدیریت چند سایت از یک نقطه مرکزی.
• عدم نیاز به روشن ماندن PowerShell یا کامپیوتر شخصی در استفاده روزمره.

۲) معماری‌هایی که در مسیر امتحان کردیم

نسخه A — Local Client

در اولین معماری، ChatGPT Plus/Pro از طریق Sign in with ChatGPT داخل یک کلاینت محلی استفاده می‌شد. کلاینت محلی با MCP Server روی 127.0.0.1 ارتباط داشت و MCP Server درخواست‌ها را به WordPress Bridge می‌فرستاد.

ChatGPT Plus/Pro ↓ WP MCP AI Client (Local) ↓ http://127.0.0.1:8787/mcp ↓ WP MCP Manager / Bridge ↓ WordPress

معماری اولیه محلی

نسخه B — اتصال مستقیم هر سایت به ChatGPT

بعد از اینکه Connector شخصی ساخته شد، تلاش کردیم هر سایت WordPress مستقیم به‌عنوان یک Custom MCP Server در ChatGPT ثبت شود. از نظر معماری ساده بود، اما در عمل هر سایت به OAuth discovery، مسیرهای .well-known و سازگاری WAF هاست وابسته می‌شد.

ChatGPT Custom MCP ↓ OAuth https://site.com/wp-json/ali-bridge/v1/mcp ↓ Ali WordPress Connector ↓ WordPress

نسخه C — Gateway مرکزی (معماری نهایی)

برای حل مشکل تکرار OAuth و تنظیمات هاست در هر سایت، یک Gateway مرکزی ساختیم. حالا ChatGPT فقط یک MCP می‌شناسد و Gateway به کمک API Key رمزنگاری‌شده، به هر سایت وصل می‌شود.

ChatGPT ↓ OAuth Ali MCP Gateway (Cloudflare Worker) ↓ X-Ali-Bridge-Key Ali WordPress Connector on each site ↓ WordPress / Bricks / Theme Files

چرا این معماری بهتر بود؟ OAuth و .well-known فقط برای Gateway مرکزی مدیریت می‌شود؛ هر سایت جدید فقط Connector + API Key نیاز دارد. در عین حال REST route سایت باید از شبکه Cloudflare قابل دسترس باشد.

۳) فاز اول: ساخت Local MCP روی ویندوز

این فاز برای اثبات امکان‌پذیری پروژه بسیار مهم بود. قبل از اینکه وارد OAuth و Cloudflare شویم، باید مطمئن می‌شدیم اصلاً می‌توانیم از طریق MCP به WordPress دستور بدهیم و ابزارهای واقعی بسازیم.

۳.۱ اجرای Setup

پکیج Local روی ویندوز شامل فایل‌های setup و mcp-server بود. هنگام اجرای فایل batch، ویندوز هشدار ناشناس بودن Publisher را نمایش داد. چون فایل متعلق به پکیج خودمان بود، Run را انتخاب کردیم.

Setup وابستگی‌های Node را نصب می‌کرد و سپس URL سرور MCP محلی را می‌پرسید. URL پیش‌فرض ما 127.0.0.1:8787/mcp بود.

۳.۲ خطای ساختار پوشه

در یکی از نسخه‌ها، setup.bat فایل configure-windows.ps1 را در مسیر مورد انتظار پیدا نکرد. این خطا ساده بود ولی یک نکته مهم داشت: فایل setup و اسکریپت PowerShell باید نسبت به پوشه mcp-server در همان ساختاری قرار بگیرند که پکیج انتظار دارد.

راه‌حل پوشه را دوباره با ساختار صحیح Extract کردیم و مطمئن شدیم setup.bat در مسیر درست نسبت به mcp-server قرار دارد.

۳.۳ تست Bridge و پایان Setup

بعد از اصلاح ساختار، Setup توانست اتصال WordPress Bridge را تست کند و پیام WordPress bridge connection succeeded را برگرداند. همین پیام ثابت کرد که لایه WordPress قابل دسترس است و مشکل از خود Bridge نیست.

۳.۴ انتخاب Permission Mode

در Local Client سه الگوی دسترسی داشتیم. برای کار روزمره، حالت «اجرای خودکار عملیات عادی و گرفتن تأیید برای destructive» منطقی‌ترین انتخاب بود؛ چون سرعت را بالا می‌برد ولی حذف یا Restore را خودکار نمی‌کرد.

قاعده‌ای که از همان ابتدا حفظ کردیم Destructive باید مستقل از Write باشد. امکان ویرایش محتوا نباید به‌طور ضمنی اجازه حذف، Restore یا عملیات پرریسک بدهد.

۴) عیب‌یابی MCP با MCP Inspector

وقتی یک MCP به ChatGPT وصل نمی‌شود، بهترین کار این نیست که مستقیم سراغ OAuth برویم. اول باید خود پروتکل را خارج از ChatGPT تست کنیم. برای همین از MCP Inspector استفاده کردیم.

۴.۱ اضافه کردن Server در Inspector

برای یک HTTP MCP، مسیر Add manually را انتخاب می‌کنیم. Inspector برای STDIO و HTTP تنظیمات جدا دارد.

۴.۲ خطای Failed و بررسی Network

در اولین تست HTTP، wp-mcp-manager به حالت Failed رفت. بخش Network در سمت راست Inspector دقیقاً نشان می‌داد درخواست به 127.0.0.1:8787/mcp ارسال شده ولی handshake کامل نشده است.

۴.۳ خطای text/event-stream

باز کردن مستقیم URL MCP در مرورگر هم یک خطای آموزنده داد: Client must accept text/event-stream. این خطا در واقع به ما گفت endpoint زنده است، اما مرورگر عادی هدر Accept مناسب MCP/SSE را نمی‌فرستد. بنابراین مشاهده این پیام به‌معنی خراب بودن MCP نبود.

نکته مهم MCP HTTP را با مرورگر عادی قضاوت نکنید. Inspector یا یک Client واقعی باید هدرهای پروتکل را ارسال کند.

۴.۴ اتصال موفق و Tools/List

بعد از اصلاح transport و پاسخ‌دهی، Inspector وضعیت Connected را نشان داد و پیام‌های initialize، notifications/initialized و tools/list با موفقیت عبور کردند.

در تب Tools ابزارهای واقعی WordPress مثل List WordPress sites، Get site info، Search content، Get content و Update content ظاهر شدند.

۴.۵ اولین Tool Call واقعی

یکی از تست‌های مهم، ساخت یک صفحه آزمایشی با POST به wp/v2/pages بود. ورودی JSON داخل Inspector نشان می‌داد ابزار واقعاً می‌تواند request ساختاریافته بگیرد و به WordPress بفرستد.

۴.۶ خطای sites.json

در نسخه محلی Manager، sites.json هم یک نقطه خطا بود. وقتی JSON با کاراکتر یا ساختار نامعتبر ذخیره شد، Tool Error با پیام Unexpected token گرفتیم. این مسئله نشان داد فایل config باید با JSON معتبر و بدون wrapper اضافه ذخیره شود.

۵) ساخت Ali WordPress Connector

بعد از اثبات MCP، قدم بعدی حذف وابستگی به Bridgeهای پراکنده و ساخت یک Connector اختصاصی برای WordPress بود. نتیجه، افزونه Ali WordPress Connector شد که در نسخه 0.6.0 به سطحی رسید که می‌توانست هم REST، هم OpenAPI، هم MCP و هم OAuth 2.1 را ارائه کند.

قابلیت‌هایی که در Connector پیاده شد

• REST base: /wp-json/ali-bridge/v1
• MCP endpoint: /wp-json/ali-bridge/v1/mcp
• OpenAPI endpoint برای مشاهده قرارداد ابزارها
• OAuth 2.1 با PKCE S256 و Dynamic Client Registration
• Legacy API Key برای اتصال Gateway
• Content list/get/create/update/search/exact_patch
• Post meta get/exact_patch
• Media list
• Theme file read/exact_patch با Backup
• Bricks read و batch patch با hash verification
• Rate limit و Audit Log اختیاری

در صفحه تنظیمات افزونه می‌توانستیم endpointها و Access Modeها را ببینیم. در اسکرین‌شات واقعی زیر، وضعیت OAuth به Ready (PKCE S256 + DCR) رسیده بود.

API Key و نقش آن در Gateway

Connector یک API Key با prefix مشخص تولید می‌کند. این کلید برای اتصال Gateway به سایت استفاده می‌شود و باید مثل رمز عبور نگهداری شود. اگر کلید لو رفت، از Rotate API key استفاده می‌کنیم.

امنیت API Key را داخل مقاله، اسکرین‌شات عمومی، Git یا فایل اشتراکی قرار ندهید. در این مستند هم مقدار واقعی کلیدها بازنشر نشده است.

۶) تلاش برای اتصال مستقیم Connector به ChatGPT

بعد از آماده شدن Connector، هدف جذاب‌تر این بود که مستقیم از داخل ChatGPT یک Custom MCP Server بسازیم. از منوی Add، گزینه Create custom MCP server را باز کردیم.

۶.۱ خطای OAuth discovery

Server URL روی endpoint افزونه قرار گرفت و Authentication روی OAuth بود. اما ChatGPT نتوانست تنظیمات OAuth را کشف کند و پیام Couldn’t discover OAuth settings نشان داد.

در تلاش بعدی، حتی وقتی بخش Advanced OAuth settings را باز کردیم، بعضی تنظیمات رد شدند و پیام Some app settings were rejected ظاهر شد.

۶.۲ User-Defined OAuth Client

برای تشخیص دقیق‌تر مشکل، حالت User-Defined OAuth Client را هم تست کردیم و Callback URL، Client ID و token endpoint auth method را تنظیم کردیم.

۶.۳ ورود دستی Endpointها و Scopeها

در Advanced settings مقادیر Auth URL، Token URL، Registration URL، Resource و Scopeها را دستی وارد کردیم. این مرحله برای عیب‌یابی مفید بود، چون مشخص کرد Connector قرارداد لازم را دارد ولی discovery در مسیر شبکه متوقف می‌شود.

۶.۴ OIDC لازم نبود

در یک مقطع OIDC را هم بررسی کردیم، ولی برای نیاز ما ضروری نبود. OAuth 2.1 با PKCE و DCR کافی بود؛ OIDC بیشتر برای دریافت هویت کاربر و UserInfo کاربرد دارد.

۷) گلوگاه واقعی: .well-known و WAF هاست

تا اینجا Connector از نظر کد آماده بود، اما discovery هنوز شکست می‌خورد. بررسی دقیق‌تر نشان داد درخواست‌های ChatGPT قبل از رسیدن به WordPress در لایه هاست متوقف می‌شوند.

۷.۱ مشکل .well-known

OAuth discovery به مسیرهایی مثل /.well-known/oauth-protected-resource و /.well-known/oauth-authorization-server وابسته است. روی هاست، این مسیرها قبل از WordPress با 404 پاسخ داده می‌شدند. پشتیبانی هاست دسترسی .well-known را برای دامنه فعال کرد.

۷.۲ مشکل ModSecurity / User-Agent

بعد از حل 404، لاگ WAF نشان داد درخواست‌هایی با User-Agent حاوی python توسط Rule ID 210832 در فایل 04_agents.conf با 403 مسدود می‌شوند. برای دامنه alifatemii.ir آن Rule غیرفعال شد و discovery مستقیم بالاخره کار کرد.

درس معماری اگر هر سایت مستقیم MCP Server نهایی باشد، این دردسر ممکن است برای هر هاست تکرار شود. همین تجربه دلیل اصلی رفتن به سمت Gateway مرکزی بود.

۸) تصمیم معماری: یک Gateway مرکزی برای همه سایت‌ها

در این نقطه سؤال اصلی این بود: آیا برای هر سایت جدید دوباره باید .well-known، WAF، OAuth و Custom MCP جدا بسازیم؟ پاسخ فنی این بود که می‌توانیم، اما برای مدیریت چند سایت طراحی خوبی نیست.

بنابراین Ali MCP Gateway طراحی شد. Gateway سه وظیفه اصلی دارد: ۱) احراز هویت ChatGPT در یک نقطه؛ ۲) نگهداری اطلاعات سایت‌ها و کلیدهای رمزنگاری‌شده؛ ۳) Route کردن Tool Callها به سایت درست.

مقدار / توضیح	بخش
یک Custom MCP Server / Plugin واحد	لایه ChatGPT
Cloudflare Worker	Gateway Runtime
Cloudflare D1	دیتابیس
OAuth روی Gateway	احراز هویت ChatGPT
X-Ali-Bridge-Key	احراز هویت Gateway→WordPress
Read / Write / Files / Destructive به‌صورت مستقل	سطح دسترسی

نکته مهم Gateway نیاز به PowerShell روشن ندارد. PowerShell فقط برای deploy، تغییر secret، D1 یا debug با wrangler tail لازم است.

۹) استقرار Ali MCP Gateway روی Cloudflare

Gateway در پکیج ali-mcp-gateway-v1.0.0 روی ویندوز آماده شد. مسیر کاری ما روی Windows داخل Downloads بود. مراحل زیر بازسازی دقیق همان Deploy است، با این تفاوت که مقادیر secret و شناسه‌های حساس با placeholder نوشته شده‌اند.

۹.۱ ورود به پوشه و نصب dependencyها

cd C:\Users\User\Downloads\ali-mcp-gateway-v1.0.0\ali-mcp-gateway-v1.0.0 npm install

۹.۲ ساخت D1 Database

npx wrangler d1 create ali-mcp-gateway

Wrangler یک database_id برمی‌گرداند. همان ID باید در wrangler.toml و binding مربوط به DB قرار گیرد. شناسه واقعی پروژه را در نسخه عمومی مقاله بازنشر نمی‌کنیم.

۹.۳ اجرای schema.sql

npx wrangler d1 execute ali-mcp-gateway –remote –file=.\schema.sql

اجرای موفق Schema جداول موردنیاز برای سایت‌ها، OAuth و تنظیمات را در D1 ایجاد می‌کند.

۹.۴ تعریف Secretها

npx wrangler secret put ADMIN_PASSWORD npx wrangler secret put SESSION_SECRET npx wrangler secret put MASTER_KEY

ADMIN_PASSWORD برای ورود به پنل مدیریت Gateway است. SESSION_SECRET برای session و MASTER_KEY برای رمزگذاری secretهای ذخیره‌شده استفاده می‌شود. این مقادیر نباید داخل wrangler.toml یا Git قرار بگیرند.

۹.۵ Deploy

npx wrangler deploy

بعد از Deploy، Worker یک آدرس workers.dev می‌دهد. در پروژه ما health endpoint را با curl.exe تست کردیم. در PowerShell بهتر است curl.exe را صریح بنویسید تا alias داخلی PowerShell مزاحم نشود.

curl.exe -i “https://YOUR-WORKER.workers.dev/health”

پاسخ مورد انتظار HTTP 200 و JSON شبیه {“ok”:true,”service”:”Ali MCP Gateway”,”version”:”1.0.0″,…}

۱۰) اتصال اولین سایت WordPress به Gateway

بعد از بالا آمدن Worker، وارد پنل Ali MCP Gateway شدیم. در شروع هیچ سایتی ثبت نشده بود. فرم Add site سه داده اصلی می‌خواهد: Name، Site URL و Ali Connector API key. در کنار آن سه Permission Ceiling برای Write، Theme Files و Destructive وجود دارد.

۱۰.۱ تست status endpoint قبل از Add

اگر Add and verify خطا می‌دهد، بهترین تست این است که دقیقاً همان Endpoint و Headerهای Gateway را از PowerShell بفرستید.

$KEY = Read-Host “Paste Ali Connector API key” curl.exe -i “https://alifatemii.ir/wp-json/ali-bridge/v1/status” ` -H “Accept: application/json” ` -H “User-Agent: Ali-MCP-Gateway/1.0” ` -H “X-Ali-Bridge-Key: $KEY” Remove-Variable KEY

در پروژه ما این تست HTTP 200 گرفت و WordPress 7.1.2، PHP 8.1.34 و قالب Planner Studio — Bricks Child را برگرداند. بنابراین خود Connector و API Key سالم بودند.

۱۰.۲ خطای 522

در یکی از تست‌های اولیه، Add and verify از Gateway خطای 522 گرفت. نکته مهم این بود که همین endpoint از اینترنت عادی 200 می‌داد؛ بنابراین مسیر Worker→Origin باید جدا بررسی می‌شد.

اگر 522 برگشت بررسی کنید سایت پشت Cloudflare است یا نه، A/AAAA چه هستند، WAF یا Anti-DDoS ورودی شبکه Cloudflare را محدود نکرده باشد و endpoint /wp-json/ali-bridge/v1/status از بیرون قابل دسترس باشد.

۱۰.۳ ثبت موفق سایت

بعد از رفع مسیر اتصال، alifatemii با موفقیت در Gateway ثبت شد. همان پنل حالا سایت و permissionهای آن را نشان می‌داد.

۱۱) اتصال Gateway به ChatGPT

از اینجا به بعد دیگر لازم نبود هر سایت WordPress را جدا به ChatGPT معرفی کنیم. فقط Gateway را یک‌بار به‌عنوان Custom MCP Server/Plugin ساختیم.

مقدار / توضیح	بخش
Ali WordPress Manager	Name
https://YOUR-WORKER.workers.dev/mcp	Server URL
OAuth	Authentication
Dynamic Client Registration (DCR)	Registration
Off	OIDC
wp:read	Default scope پیشنهادی

بعد از OAuth approval، اولین تست فقط Read بود: «سایت‌های WordPress متصل به Gateway را لیست کن. هیچ تغییری ایجاد نکن.» سپس وضعیت alifatemii خوانده شد و نسخه WordPress، PHP و قالب فعال دقیقاً برگشت.

قاعده تست همیشه اتصال جدید را با Read-only شروع کنید. بعد از موفق شدن، Write را فعال کنید. Theme Files و Destructive را آخر از همه بالا ببرید.

۱۲) تست واقعی قابلیت‌ها بعد از اتصال

۱۲.۱ Read

site_status روی alifatemii با موفقیت WordPress 7.1.2، PHP 8.1.34 و Planner Studio — Bricks Child را برگرداند. این یعنی مسیر ChatGPT → Gateway → Connector → WordPress از ابتدا تا انتها سالم بود.

۱۲.۲ Write

برای تست Write یک Draft با عنوان Gateway Write Test ساخته شد و سپس همان Draft دوباره خوانده شد. وضعیت draft باقی ماند و هیچ چیزی publish نشد. این تست ثابت کرد عملیات Create و Read-after-write کار می‌کند.

۱۲.۳ Bricks Read

برای صفحه اصلی alifatemii با ID 1525، ابزار Bricks توانست 389 element را بخواند و یک verification hash برگرداند. دریافت hash مهم است چون patch بعدی می‌تواند قبل از Commit بررسی کند داده از زمان Read تغییر نکرده باشد.

۱۲.۴ Theme Files Read

فایل style.css قالب child با موفقیت خوانده شد؛ اندازه 32694 بایت و hash فایل برگشت. همین تست نشان داد Gateway permission فایل و Connector file mode هر دو درست تنظیم شده‌اند.

۱۲.۵ Theme File Patch با Dry Run

برای اطمینان از امنیت patch، یک exact-match patch با dry_run=true اجرا شد. سیستم match_count=1 و before_hash/after_hash فرضی را برگرداند، اما بعد از dry run فایل دوباره خوانده شد و hash واقعی تغییر نکرد. این تست یکی از مهم‌ترین تست‌ها بود چون نشان داد می‌توان تغییر را پیش‌نمایش کرد بدون اینکه فایل واقعی دست بخورد.

الگوی امن ویرایش فایل Read → ذخیره Hash → Dry Run → بررسی match_count و after_hash → Commit واقعی → Read مجدد → در صورت نیاز Restore از Backup.

۱۳) تبدیل شدن سیستم به مدیریت چندسایتی

بعد از موفق شدن alifatemii، اضافه کردن سایت‌های بعدی بسیار سریع شد. دیگر هیچ Custom MCP جدیدی داخل ChatGPT نساختیم؛ فقط همان فایل Ali WordPress Connector 0.6.0 روی سایت جدید نصب شد، API Key تولید شد و رکورد سایت در Gateway ساخته شد.

مقدار / توضیح	بخش
متصل؛ Read/Write/Bricks/Theme Files تست شد	alifatemii
متصل؛ WordPress 7.1.2، PHP 8.1.34، Woodmart Child	digikhab
متصل؛ WordPress 7.1.2، PHP 8.1.34، Woodmart	apadanasivand
متصل؛ WordPress 7.1.2، PHP 8.1.34، Woodmart	exir

در این مرحله مهم‌ترین نتیجه معماری مشخص شد: برای کار روزمره PowerShell دیگر لازم نیست باز باشد. Worker ابری مستقل از سیستم شخصی اجرا می‌شود.

روش استاندارد اضافه کردن سایت جدید

1) فایل ali-wordpress-connector-v0.6.0 را در WordPress نصب و Activate کن.

2) از Tools → Ali WordPress Connector وارد صفحه تنظیمات شو.

3) Writes و Advanced را بر اساس نیاز روشن کن. Theme Files فقط وقتی واقعاً لازم است.

4) Destructive را پیش‌فرض خاموش نگه دار.

5) API Key بساز یا Rotate کن و فقط همان لحظه کپی کن.

6) در Gateway نام کوتاه و واضح سایت، URL و API Key را وارد کن.

7) Gateway permission ceiling را تنظیم کن.

8) Add and verify site را بزن.

9) از داخل ChatGPT sites_list و site_status را اجرا کن و هیچ تغییری نده.

10) بعد از موفقیت، Write را با ساخت Draft تست کن.

۱۴) مدل امنیت و Permissionها

یکی از مهم‌ترین تصمیم‌های فنی پروژه، دو لایه کردن Permission بود. فقط روشن بودن قابلیت در WordPress کافی نیست؛ Gateway هم باید اجازه همان عملیات را بدهد. این یعنی Gateway یک سقف اضافه روی دسترسی سایت ایجاد می‌کند.

مقدار / توضیح	بخش
پایه و کم‌ریسک؛ برای status، content، meta، media و Bricks read	Read
ساخت/ویرایش محتوا و patchهای غیر destructive	Write
عملیات پیشرفته Connector مانند Bricks و exact patch	Advanced
خواندن و patch کردن فایل‌های child theme؛ بهتر است فقط زمان نیاز روشن باشد	Theme Files
Restore/Delete و عملیات خطرناک؛ پیش‌فرض خاموش	Destructive

یک نکته از تست فعلی در یکی از بررسی‌های Gateway، alifatemii برای مدتی allow_destructive=true دیده شد. در استفاده واقعی بهتر است این گزینه فقط هنگام Restore یا عملیات مشخص روشن شود و بعد دوباره خاموش گردد.

۱۵) خطاهای مهمی که واقعاً دیدیم و راه‌حلشان

راه‌حل	علت	خطا
پکیج را با ساختار اصلی Extract کنید و setup را از همان Root اجرا کنید.	ساختار Extract پکیج غلط بود یا setup.bat کنار مسیر مورد انتظار نبود.	configure-windows.ps1 was not found
با MCP Inspector یا Client واقعی تست کنید؛ این پیام ثابت می‌کند endpoint زنده است.	URL MCP را با مرورگر عادی باز کرده بودیم.	Client must accept text/event-stream
تب Network و Protocol را بررسی و initialize/tools/list را جدا تست کنید.	Handshake/transport یا server process کامل نبود.	MCP Inspector: Failed
JSON را validate و فایل را UTF-8 با ساختار خالص JSON ذخیره کنید.	فایل JSON نامعتبر یا با wrapper اضافه ذخیره شده بود.	sites.json Unexpected token
protected-resource و authorization-server را مستقیم تست کنید و لاگ WAF را ببینید.	مسیر .well-known از هاست قابل دسترس نبود یا WAF جلوی درخواست را می‌گرفت.	Couldn’t discover OAuth settings
Rule مشخص دامنه را در هاست disable/allow کنید؛ از whitelist بی‌قاعده خودداری کنید.	ModSecurity User-Agent شامل python را بلاک می‌کرد.	403 روی OAuth/MCP
A/AAAA، proxy، Firewall و route /wp-json/ali-bridge/v1/* را بررسی کنید.	Worker توان اتصال به origin را نداشت یا upstream Cloudflare/Firewall دخالت داشت.	Connection test failed: HTTP 522
از curl.exe استفاده کنید.	curl در PowerShell می‌تواند alias Invoke-WebRequest باشد.	PowerShell curl رفتار عجیب

۱۶) نسخه اجرایی: اگر بخواهی امروز از صفر همین سیستم را بسازی

مرحله A — WordPress Connector

1) روی یک سایت آزمایشی WordPress شروع کن، نه سایت تولیدی حساس.

2) Ali WordPress Connector 0.6.0 را نصب و Activate کن.

3) status endpoint را بدون secret تست نکن؛ از API Key و هدر درست استفاده کن.

4) Read را اول تست کن.

5) اگر Bricks یا Theme Files لازم داری، modeهای مربوط را روشن کن.

مرحله B — Gateway

1) Cloudflare account و Wrangler را آماده کن.

2) D1 Database بساز و database_id را در wrangler.toml بگذار.

3) schema.sql را روی Remote D1 اجرا کن.

4) ADMIN_PASSWORD، SESSION_SECRET و MASTER_KEY را به‌صورت secret تنظیم کن.

5) Worker را deploy کن و /health را تست کن.

مرحله C — ثبت سایت

1) API Key Connector را بساز.

2) در Gateway: Name، Site URL و API Key را وارد کن.

3) Write/Files/Destructive را به‌عنوان Gateway ceiling تعیین کن.

4) Add and verify را بزن.

5) اگر خطا بود، ابتدا /status را با همان Headerهای Gateway از PowerShell تست کن.

مرحله D — ChatGPT

1) یک Custom MCP Server برای Gateway بساز.

2) Server URL را روی /mcp خود Worker بگذار.

3) OAuth + DCR را استفاده کن؛ OIDC لازم نیست.

4) اول sites_list و site_status را اجرا کن.

5) بعد یک Draft بساز و دوباره بخوان.

6) بعد Bricks read و Theme File read را تست کن.

7) در نهایت Dry Run patch را اجرا کن.

تست نهایی موفق یعنی چه؟ وقتی بدون PowerShell روشن بتوانی از ChatGPT وضعیت چند سایت را بخوانی، روی سایت انتخابی Draft بسازی، Bricks و Theme Files را بخوانی و یک patch dry-run با hash verification بگیری، معماری اصلی کامل است.

۱۷) استفاده و نگهداری روزانه

بعد از Deploy، کار روزانه بسیار ساده‌تر از مرحله ساخت است. PowerShell نباید روشن بماند. فقط در موارد زیر دوباره به Wrangler/PowerShell نیاز دارید:

• Deploy نسخه جدید Gateway
• تغییر Secretها
• مهاجرت یا Query مستقیم D1
• مشاهده لاگ زنده با wrangler tail
• عیب‌یابی Worker یا ارتباط Worker→WordPress

روال پیشنهادی برای تغییرات حساس

• قبل از ویرایش صفحه Bricks، bricks_read و hash را بگیر.
• برای patch فایل، ابتدا theme_file_read و hash را بگیر.
• Dry Run را برای patch اجرا کن.
• پس از Commit، همان منبع را دوباره بخوان و نتیجه را verify کن.
• Destructive را فقط برای Restore روشن کن و پس از اتمام خاموش کن.

۱۸) جمع‌بندی تجربه

چیزی که این پروژه را جالب کرد فقط «وصل کردن WordPress به ChatGPT» نبود. ارزش اصلی تجربه در این بود که چند لایه متفاوت را کنار هم فهمیدیم: پروتکل MCP، Transportهای HTTP/STDIO، رفتار Inspector، REST WordPress، OAuth 2.1، DCR، PKCE، مسیرهای .well-known، WAF هاست، Cloudflare Worker، D1، مدیریت Secret و در نهایت طراحی Permission.

نسخه اول وابسته به کامپیوتر محلی بود. نسخه دوم از نظر UX بهتر بود ولی برای هر سایت OAuth و هاست را تکرار می‌کرد. نسخه نهایی با Gateway مرکزی این دو مشکل را حل کرد و سیستم را به یک زیرساخت واقعی چندسایتی تبدیل کرد.

الان مسیر نهایی برای اضافه کردن سایت جدید بسیار کوتاه است: Connector را نصب کن، API Key بساز، سایت را در Gateway اضافه و Verify کن. ChatGPT از همان Ali WordPress Manager مرکزی می‌تواند سایت جدید را ببیند. این دقیقاً همان نقطه‌ای است که پروژه از «آزمایش MCP» به «ابزار عملی روزمره» تبدیل شد.

معماری نهایی در یک خط ChatGPT → Ali MCP Gateway → Ali WordPress Connector → WordPress

ضمیمه A — Promptهای پیشنهادی برای تست

نمونه Prompt سایت‌های WordPress متصل به Gateway را لیست کن. هیچ تغییری ایجاد نکن.

نمونه Prompt وضعیت سایت alifatemii را بررسی کن و نسخه WordPress، PHP و قالب فعال را بگو. هیچ تغییری نده.

نمونه Prompt یک نوشته Draft با عنوان Gateway Write Test بساز، منتشرش نکن، بعد همان Draft را دوباره بخوان و تأیید کن.

نمونه Prompt صفحه اصلی را از طریق Bricks فقط Read-only بررسی کن و تعداد elementها و hash را بگو.

نمونه Prompt فایل style.css قالب فرزند را فقط بخوان و size و hash را گزارش کن.

نمونه Prompt یک Theme File Patch آزمایشی با dry-run انجام بده؛ هیچ تغییری واقعی اعمال نکن.

ضمیمه B — نکات انتشار عمومی این مقاله

• API Key، Application Password، ADMIN_PASSWORD، SESSION_SECRET و MASTER_KEY را هرگز منتشر نکن.
• اگر اسکرین‌شات جدیدی اضافه می‌کنی، قبل از انتشار Tokenها و ایمیل/شناسه‌های حساس را Mask کن.
• Worker URL به‌خودی‌خود secret نیست، اما در مقاله عمومی بهتر است از YOUR-WORKER به‌عنوان مثال استفاده شود.
• هر API Key که قبلاً در چت یا اسکرین‌شات عمومی دیده شده بهتر است Rotate شود.