https پر منتقلی کے بعد wordpress میں مکسڈ کنٹینٹ

آپ کا سرٹیفکیٹ نصب ہے، سائٹ https پر کھلتی ہے، اور تالا پھر بھی ظاہر ہونے سے انکاری ہے۔ یہی مکسڈ کنٹینٹ ہے: صفحہ خود https پر آیا، مگر اس کے اندر کوئی چیز — کوئی تصویر، کوئی اسٹائل شیٹ، کوئی اسکرپٹ — اب بھی سادہ http:// پر مانگی جا رہی ہے۔ یہ رہنما ان urls کو تلاش کرنے، سیریلائزڈ ڈیٹا خراب کیے بغیر انہیں بدلنے، siteurl اور home درست کرنے، اور سرور پر https نافذ کرنے تک لے جاتا ہے تاکہ مسئلہ واپس نہ آ سکے۔

مکسڈ کنٹینٹ دراصل ہے کیا

سرٹیفکیٹ لگانے سے یہ بدلتا ہے کہ کنکشن کیسے خفیہ ہوتا ہے۔ یہ نہیں بدلتا کہ آپ کے صفحات کیا مانگتے ہیں۔ ہر وہ http://yoursite.com/wp-content/uploads/logo.png جو منتقلی سے پہلے کسی پوسٹ، ویجٹ یا تھیم کی ترتیب میں لکھا گیا تھا اب بھی ڈیٹابیس میں پڑا ہے، اور براؤزر فرمانبرداری سے اسے غیر محفوظ کنکشن پر مانگتا ہے۔

براؤزر دو زمروں کے ساتھ الگ سلوک کرتے ہیں، اور یہ فرق تب اہم ہوتا ہے جب آپ طے کر رہے ہوں کہ معاملہ کتنا فوری ہے:

• فعال مکسڈ کنٹینٹ — اسکرپٹس، اسٹائل شیٹس، آئی فریمز، XHR۔ یکسر روک دیے جاتے ہیں۔ اسی لیے https پر منتقلی کے بعد سائٹ ٹوٹی ہوئی دکھ سکتی ہے حالانکہ کہیں کوئی ایرر پیغام نہیں ہوتا: کوئی اسٹائل شیٹ خاموشی سے رد کر دی گئی۔
• غیر فعال مکسڈ کنٹینٹ — تصاویر، آڈیو، ویڈیو۔ عموماً لوڈ ہو جاتا ہے، مگر تالا کمزور ہو جاتا ہے اور کچھ براؤزر ”غیر محفوظ“ کا نشان دکھاتے ہیں۔

دونوں ٹھیک کرنے کے لائق ہیں۔ صرف پہلا چیزیں توڑتا ہے۔

قدم ۱: معلوم کریں اب بھی کیا غیر محفوظ ہے

آغاز براؤزر سے کریں۔ صفحہ کھولیں، ڈویلپر ٹولز کھولیں، اور کنسول پڑھیں۔ ہر روکی گئی یا کمزور کی گئی درخواست وہاں اپنے مکمل url سمیت درج ہوتی ہے۔ یہ بتاتا ہے کیا غیر محفوظ ہے؛ یہ نہیں بتاتا کہ وہ کہاں محفوظ ہے۔

اس کے لیے براہِ راست ڈیٹابیس دیکھیں۔ اسے ایکسپورٹ کریں اور ڈمپ میں تلاش کریں:

wp db export dump.sql
grep -o "http://example\.com[^\"']*" dump.sql | sort -u | head -50

اگر WP-CLI دستیاب نہ ہو تو mysqldump وہی فائل بناتا ہے:

mysqldump -u USER -p DBNAME > dump.sql

جو منفرد urls واپس آئیں انہیں پڑھیں۔ اپلوڈز کے راستے پوسٹ کے مواد اور میٹا کی طرف اشارہ کرتے ہیں۔ تھیم اثاثوں کے راستے عموماً آپشنز کی طرف۔ جو کچھ ایسے ڈومین کے ساتھ ہو جسے آپ نہیں پہچانتے وہ بیرونی ایمبڈ ہے، جس کا حل الگ ہے (نیچے بیان ہوا ہے)۔

قدم ۲: پہلے siteurl اور home درست کریں

siteurl اور home وہ دو آپشن ہیں جن سے wordpress اپنا تقریباً ہر اندرونی url بناتا ہے۔ اگر ان میں سے کوئی بھی اب تک http:// کہتا ہے تو باقی ڈیٹابیس کتنا ہی صاف ہو، wordpress غیر محفوظ urls نکالتا رہے گا۔

انہیں جانچیں:

wp option get siteurl
wp option get home

یا sql میں:

SELECT option_name, option_value
FROM wp_options
WHERE option_name IN ('siteurl', 'home');

یہ دونوں سادہ اسٹرنگز ہیں، سیریلائزڈ ارے نہیں، اس لیے یہاں براہِ راست sql اپ ڈیٹ واقعی محفوظ ہے:

UPDATE wp_options
SET option_value = REPLACE(option_value, 'http://example.com', 'https://example.com')
WHERE option_name IN ('siteurl', 'home');

اس پر وقت لگانے سے پہلے ایک جال۔ اگر wp-config.php میں WP_HOME یا WP_SITEURL متعین ہوں تو یہ کونسٹنٹس ڈیٹابیس کو مکمل طور پر منسوخ کر دیتے ہیں اور آپ کا اپ ڈیٹ بے اثر لگے گا:

define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );

انہیں وہیں اپ ڈیٹ کریں، یا ہٹا دیں اور ڈیٹابیس کو چلانے دیں۔ یہ پہلے جانچیں — ”میں نے بدلا مگر کچھ نہیں ہوا“ کے بہت سے واقعات کی وضاحت یہی ہے۔

قدم ۳: ری پلیس کا سیریلائزیشن کے لحاظ سے محفوظ ہونا ضروری ہے

ڈیٹابیس میں باقی سب کچھ وہ جگہ ہے جہاں اصل خطرہ ہے، اور یہ وہ خطرہ نہیں جس کی زیادہ تر لوگ توقع کرتے ہیں۔ خطرہ یہ نہیں کہ ری پلیس کچھ urls چھوڑ دے گا۔ خطرہ یہ ہے کہ وہ متن کی سطح پر کامیاب ہو جائے اور گرد و پیش کا ڈیٹا تباہ کر دے۔

wordpress ارے اور آبجیکٹ کو php سیریلائزڈ اسٹرنگز کے طور پر محفوظ کرتا ہے، اور وہ فارمیٹ اپنے اندر موجود ہر اسٹرنگ کی بائٹ لمبائی درج کرتا ہے:

a:1:{s:4:"logo";s:38:"http://example.com/img/logo.png";}

خام sql REPLACE سے http:// کو https:// کریں تو متن ایک بائٹ لمبا ہو جاتا ہے جبکہ درج شدہ لمبائی پرانی قدر پر رہ جاتی ہے۔ php لمبائی پڑھتا ہے، اتنے بائٹ آگے چلتا ہے، جہاں اختتامی نشان متوقع ہو وہاں نہیں ملتا، اور پوری ارے کو ان سیریلائز کرنے سے انکار کر دیتا ہے۔ پھر wordpress تھیم یا پلگ ان کو ایسی قدر تھما دیتا ہے جو یوں برتاؤ کرتی ہے جیسے وہ ترتیب کبھی محفوظ ہی نہ ہوئی ہو۔

علامت کوئی ایرر نہیں ہوتی۔ علامت یہ ہوتی ہے کہ ویجٹ غائب ہو جائیں، کسٹمائزر کی ترتیبات ری سیٹ ہو جائیں، اور پیج بلڈر کے لے آؤٹ خالی رینڈر ہوں — جبکہ ایڈمن میں کہیں اشارہ تک نہ ہو کہ کچھ غلط ہوا۔ بیک اپ کے بغیر اس سے واپسی واقعی تکلیف دہ ہے، اس لیے ایک لے لیں:

wp db export backup-before-https-replace.sql

پھر ایسا اوزار استعمال کریں جو ان سیریلائز کرے، ڈی کوڈ شدہ ساخت کے اندر تبدیلی کرے، اور درست لمبائیوں کے ساتھ دوبارہ سیریلائز کرے۔ پہلے آزمائشی چلائیں:

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

رپورٹ پڑھیں۔ اگر کوئی ایسا ٹیبل جسے آپ نہیں پہچانتے ہزاروں نتائج دکھائے تو رکیں اور عمل سے پہلے دیکھیں۔ پھر اصل میں چلائیں:

wp search-replace 'http://example.com' 'https://example.com' --all-tables --skip-columns=guid --report-changed-only

--skip-columns=guid اہم ہے: guid فیڈ ریڈرز کے لیے ایک مستقل شناخت کنندہ ہے، زندہ url نہیں، اور اسے دوبارہ لکھنے سے سبسکرائبرز کو آپ کا سارا آرکائیو نئی پوسٹوں کے طور پر دکھ سکتا ہے۔ کچھ بھی چلانے سے پہلے اگر آپ دیکھنا چاہتے ہیں کہ کون سے کالم سادہ sql کے لیے محفوظ ہیں اور کن کو سیریلائزیشن سے واقف طریقے کی ضرورت ہے تو اسٹیٹمنٹس wordpress سرچ اینڈ ری پلیس sql ٹول سے بنائیں۔

اگر آپ کمانڈ لائن استعمال نہیں کر سکتے تو ایسا مائیگریشن پلگ ان جو صراحتاً کہے کہ وہ سیریلائزڈ ڈیٹا سنبھالتا ہے، وہی ڈی کوڈنگ کا کام ایڈمن اسکرین سے کر دیتا ہے۔ اگر کوئی اوزار یہ نہیں کہتا تو فرض کریں کہ وہ نہیں کرتا۔

قدم ۴: سرور پر https نافذ کریں

ڈیٹابیس صاف کرنے سے آپ کے صفحات غیر محفوظ وسائل مانگنا بند کر دیتے ہیں۔ اس سے کوئی وزیٹر شروع ہی میں http:// پر آنے سے نہیں رکتا۔ وہ سرور کی سطح کا ری ڈائریکٹ ہے، اور Apache پر اس کی جگہ .htaccess ہے:

# BEGIN Force HTTPS
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</IfModule>
# END Force HTTPS

جگہ کے بارے میں دو باتیں۔ اسے # BEGIN WordPress مارکرز کے اوپر رکھیں — ان کے اندر کی ہر چیز ہر بار پرمالنکس محفوظ ہونے پر پھینک دی جاتی ہے۔ اور یہ صرف تب کام کرتا ہے جب mod_rewrite فعال ہو اور ورچوئل ہوسٹ اوور رائیڈ کی اجازت دے (AllowOverride All، یا کم از کم FileInfo)۔ nginx پر .htaccess مکمل نظرانداز ہوتی ہے اور یہ سرور بلاک میں جانا چاہیے۔

RedirectMatch یہ کام نہیں کرے گا۔ وہ صرف درخواست کے راستے پر مماثلت کرتا ہے اور اس کے پاس یہ جانچنے کا کوئی ذریعہ نہیں کہ موجودہ درخواست پہلے ہی محفوظ ہے یا نہیں، چنانچہ وہ https درخواستوں کو خود انہی پر بھیج دیتا ہے۔ اوپر والا شرطی RewriteRule ہی درست اوزار ہے۔

ری ڈائریکٹ لوپ، اور یہ کیوں ہوتا ہے

اگر وہ رول شامل کرتے ہی سائٹ ہمیشہ کے لیے ری ڈائریکٹ کرنے لگے تو آپ کا TLS کہیں اوپر ختم ہو رہا ہے — کوئی لوڈ بیلنسر، ریورس پراکسی، یا cdn — جو پھر Apache کو سادہ http بھیجتا ہے۔ Apache کو غیر محفوظ درخواست نظر آتی ہے، وہ https پر بھیجتا ہے، پراکسی دوبارہ http بھیجتا ہے، اور یہ چکر چلتا رہتا ہے۔

اس کے بجائے فارورڈ کیا گیا ہیڈر جانچیں:

RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

خود wordpress میں بھی اس ترتیب میں یہی اندھا دھبہ ہے — is_ssl() $_SERVER['HTTPS'] پڑھتا ہے، جسے پراکسی کبھی مقرر نہیں کرتا، چنانچہ ایڈمن urls http:// کے طور پر نکلتے ہیں۔ یہ wp-config.php میں ”یہاں سے آگے ترمیم نہ کریں“ والی لائن کے اوپر شامل کریں:

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && 'https' === $_SERVER['HTTP_X_FORWARDED_PROTO'] ) {
	$_SERVER['HTTPS'] = 'on';
}

خطرے کے بارے میں صاف بات کرنا مناسب ہے: X-Forwarded-Proto کلائنٹ کا بھیجا ہوا ہیڈر ہے۔ اس پر بھروسہ صرف تب درست ہے جب آپ کے اپنے قابو میں موجود پراکسی اسے ہمیشہ دوبارہ لکھ دے۔ ایسے سرور پر جو انٹرنیٹ سے براہِ راست قابلِ رسائی ہو، اسے جعلی بنایا جا سکتا ہے۔

ڈیٹابیس ری پلیس کیا ٹھیک نہیں کرے گا

• فائلوں میں ہارڈ کوڈ شدہ urls۔ جو کچھ functions.php میں، چائلڈ تھیم کے ٹیمپلیٹ میں، یا اِن لائن اثاثے کے راستے کے طور پر لکھا گیا ہو وہ ڈیٹابیس میں نہیں ہے۔ تھیم ڈائریکٹری الگ سے grep کریں۔
• ایسکیپ شدہ JSON۔ کچھ بلڈرز urls کو https:\/\/example.com کی صورت میں محفوظ کرتے ہیں۔ عام صورت کی تلاش انہیں یکسر چھوڑ دیتی ہے، اس لیے ایسکیپ شدہ اسٹرنگ پر دوسرا راؤنڈ درکار ہو سکتا ہے۔
• بیرونی وسائل۔ کوئی فریقِ ثالث اسکرپٹ یا ایمبڈ جو صرف http پر دستیاب ہو، آپ کی طرف سے ٹھیک نہیں کیا جا سکتا۔ https والا متبادل ڈھونڈیں یا اسے چھوڑ دیں۔
• کیش۔ پیج کیش، آبجیکٹ کیش اور cdn کی نقول درست ری پلیس کے بعد بھی پرانا مارک اپ پیش کرتی رہتی ہیں۔ یہ نتیجہ نکالنے سے پہلے کہ ری پلیس ناکام رہا، تینوں خالی کریں۔

ایک چیز جسے چھوڑ دینا بہتر ہے: upgrade-insecure-requests والا کنٹینٹ سیکیورٹی پالیسی ہیڈر براؤزر میں غیر محفوظ درخواستیں دوبارہ لکھ کر انتباہات خاموش کر دیتا ہے۔ مگر یہ علامت کا علاج کرتا ہے اور غلط urls آپ کے ڈیٹابیس میں چھوڑ دیتا ہے، جہاں سے اگلا ایکسپورٹ، مائیگریشن یا فیڈ انہیں آگے لے جائے گا۔ ڈیٹا درست کریں، پھر چاہیں تو اسے حفاظتی جال کے طور پر استعمال کریں۔

اب بھی پھنسے ہوئے ہیں؟

ہر قدم کے بعد siteurl اور home دوبارہ جانچیں — پلگ ان اور مائیگریشن ٹولز کبھی کبھی آپ کے پیچھے انہیں دوبارہ لکھ دیتے ہیں۔ اگر کنسول اب بھی کوئی ایسا غیر محفوظ url بتاتا ہے جو آپ کو ڈمپ میں نہیں ملتا تو صفحے کا سورس دیکھیں اور وہاں تلاش کریں: اگر وہ تیار شدہ مارک اپ میں ہے مگر ڈیٹابیس میں نہیں، تو وہ php میں بن رہا ہے، اور جو تھیم یا پلگ ان اسے بنا رہا ہے وہی ٹھیک کرنے کی چیز ہے۔