رفع خطای Mixed Content در وردپرس؛ آموزش شناسایی و اصلاح محتوای ناامن

مقدمه:

رفع خطای Mixed Content در وردپرس فقط به نصب گواهی SSL محدود نمی‌شود. پس از فعال‌سازی HTTPS باید تمام تصاویر، فونت‌ها، فایل‌های CSS و JavaScript، iframeها و درخواست‌های داخلی نیز از مسیر امن بارگذاری شوند. برای حل مشکل ابتدا منبع درخواست HTTP را با ابزار توسعه‌دهندگان مرورگر پیدا کنید، سپس نشانی‌های وردپرس و دیتابیس را اصلاح کرده و قالب، افزونه، CDN و کش سایت را بررسی کنید. پیش از تغییر دیتابیس یا فایل‌های اصلی، حتماً نسخه پشتیبان تهیه کنید.

فهرست مطالب

• خطای Mixed Content چیست؟
• انواع محتوای ترکیبی و نشانه‌های آن
• پیش‌نیازهای رفع خطا
• روش پیدا کردن منابع HTTP
• مراحل رفع خطای Mixed Content در وردپرس
• استفاده از افزونه؛ راه‌حل دائمی یا موقت؟
• اشتباهات متداول هنگام اصلاح خطا
• چک‌لیست آزمایش نهایی
• جمع‌بندی
• سؤالات متداول

خطای Mixed Content چیست و چرا ایجاد می‌شود؟

وقتی صفحه‌ای با آدرس https:// باز می‌شود، انتظار می‌رود تمام اجزای داخل آن نیز از یک اتصال رمزگذاری‌شده دریافت شوند. اگر همان صفحه یک تصویر، فونت، اسکریپت، فایل CSS یا محتوای دیگری را با http:// فراخوانی کند، محتوای ترکیبی یا Mixed Content به وجود می‌آید.

برای مثال، صفحه زیر با HTTPS باز شده است:

https://example.com/about-us/

اما یکی از تصاویر آن همچنان از این نشانی دریافت می‌شود:

http://example.com/wp-content/uploads/logo.png

در این وضعیت، سند اصلی امن است اما بخشی از محتوا از ارتباط ناامن استفاده می‌کند. مرورگر ممکن است درخواست ناامن را به HTTPS ارتقا دهد یا آن را کاملاً مسدود کند. اسکریپت‌ها، استایل‌ها، iframeها و فونت‌های ناامن معمولاً حساس‌تر هستند و مسدود شدن آن‌ها می‌تواند ظاهر یا عملکرد صفحه را مختل کند. MDN

دلایل متداول بروز این خطا عبارت‌اند از:

• فعال‌کردن SSL بدون اصلاح آدرس‌های قدیمی داخل دیتابیس
• باقی‌ماندن URLهای HTTP در تنظیمات وردپرس
• استفاده از آدرس ثابت در قالب یا افزونه اختصاصی
• فراخوانی فونت، تصویر یا اسکریپت از یک سرویس خارجی فاقد HTTPS
• تنظیم نادرست CDN، پراکسی معکوس یا Load Balancer
• نمایش نسخه قدیمی صفحه از کش وردپرس، سرور یا مرورگر
• وجود CSS ذخیره‌شده توسط صفحه‌سازها با نشانی‌های قبلی

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

مطالعه بیشتر:آموزش نصب و فعال‌سازی SSL

انواع Mixed Content و تأثیر آن بر سایت

در منابع جدید فنی، محتوای ترکیبی بیشتر به دو گروه «قابل ارتقا» و «قابل مسدودسازی» تقسیم می‌شود. مرورگر ممکن است بعضی درخواست‌های تصویری یا چندرسانه‌ای را به‌صورت خودکار از HTTP به HTTPS تغییر دهد، اما درخواست‌هایی مانند اسکریپت، CSS، iframe، فونت و Fetch معمولاً مسدود می‌شوند. MDN

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

پیش‌نیازهای رفع خطای Mixed Content در وردپرس

پیش از شروع، مطمئن شوید گواهی SSL معتبر روی دامنه نصب شده و نسخه HTTPS سایت بدون هشدار مربوط به خود گواهی باز می‌شود. اگر گواهی نصب نشده، منقضی شده یا نام دامنه را پوشش نمی‌دهد، تغییر URLهای وردپرس مشکل اصلی را حل نخواهد کرد.

موارد زیر را نیز آماده کنید:

• دسترسی مدیر به پیشخوان وردپرس
• دسترسی به کنترل‌پنل هاست و File Manager
• امکان تهیه خروجی از دیتابیس
• دسترسی SSH در صورت استفاده از WP-CLI
• فهرست سرویس‌های کش، CDN و پراکسی متصل به سایت
• یک نسخه پشتیبان سالم از فایل‌ها و دیتابیس

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

مطالعه بیشتر: تهیه بکاپ کامل از وردپرس

چگونه منبع خطای Mixed Content را پیدا کنیم؟

بررسی Console مرورگر

صفحه مشکل‌دار را در Chrome، Firefox یا Edge باز کنید. کلید F12 را بزنید یا از منوی مرورگر وارد Developer Tools شوید و زبانه Console را باز کنید.

پیام Mixed Content معمولاً نشانی صفحه و فایل HTTP را نشان می‌دهد. این نشانی مهم‌ترین سرنخ برای تشخیص محل ذخیره منبع است. برای مثال:

Mixed Content: The page was loaded over HTTPS,
but requested an insecure stylesheet:
http://example.com/theme/style.css

کنسول توسعه‌دهندگان هشدار درخواست‌هایی را که ارتقا یافته یا مسدود شده‌اند نمایش می‌دهد و یکی از روش‌های مستقیم عیب‌یابی Mixed Content است. MDN

استفاده از زبانه Network

در Developer Tools وارد زبانه Network شوید و صفحه را دوباره بارگذاری کنید. در فیلتر جست‌وجو عبارت http:// را وارد کنید یا ستون Scheme را بررسی کنید.

این روش زمانی مفید است که خطا به درخواست API، فایل فونت، CSS فرعی یا منابعی مربوط باشد که مستقیماً در HTML صفحه دیده نمی‌شوند.

جست‌وجو در کد منبع صفحه

روی صفحه راست‌کلیک کنید و View Page Source را انتخاب کنید. سپس عبارت http:// را جست‌وجو کنید.

توجه داشته باشید که هر آدرس HTTP الزاماً Mixed Content نیست. یک لینک عادی که کاربر را به صفحه‌ای دیگر هدایت می‌کند با منبعی که داخل صفحه بارگذاری می‌شود تفاوت دارد. بیشتر روی ویژگی‌هایی مانند src، srcset، href مربوط به CSS، url() و درخواست‌های اسکریپتی تمرکز کنید.

تشخیص محل ذخیره آدرس

از ساختار URL می‌توان محل احتمالی مشکل را حدس زد:

• مسیر /wp-content/uploads/ معمولاً به رسانه یا محتوای دیتابیس مربوط است.
• مسیر /wp-content/themes/ می‌تواند از قالب یا تنظیمات آن باشد.
• مسیر /wp-content/plugins/ احتمالاً توسط افزونه تولید شده است.
• دامنه خارجی می‌تواند به فونت، نقشه، آمارگیر، ویدئو یا CDN مربوط باشد.
• آدرس داخل CSS تولیدشده معمولاً با تنظیمات صفحه‌ساز یا کش CSS ارتباط دارد.

آموزش رفع خطای Mixed Content در وردپرس

مرحله اول: بررسی آدرس‌های اصلی وردپرس

در پیشخوان به مسیر تنظیمات ← عمومی بروید. دو گزینه زیر باید با HTTPS آغاز شوند:

• نشانی وردپرس یا WordPress Address
• نشانی سایت یا Site Address

برای نمونه:

https://example.com

اگر این فیلدها غیرفعال‌اند، احتمال دارد مقادیر WP_HOME یا WP_SITEURL در فایل wp-config.php تعریف شده باشند. در این حالت ابتدا فایل را بررسی کنید و بدون شناخت پیکربندی، مقدار دیگری را هم‌زمان در دیتابیس و فایل تنظیم نکنید.

وردپرس برای استفاده کامل از HTTPS باید گواهی معتبر و پیکربندی مناسب وب‌سرور داشته باشد. تغییر اجباری تنظیمات پیش از آماده بودن SSL می‌تواند دسترسی به سایت یا مدیریت را مختل کند. Developer.WordPress.org

مرحله دوم: اصلاح URLهای قدیمی داخل دیتابیس

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

اگر به SSH و WP-CLI دسترسی دارید، ابتدا از دیتابیس بکاپ بگیرید و یک اجرای آزمایشی انجام دهید:

wp search-replace 'http://example.com' 'https://example.com' \
  --all-tables-with-prefix --precise --dry-run

گزینه --dry-run فقط گزارش تغییرات را نمایش می‌دهد و چیزی را ذخیره نمی‌کند. دستور رسمی WP-CLI داده‌های سریال‌شده را نیز در فرایند جایگزینی مدیریت می‌کند و گزینه --precise برای پردازش دقیق‌تر ساختارهای پیچیده در دسترس است. Developer.WordPress.org

پس از بررسی دامنه، مسیر نصب، تعداد تغییرات و تهیه نسخه پشتیبان، دستور را بدون --dry-run اجرا کنید:

wp search-replace 'http://example.com' 'https://example.com' \
  --all-tables-with-prefix --precise

در سایت چنددامنه‌ای یا Multisite از این دستور بدون تطبیق با ساختار شبکه استفاده نکنید. همچنین آدرس نمونه را دقیقاً با دامنه واقعی، زیر دامنه و وجود یا نبود www هماهنگ کنید.

اگر SSH ندارید، می‌توانید از افزونه معتبر Search and Replace استفاده کنید؛ اما باید افزونه‌ای را انتخاب کنید که داده‌های سریال‌شده را پشتیبانی کند و حالت آزمایشی یا گزارش تغییرات داشته باشد. پس از اتمام کار، افزونه‌ای را که دیگر لازم نیست غیرفعال و حذف کنید.

مرحله سوم: بررسی قالب و افزونه‌ها

اگر URL ناامن داخل دیتابیس پیدا نشد، پوشه قالب و افزونه‌ها را برای http:// جست‌وجو کنید. آدرس ممکن است در فایل‌های PHP، JavaScript یا CSS نوشته شده باشد.

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

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

مرحله چهارم: اصلاح منابع خارجی

اگر منبع ناامن روی دامنه دیگری قرار دارد، ابتدا نسخه HTTPS همان فایل را آزمایش کنید. صرفاً جایگزین‌کردن http:// با https:// کافی نیست؛ سرور خارجی باید واقعاً SSL معتبر داشته باشد و فایل را از مسیر جدید ارائه کند.

اگر سرویس مقصد HTTPS ندارد، گزینه‌های منطقی عبارت‌اند از:

• جایگزینی منبع با یک سرویس امن
• میزبانی محلی فایل با رعایت مجوز انتشار
• حذف منبع غیرضروری
• دریافت نسخه امن از ارائه‌دهنده اصلی

از بارگذاری فایل ناشناس یا کپی محتوای دارای محدودیت استفاده بدون بررسی مجوز خودداری کنید.

مرحله پنجم: بازسازی فایل‌های CSS صفحه‌ساز

برخی صفحه‌سازها و قالب‌ها فایل CSS تولیدشده را در پوشه آپلود یا کش خود ذخیره می‌کنند. حتی پس از اصلاح دیتابیس، نسخه قدیمی این فایل ممکن است به HTTP اشاره کند.

در تنظیمات صفحه‌ساز، گزینه بازسازی CSS، همگام‌سازی فایل‌ها یا Regenerate Files را اجرا کنید. نام و محل این گزینه میان محصولات مختلف تفاوت دارد. سپس کش افزونه، هاست و CDN را پاک کنید.

مطالعه بیشتر: آموزش پاک‌کردن کش وردپرس

مرحله ششم: بررسی CDN و پراکسی معکوس

اگر SSL روی CDN یا Load Balancer پایان می‌یابد و ارتباط داخلی تا وردپرس HTTP است، وردپرس باید درخواست اصلی را HTTPS تشخیص دهد. پیکربندی ناقص این بخش ممکن است URLهای HTTP یا حلقه تغییر مسیر ایجاد کند.

مستندات وردپرس هشدار می‌دهد که استفاده از SSL در پراکسی معکوس، بدون شناسایی صحیح هدر پروتکل، می‌تواند باعث حلقه بی‌نهایت تغییر مسیر شود. تنظیم هدرهایی مانند X-Forwarded-Proto باید در پراکسی و وردپرس هماهنگ و توسط مدیر سرور انجام شود. Developer.WordPress.org

اگر از CDN استفاده می‌کنید، موارد زیر را کنترل کنید:

• حالت SSL با گواهی نصب‌شده روی سرور مبدا هماهنگ باشد.
• CDN منابع کش‌شده HTTP را نگه نداشته باشد.
• URL مبدا و Rewriteهای CDN روی HTTPS تنظیم شده باشند.
• دامنه‌های جانبی مربوط به تصاویر و فایل‌های ثابت نیز گواهی معتبر داشته باشند.

رفع خطای Too Many Redirects در وردپرس» ← مقاله عیب‌یابی حلقه تغییر مسیر وردپرس]

مقایسه راه‌حل‌های رفع Mixed Content

برای یک سایت کوچک، اصلاح تنظیمات وردپرس و چند URL محدود ممکن است کافی باشد. در سایت فروشگاهی، چندزبانه یا دارای صفحه‌ساز، استفاده از WP-CLI یا ابزار سازگار با داده سریال‌شده، همراه با آزمایش روی نسخه Stage، انتخاب مطمئن‌تری است.

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

مطالعه بیشتر: خدمات هاست وردپرس

آیا افزونه SSL مشکل Mixed Content را کاملاً حل می‌کند؟

برخی افزونه‌ها درخواست‌های HTTP را هنگام تولید صفحه به HTTPS بازنویسی می‌کنند. این روش برای راه‌اندازی سریع یا سایت‌هایی که دسترسی فنی محدودی دارند مفید است، اما همیشه URLهای قدیمی را از دیتابیس، CSS تولیدشده یا کد افزونه حذف نمی‌کند.

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

در انتخاب افزونه به سازگاری با نسخه وردپرس، سابقه نگهداری، دامنه تغییرات و امکان بازگشت توجه کنید. پیش از نصب یا تغییر تنظیمات، نسخه پشتیبان تهیه کنید.

اشتباهات متداول در رفع خطای Mixed Content

جایگزینی تمام HTTPها بدون بررسی

همه آدرس‌های HTTP متعلق به دامنه سایت نیستند. جایگزینی سراسری ممکن است URL سرویس‌های خارجی، محتوای متنی، کد نمونه یا داده‌های یکپارچه‌سازی را تغییر دهد.

فقط دامنه و الگوی مشخص خود را جایگزین کنید. نتیجه dry-run را بررسی کرده و از اجرای دستور مبهم مانند جایگزینی تمام http://ها بپرهیزید.

ویرایش مستقیم دیتابیس سریال‌شده

تغییر طول رشته در داده سریال‌شده می‌تواند ساختار آن را خراب کند. از WP-CLI یا ابزاری استفاده کنید که این نوع داده را تشخیص می‌دهد.

اجبار HTTPS پیش از نصب گواهی

اگر گواهی معتبر و پیکربندی HTTPS آماده نباشد، اجبار تغییر مسیر می‌تواند دسترسی به سایت و پیشخوان را مختل کند. ابتدا HTTPS را مستقیماً آزمایش کنید و سپس ریدایرکت را فعال کنید.

پاک نکردن تمام لایه‌های کش

ممکن است دیتابیس اصلاح شده باشد اما CDN یا افزونه کش همچنان HTML قدیمی را تحویل دهد. کش وردپرس، Object Cache، کش سرور، CDN و مرورگر را به‌ترتیب پاک کنید.

آزمایش‌کردن فقط صفحه اصلی

Mixed Content ممکن است تنها در نوشته قدیمی، صفحه محصول، سبد خرید یا فرم تماس دیده شود. صفحات دارای قالب‌های متفاوت را جداگانه بررسی کنید.

سناریوی عملی عیب‌یابی

فرض کنید صفحه اصلی امن است، اما صفحه تماس هشدار Mixed Content دارد. Console نشانی زیر را نمایش می‌دهد:

http://cdn.example.com/fonts/site-font.woff2

ابتدا نسخه HTTPS فایل آزمایش می‌شود. اگر فایل با گواهی معتبر باز شود، آدرس فونت در تنظیمات قالب یا CSS به HTTPS تغییر می‌کند. اگر نسخه امن وجود نداشته باشد، باید منبع فونت با سرویس امن جایگزین یا با رعایت مجوز روی هاست خود سایت میزبانی شود.

پس از اصلاح، CSS قالب یا صفحه‌ساز بازسازی و تمام کش‌ها پاک می‌شوند. در پایان، صفحه در پنجره ناشناس باز شده و Console و Network دوباره بررسی می‌شوند.

چک‌لیست آزمایش سایت پس از اصلاح

• صفحه اصلی، نوشته‌ها، برگه‌ها و محصولات را باز کنید.
• Console را برای عبارت Mixed Content بررسی کنید.
• در Network درخواست‌های http:// را پیدا کنید.
• فرم تماس، ورود کاربران و فرایند خرید را آزمایش کنید.
• تصاویر واکنش‌گرا و ویژگی srcset را کنترل کنید.
• فونت‌ها، منو، اسلایدر و فایل‌های JavaScript را بررسی کنید.
• سایت را روی موبایل و مرورگر دیگری آزمایش کنید.
• دامنه‌های دارای www و بدون www را کنترل کنید.
• کش وردپرس، سرور، CDN و مرورگر را پاک کنید.
• از سلامت پیشخوان و وظایف زمان‌بندی‌شده مطمئن شوید.

مطالعه بیشتر: افزایش امنیت سایت وردپرسی

جمع‌بندی رفع خطای Mixed Content در وردپرس

رفع خطای Mixed Content در وردپرس با پیدا کردن منبع دقیق درخواست HTTP آغاز می‌شود. Console و Network مرورگر مشخص می‌کنند که مشکل از تصویر، فونت، CSS، اسکریپت، iframe یا درخواست خارجی ناشی شده است.

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

حل اصولی خطا به این معناست که تمام منابع صفحه واقعاً از HTTPS دریافت شوند؛ نه اینکه هشدار فقط با یک بازنویسی موقت پنهان شود. پس از هر تغییر نیز صفحات مهم و امکانات تعاملی سایت باید دوباره آزمایش شوند.

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

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

۱. چرا با وجود نصب SSL هنوز خطای Mixed Content نمایش داده می‌شود؟

زیرا نصب SSL فقط ارتباط صفحه اصلی را امن می‌کند. اگر تصویر، فونت، CSS، اسکریپت یا iframe با HTTP بارگذاری شود، خطای Mixed Content باقی می‌ماند.

۲. آیا تغییر آدرس وردپرس از HTTP به HTTPS کافی است؟

خیر. این تغییر آدرس‌های اصلی را اصلاح می‌کند، اما URLهای ذخیره‌شده در محتوا، صفحه‌ساز، قالب، افزونه یا کش ممکن است همچنان HTTP باشند.

۳. چگونه فایل ایجادکننده خطا را پیدا کنیم؟

Developer Tools مرورگر را باز کنید و زبانه‌های Console و Network را بررسی کنید. پیام خطا معمولاً URL کامل منبع ناامن را نشان می‌دهد.

۴. آیا می‌توان تمام http://ها را مستقیماً در دیتابیس تغییر داد؟

جایگزینی بدون محدودکردن دامنه خطرناک است. ابتدا بکاپ بگیرید و با WP-CLI یا ابزار سازگار با داده‌های سریال‌شده، فقط URL مشخص سایت را جایگزین کنید.

۵. آیا افزونه SSL برای حل دائمی مشکل کافی است؟

همیشه خیر. افزونه ممکن است URLها را هنگام نمایش بازنویسی کند، اما آدرس‌های قدیمی دیتابیس، کد قالب یا تنظیمات CDN همچنان باقی بمانند.

۶. چرا خطا فقط در بعضی صفحات دیده می‌شود؟

هر صفحه ممکن است تصویر، ابزارک، فرم یا قالب متفاوتی داشته باشد. یک فایل HTTP در نوشته قدیمی یا صفحه محصول می‌تواند فقط همان صفحه را دچار خطا کند.

۷. چرا بعد از اصلاح URL هنوز مرورگر هشدار می‌دهد؟

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