WordPress 7.0 به معنی کنار گذاشتن معماری شناخته‌شده وردپرس و تبدیل اجباری تمام سایت‌ها به Headless نیست. سایت‌ها همچنان با هسته، قالب، افزونه و پایگاه داده خود کار می‌کنند. تغییرهای این انتشار به تجربه ویرایش، ابزارهای توسعه و زیرساخت اتصال به هوش مصنوعی مربوط‌اند. اگر مدیر یک سایت موجود هستید، پرسش اصلی این است که کدام تغییر روی کار روزانه شما اثر دارد و برای ارتقا چه وابستگی‌هایی باید بررسی شوند.
این راهنما تا ۱۰ اکتبر ۲۰۲۶ به‌روزرسانی شده است. طبق آرشیو رسمی انتشارها، شاخه جدیدتر 7.1 نیز منتشر شده و نسخه 7.1.3 در دسترس است. بنابراین 7.0 را به‌عنوان نقطه شروع یک مجموعه تغییر بررسی می‌کنیم، نه آخرین نسخه امروز. برای نگهداری سایت باید انتشارهای امنیتی و سازگاری محیط واقعی را دنبال کنید؛ شماره نسخه مقاله به‌تنهایی برنامه ارتقای شما را تعیین نمی‌کند.
چه چیزهایی در نسخه هفت تغییر کردند؟
Field Guide رسمی 7.0 تغییرها را در چند حوزه معرفی می‌کند: ابزارهای اتصال AI، بهبود محیط مدیریت و ویرایش، قابلیت‌های طراحی بلوک و APIهای توسعه. برای مثال، WP AI Client و Connectors API برای ارتباط با ارائه‌دهندگان مدل معرفی شده‌اند. این لایه‌ها به افزونه‌ها ابزار می‌دهند؛ وجودشان به معنی تولید خودکار تمام محتوای سایت یا رایگان بودن هر سرویس متصل نیست.
در محیط مدیریت، تغییرهای بصری و امکاناتی برای کار با محتوا و طراحی مطرح شده‌اند. برای توسعه‌دهنده، APIهای مربوط به بلوک‌ها و تعامل نیز اهمیت دارند. این مجموعه را با «بازنویسی کامل وردپرس» اشتباه نگیرید. یک نسخه اصلی ممکن است چندین رفتار را تغییر دهد، اما نمی‌توان از شماره آن نتیجه گرفت که همه افزونه‌ها باید از ابتدا نوشته شوند یا تمام قالب‌ها دیگر قابل استفاده نیستند. هر وابستگی باید جداگانه بررسی شود.
هسته، قالب و افزونه سه مسئولیت متفاوت دارند
هسته وردپرس امکانات پایه مدیریت محتوا را فراهم می‌کند. قالب روی نمایش و سازمان‌دهی ظاهر سایت اثر دارد و افزونه رفتار یا قابلیت تازه اضافه می‌کند. این تفکیک در زمان ارتقا کاربردی است: اگر صفحه‌ای بعد از تغییر نسخه مشکل دارد، علت می‌تواند در تعامل این بخش‌ها باشد. نسبت دادن هر خطا به نسخه هسته، مسیر بررسی را طولانی می‌کند. ابتدا مشخص کنید مشکل در ویرایش محتواست، در نمایش عمومی یا در یک عملیات افزونه.
در یک سایت محتوایی، بهتر است اطلاعات مقاله وابسته به ظاهر یک قالب خاص نباشد. اگر با تغییر قالب، ساختار مهم داده از بین می‌رود، مرز مسئولیت‌ها درست طراحی نشده است. برای سایت جدید، پیش از انتخاب افزونه‌ها فهرست نیازهای واقعی را بنویسید: نوع محتوا، نقش نویسندگان، جست‌وجو، فرم‌ها و مسیر انتشار. نصب چند ابزار مشابه برای یک نیاز، الزاماً انعطاف بیشتری ایجاد نمی‌کند و ممکن است تعارض و هزینه نگهداری را بالا ببرد.
Block Editor و Site Editor را جدا بشناسید
Block Editor محیط کار با محتوای بلوکی است. Site Editor در قالب‌های بلوکی امکان کار با بخش‌هایی از ساختار و طراحی سایت را فراهم می‌کند. استفاده از یکی، به معنی برخورداری یکسان همه قالب‌ها از دیگری نیست. اگر سایت شما قالب کلاسیک یا یک صفحه‌ساز افزونه‌ای دارد، مسیر ویرایش آن ممکن است با یک قالب بلوکی متفاوت باشد. نخست نوع قالب و نقش ابزارهای فعلی را روشن کنید.
برای تیم تحریریه، قابلیت تازه وقتی مفید است که وظیفه روزمره را ساده‌تر کند. نویسنده باید بتواند عنوان، تصویر، توضیح و لینک را بدون دستکاری ساختار کلی صفحه تنظیم کند. در مقابل، تغییر header یا الگوی نمایش مقاله بهتر است در اختیار نقش مسئول طراحی باشد. تقسیم دسترسی‌ها را بر اساس مسئولیت انجام دهید؛ دسترسی گسترده برای رفع یک مشکل موقت ممکن است بعداً باعث تغییر ناخواسته ساختار سایت شود.
اگر الگوی ثابت مقاله می‌سازید، آن را با محتوای واقعی بررسی کنید: عنوان فارسی بلند، فهرست چندبخشی، تصویر با نسبت متفاوت و پاراگراف دارای اصطلاح انگلیسی. نمونه کوتاه نمایشی، ضعف‌های ساختار را پنهان می‌کند. برای تصمیم درباره صفحه مقاله، راهنمای طراحی سایت محتوایی و بلاگ کمک می‌کند نیاز خواننده و نویسنده را کنار ظاهر صفحه ببینید.
AI Client به معنی انتخاب خودکار مدل مناسب نیست
یک لایه مشترک برای ارتباط با مدل‌ها می‌تواند کار توسعه افزونه را منظم‌تر کند. اما تیم سایت همچنان باید هدف استفاده، داده ارسال‌شده و هزینه را مشخص کند. تولید پیش‌نویس عنوان با تحلیل یک فایل محرمانه مسئله یکسانی ندارد. اگر از سرویس بیرونی استفاده می‌کنید، مشخص کنید چه داده‌ای از سایت خارج می‌شود و نتیجه قبل از انتشار کجا بازبینی خواهد شد.
برای مثال، ابزار پیشنهاد توضیح تصویر می‌تواند نویسنده را در شروع کار کمک کند، ولی alt باید با تصویر واقعی و نقش آن در صفحه تطبیق داشته باشد. توصیف طولانی ولی نادرست، دسترسی‌پذیری را بهتر نمی‌کند. متن تبلیغاتی تولیدشده نیز باید با خدمت واقعی کسب‌وکار هماهنگ باشد. مدل نمی‌تواند صرف داشتن دسترسی به صفحه، مجوز انتشار ادعا درباره قیمت، تضمین یا نتیجه مشتری را به دست بیاورد.
کلید سرویس را در فایل عمومی، کد مرورگر یا توضیحات یک مقاله قرار ندهید. سطح دسترسی اتصال را با کار مورد نیاز هماهنگ کنید و امکان قطع آن را داشته باشید. همچنین اختلاف پاسخ مدل‌ها را در طراحی تجربه حساب کنید: خروجی ممکن است ناقص، نامعتبر یا نیازمند اصلاح باشد. یک جریان کاری مناسب، مرحله بررسی و وضعیت خطا دارد؛ صرف افزودن دکمه «تولید» تجربه قابل اعتماد ایجاد نمی‌کند.
Headless یک انتخاب معماری است
در معماری Headless، مدیریت محتوا از رابط نمایش جدا می‌شود. وردپرس می‌تواند محتوا را فراهم کند و برنامه دیگری آن را نمایش دهد. اما این انتخاب با فعال شدن نسخه هفت اجباری نمی‌شود. یک سایت معمولی که قالب وردپرس آن را رندر می‌کند، همچنان مسیر معتبر و قابل نگهداری است. جداسازی رابط وقتی ارزش دارد که نیاز محصول و توان نگهداری آن روشن باشد.
در Headless، مسئولیت‌هایی مثل پیش‌نمایش محتوا، مدیریت مسیرها، Cache، metadata و وضعیت ورود باید میان دو بخش هماهنگ شوند. استفاده از فریم‌ورک جدید، این وظایف را حذف نمی‌کند. اگر تیم فقط برای انتشار چند مقاله به این معماری فکر می‌کند، هزینه عملیاتی را با سود واقعی مقایسه کنید. برای تیمی که چند خروجی مستقل دارد، جداسازی ممکن است منطقی‌تر باشد، ولی باز هم به طراحی قرارداد داده نیاز دارد.
REST API وردپرس مسیر رسمی شناخته‌شده‌ای برای کار با داده فراهم می‌کند. وجود آن به معنی اضافه شدن خودکار GraphQL به هسته نیست. اگر پروژه شما GraphQL دارد، باید ابزار فراهم‌کننده آن و وضعیت پشتیبانی‌اش را جدا مشخص کنید. خواننده نباید از یک مقاله درباره هسته، انتظار API افزونه‌ای را بدون نصب وابستگی پیدا کند.
ارتقای سایت موجود: از فهرست وابستگی‌ها شروع کنید
پیش از ارتقا، نسخه PHP و پایگاه داده، قالب، افزونه‌های ضروری و تغییرات سفارشی را ثبت کنید. برای فروشگاه، مسیر سفارش و پرداخت مهم است؛ برای سایت عضویت، ورود و دسترسی؛ برای سایت محتوایی، ویرایش و انتشار. به جای بررسی تصادفی همه صفحات، چند سناریوی اصلی محصول را انتخاب کنید. این کار کمک می‌کند پس از تغییر بدانید رفتار مهم سایت حفظ شده یا خیر.
ادعای سازگاری یک افزونه را از مستندات و انتشارهای خود آن بررسی کنید. نام شناخته‌شده افزونه، مدرک سازگاری با تمام ترکیب‌های ممکن نیست. افزونه ممکن است با هسته سازگار باشد، ولی با نسخه قدیمی یک افزونه دیگر تعارض داشته باشد. تنظیمات اختصاصی و کدهای تیم شما نیز بخشی از محیط هستند. برای همین، تصمیم ارتقا نباید فقط بر اساس یک فهرست عمومی «افزونه‌های محبوب» گرفته شود.
برای مدیریت واقعی یک ارتقا، نسخه پشتیبان قابل بازیابی و محیط جداگانه ارزش دارند. این توصیه درباره نگهداری سایت شماست و نباید با ساخت چند فایل تکراری بی‌هدف اشتباه گرفته شود. دانستن اینکه نسخه پشتیبان وجود دارد کافی نیست؛ تیم باید بداند چه کسی، با چه دسترسی و در چه شرایطی آن را برمی‌گرداند. برنامه برگشت مخصوصاً وقتی تغییر داده یا پرداخت وجود دارد، باید روشن باشد.
عملکرد، فارسی و تجربه ویرایش
ارتقای هسته الزاماً همه صفحات را سریع‌تر نمی‌کند. تعداد و رفتار افزونه‌ها، کیفیت قالب، حجم تصاویر و تنظیمات Cache روی نتیجه اثر دارند. اگر صفحه کند است، مشکل را با شواهد تفکیک کنید: پاسخ اولیه سرور، دریافت منابع یا اجرای کد در مرورگر. راهنمای PageSpeed Insights برای خواندن همین تفاوت‌ها مفید است؛ یک امتیاز را جای تشخیص علت نگذارید.
برای سایت فارسی، چیدمان RTL، نمایش هم‌زمان فارسی و انگلیسی، اعداد، فاصله‌های متن و فونت را در محیط عمومی و مدیریت بررسی کنید. یک قالب زیبا در نمونه انگلیسی ممکن است در عنوان فارسی چندخطی به مشکل بخورد. مقاله تایپوگرافی فارسی برای طراحان کمک می‌کند این تصمیم‌ها را به اندازه و وزن فونت محدود نکنید.
چه زمانی به نسخه جدید مهاجرت کنیم؟
برای سایت فعال، دنبال کردن انتشارهای امنیتی و سازگاری وابستگی‌ها بخشی از نگهداری عادی است. زمان مهاجرت را با اهمیت مسیرهای سایت، وضعیت افزونه‌ها و توان تیم هماهنگ کنید. نه ماندن بی‌برنامه روی نسخه قدیمی تصمیم خوبی است و نه ارتقای عجولانه بدون شناخت محیط. تفاوت این دو را با یک برنامه مشخص حل کنید: وابستگی‌های حساس، مسئول انجام کار و سناریوهای لازم برای حفظ رفتار را بنویسید.
نسخه هفت وردپرس ابزارها و امکانات تازه‌ای آورده، اما انتخاب معماری، کیفیت محتوا و مسئولیت نگهداری همچنان بر عهده تیم سایت است. اگر تغییر مرتبطی دارید، آن را در جریان کاری خودتان استفاده کنید. اگر ندارید، فقط برای بهره بردن از یک عنوان خبری، ساختار قابل اعتماد محصول را پیچیده نکنید. ارزش ارتقا زمانی روشن می‌شود که امنیت و سازگاری حفظ شوند و نیاز مشخص نویسنده، مدیر یا کاربر بهتر پاسخ بگیرد.
هنوز دیدگاهی ثبت نشده
اولین نفری باشید که نظر می‌دهد!