موقع ووردبريس HTTPS والصور لا تظهر؟ تجربة حظر المحتوى المختلط

فعلت شهادة SSL وصار رابط ووردبريس يبدأ بـ HTTPS، لكن بعض الصور او الخطوط اختفت، التصميم تخرب، او نموذج وإضافة توقفوا؟ وجود القفل للصفحة الرئيسية ما يعني ان كل مورد داخلها آمن. اذا الصفحة HTTPS وطلبت صورة او CSS او JavaScript عبر HTTP، المتصفح يعتبره محتوى مختلط.

عشان نشوف السلوك الحقيقي، شغلنا صفحة على خادم HTTPS محلي وموردا منفصلا على HTTP. الصفحة طلبت صورة وسكربت من العنوان غير الآمن، وراقبنا ايدج. بعد هيك قدمنا الموردين عبر HTTPS واعدنا الاختبار بنفس المتصفح ونفس الصورة.

هاي الحالة ظهرت في سؤال حديث داخل دعم ووردبريس عن صور مصغرة تستخدم HTTP رغم عمل الموقع عبر SSL، وظهرت رسائل قريبة في نقاش مجتمع ووردبريس على ريديت. استخدمنا الحالات لاختيار المشكلة، لكن الصور والارقام هنا من تجربتنا.

شو يعني محتوى مختلط؟

صفحة HTTPS يفترض ان يصل محتواها من قناة مشفرة. لما تضع داخلها موردا يبدأ بـ http://، يصير جزء من الصفحة خارج الحماية. السكربت غير الآمن اخطر لانه يقدر يغير الصفحة، لذلك المتصفح يحظره. بعض الصور والفيديو قد يحاول المتصفح رفع طلبها تلقائيا إلى HTTPS، واذا الخادم ما يدعم HTTPS تفشل.

مواصفة W3C للمحتوى المختلط تفرق بين موارد قابلة للرفع وموارد قابلة للحظر. السكربت مثال واضح على مورد يحظر، بينما الصورة قد ترفع تلقائيا ثم تمنع اذا ما قدرت تعمل عبر اتصال آمن.

ترتيب المختبر

شغلنا الصفحة على https://localhost:8843 بشهادة محلية مخصصة للاختبار. ايدج فتحها مع تجاهل تحذير ثقة الشهادة المحلية فقط. هذا التجاهل ما عطل سياسة المحتوى المختلط. المورد غير الآمن كان على http://127.0.0.1.nip.io:8897، وهو عنوان يرجع لنفس الجهاز ولا يرسل بيانات لموقع خارجي.

طلبنا من الصفحة موردين:

• صورة PNG فعلية عبر HTTP.
• ملف JavaScript صغير يغير حالة داخل الصفحة اذا اشتغل.

صفحة HTTPS نفسها رجعت برمز 200. يعني المشكلة مش فشل الشهادة او توقف الصفحة؛ الفشل كان في الموارد الداخلية.

النتيجة قبل التصحيح

ايدج سجل تحذيرا ان الصورة غير الآمنة تم رفعها تلقائيا من HTTP إلى HTTPS. المنفذ 8897 كان يقدم HTTP فقط، لذلك محاولة HTTPS انتهت بـ ERR_SSL_PROTOCOL_ERROR. العرض الطبيعي للصورة كان صفرا، فظهرت مكسورة.

اما السكربت، فسجل المتصفح له خطأ mixed-content وحظره مباشرة. علامة الاختبار داخل الصفحة بقيت تقول انه محجوب. هذا يشرح ليش موقعك ممكن يفتح بينما قائمة متحركة، نموذج، خط، او جزء من منشئ الصفحات لا يعمل.

فيديو توثيق التجربة الفعلية

هذا تسجيل شاشة صامت ومتواصل للاختبار وهو يحدث داخل بيئة محلية معزولة. تظهر الخطوات والنتائج الفعلية لحظة التنفيذ، من غير تركيب صور ثابتة.

النتيجة بعد تقديم الموارد عبر HTTPS

غيرنا مصدر الصورة والسكربت إلى https://localhost:8843 من غير تغيير الملفين. في الجولة الثانية:

• الصفحة بقيت HTTPS وبرمز 200.
• الصورة حملت ووصل عرضها الطبيعي إلى 1365 بكسل.
• السكربت اشتغل وغير حالة الاختبار.
• عدد الطلبات الفاشلة التي سجلها المراقب صار صفرا.

كيف تعرف المورد اللي عامل المشكلة في ووردبريس؟

1. افتح الصفحة المتأثرة في ايدج او كروم.
2. افتح ادوات المطور ثم Console وابحث عن Mixed Content.
3. انتقل إلى Network واعد تحميل الصفحة.
4. اكتب http:// في خانة التصفية او راجع الطلبات الحمراء.
5. انسخ عنوان المورد وحدد مصدره: محتوى مقال، إضافة، قالب، CSS مولد، CDN، او إعداد قديم.

لا تعتمد على شكل القفل وحده. ممكن الصفحة تظهر آمنة بعد ان المتصفح حظر المورد الخطر، لكن التصميم او الوظيفة تكون ناقصة. سجل Network يعطيك اسم الملف والجهة اللي طلبته.

ترتيب الاصلاح في موقع حقيقي

1. تأكد ان HTTPS يعمل فعليا

افتح ملف صورة مباشرة على HTTPS. اذا الشهادة منتهية او لا تغطي الدومين او CDN، اصلاح النص من HTTP إلى HTTPS رح ينقلك من mixed content إلى خطأ شهادة. لازم الاصل نفسه يدعم HTTPS اولا.

2. راجع عنواني ووردبريس

من الاعدادات العامة تأكد ان WordPress Address وSite Address يستخدمان https:// والدومين الصحيح. اذا الموقع خلف Cloudflare او وكيل عكسي، تأكد ان ووردبريس يعرف ان الطلب الخارجي HTTPS، لان اكتشاف البروتوكول بشكل غلط يخليه يولد روابط HTTP كل مرة.

3. بدل الروابط القديمة داخل قاعدة البيانات بأمان

اذا الموارد مخزنة كرابط كامل، خذ نسخة احتياطية وشغل استبدالا يفهم البيانات المتسلسلة. مثال معاينة عبر WP-CLI:

wp search-replace 'http://example.com' 'https://example.com' --all-tables-with-prefix --skip-columns=guid --dry-run

راجع العدد قبل التنفيذ. هذا نفس مبدأ تجربة المقال السابق: لا تستخدم REPLACE() اعمى على كل قاعدة البيانات، ولا تغير guid.

4. افحص الملفات الصلبة والكاش

اذا البحث داخل قاعدة البيانات رجع صفرا وما زال الخطأ موجودا، ابحث في ملفات القالب والإضافة وCSS المولد. بعض الإضافات تكتب ملفات كاش داخل uploads فيها رابط كامل. اعد توليد CSS من اعداد الإضافة، امسح الكاش بعد اصلاح المصدر، وافحص نسخة CDN.

هل إضافة Mixed Content Fixer تكفي؟

ممكن إضافة موثوقة تعيد كتابة الروابط وقت عرض الصفحة وتوقف العطل بسرعة، لكنها مش دائما اصلاحا لجذر المشكلة. لو قاعدة البيانات او إعداد البروكسي ما زال يولد HTTP، تظل معتمدا على طبقة ترقيع بكل طلب. الافضل تعرف المصدر وتصلحه، وبعدها تقرر اذا تحتاج الإضافة لحالة خاصة.

لا تغير كل ظهور لـ http:// بشكل اعمى. روابط خارجية قد لا تدعم HTTPS، وروابط Webhook او API قد تحتاج تحديثا عند المزود، وبعض النصوص مجرد امثلة داخل مقال. عالج الموارد التي تحملها الصفحة فعليا، وراجع كل نطاق على حدة.

فرق مهم: mixed content وخطأ الشهادة

في mixed content تكون الصفحة HTTPS لكنها تطلب موردا HTTP. في خطأ الشهادة، المورد نفسه يستخدم HTTPS لكن شهادته غير صالحة او لا تطابق اسمه. وفي 404 يكون الاتصال ناجحا لكن الملف غير موجود. الرسائل قد تنتهي كلها بصورة مكسورة، لكن الحل مختلف:

• mixed-content: صحح بروتوكول ومصدر الرابط.
• ERR_CERT...: اصلح الشهادة والدومين المغطى.
• 404: راجع نقل الملف والمسار واسم النسخة المصغرة.
• 403: راجع الصلاحيات والحماية وCDN.

الخلاصة

في تجربتنا فتحت صفحة HTTPS برمز 200، لكن صورة HTTP فشلت بعد محاولة رفعها إلى HTTPS، وسكربت HTTP حظره ايدج كـ mixed content. لما قدمنا الموردين عبر HTTPS ظهرت الصورة بعرض طبيعي 1365، اشتغل السكربت، وصار عدد الطلبات الفاشلة صفرا.

على ووردبريس، ابدأ من Console وNetwork وحدد المورد الحقيقي. تأكد من الشهادة وعناوين ووردبريس واكتشاف HTTPS خلف البروكسي، ثم بدل الروابط القديمة بأداة آمنة وافحص CSS والكاش وCDN. الهدف مش اخفاء التحذير، بل جعل كل مورد تحتاجه الصفحة يصل فعليا عبر HTTPS.