آرٹیکل ڈائرکٹری
کل دوپہر، میں سرور پر ایڈمنر ڈیٹا بیس مینجمنٹ ٹول کو ترتیب دے رہا تھا۔ ایڈمنر ہلکا پھلکا اور استعمال میں آسان ہے۔ ایک پی ایچ پی فائل کام کرتی ہے، phpMyAdmin کے برعکس جس کے لیے انحصار کا ایک گروپ درکار ہوتا ہے۔ میں نے آفیشل ویب سائٹ سے تازہ ترین ورژن ڈاؤن لوڈ کیا، اسے سرور پر اپ لوڈ کیا، اجازتیں سیٹ کیں، اور اپنا براؤزر کھولا، اسے چیک کرنے کے لیے تیار ہوں۔
پھر، سب کچھ خالی ہو گیا.
میں نے صفحہ کو تین بار تازہ کیا، میری انگلیاں F5 کو کئی بار دبانے سے درد کر رہی تھیں۔ پھر بھی کچھ نہیں۔ میں نے براؤزر کے ڈویلپر ٹولز کھولے۔ اس نے 200 OK کی خرابی ظاہر کی، لیکن رسپانس باڈی خالی تھی۔ میں بالکل دنگ رہ گیا۔ کیا ہو رہا تھا؟
میں نے ایک لمحے کے لیے اس کے بارے میں سوچا۔ کیا یہ فائل کی اجازت کا مسئلہ ہوسکتا ہے؟ میں نے چیک کیا، اور یہ 755 تھا۔ کیا یہ پی ایچ پی ورژن کی عدم مطابقت ہو سکتی ہے؟ میں نے چیک کیا، اور یہ پی ایچ پی 8.2 ہے، جو ٹھیک ہے۔ کیا فائل خود ناقص ہو سکتی ہے؟ میں نے ایک نئی کاپی ڈاؤن لوڈ کی، اسے اوور رائٹ کیا، اور یہ ابھی تک خالی ہے۔
کسی ناقابل فہم وجہ سے، میں نے سوچا، کیوں نہ اپنا نام بدلنے کی کوشش کروں؟
میں نے adminer.php کا نام بدل کر adminer1.php رکھا اور صفحہ کو تازہ کیا۔
رسائی کامیاب رہی۔
میں حقیقی طور پر حیران تھا۔ وہی فائل، وہی کوڈ، وہی سرور، اور یہ صرف نام تبدیل کرکے قابل رسائی ہے؟ یہ کیسی صوفیانہ منطق ہے؟
adminer.php فائل خالی ہے۔
بعد میں مجھے معلوم ہوا کہ یہ کوئی توہم پرستی نہیں تھی۔ یہ پی ایچ پی کیشنگ تھی جو مسئلہ پیدا کر رہی تھی۔
OPcache، Opcode Cache کے لیے مختصر، PHP کے لیے کارکردگی کی اصلاح کی توسیع ہے۔ اس کا اصول آسان ہے: پی ایچ پی ایک تشریح شدہ زبان ہے، اور ہر درخواست کے لیے پی ایچ پی کوڈ کو عمل درآمد سے پہلے آپ کوڈ میں مرتب کرنے کی ضرورت ہوتی ہے۔ OPcache مرتب شدہ نتیجہ کو میموری میں کیش کرتا ہے، جس سے بعد میں آنے والی درخواستوں کو بغیر کسی کمپلیشن کے براہ راست کیش شدہ ورژن استعمال کرنے کی اجازت ملتی ہے، جس کے نتیجے میں کارکردگی میں نمایاں بہتری آتی ہے۔
لیکن مسئلہ وہیں ہے۔
پہلے، adminer.php نے "فائل نہیں ملی" ظاہر کیا تھا (میں نے غلط فائل اپ لوڈ کی تھی)، اور OPcache نے اس غلط مواد کے مرتب کردہ نتائج کو کیش کر دیا تھا۔ بعد میں، میں نے adminer.php کو درست کوڈ سے تبدیل کر دیا، لیکن OPcache نے اسے نظر انداز کر دیا اور میموری سے پرانے کیش کو پڑھنا جاری رکھا، جس کے نتیجے میں ایک خالی صفحہ یا پرانا ایرر میسج تھا۔
جب آپ اسے adminer1.php کا نام دیتے ہیں، تو یہ OPcache کے لیے بالکل نیا فائل پاتھ بن جاتا ہے، اور یہ اسے دوبارہ لوڈ کر کے صحیح طریقے سے حل کر دے گا۔
ایسا لگتا ہے کہ آپ نے پہلے ہی ایک نئی کتاب حاصل کر لی ہے، لیکن لائبریری کے انڈیکس کارڈ میں اب بھی پرانی کتاب کا کال نمبر موجود ہے۔ جب آپ اسے شیلف پر تلاش کرنے جاتے ہیں، یقیناً یہ خالی ہے۔ لیکن اگر آپ کتاب کا عنوان تبدیل کرتے ہیں، تو لائبریری آپ کے لیے ایک نیا انڈیکس کارڈ بنائے گی، اور پھر آپ اسے تلاش کر سکتے ہیں۔
وجہ 1: OPcache کیشے خالی جگہوں کا سبب بنتا ہے۔
اس سے نمٹنے کے لئے کس طرح؟
PHP-FPM سروس کو دوبارہ شروع کریں اور OPcache کیشے کو صاف کریں۔
# 查看正在运行的PHP版本
php -v
# 重启对应的PHP-FPM（例如PHP 8.5）
sudo systemctl restart php8.5-fpm
# 或者重启所有PHP-FPM服务
sudo systemctl restart php*-fpmدوبارہ شروع کرنے کے بعد، فائل کا نام دوبارہ adminer.php پر رکھیں، ویب پیج کو ریفریش کریں (براؤزر کو ریفریش کرنے کے لیے Ctrl+F5 دبانے کی سفارش کی جاتی ہے) اور مسئلہ حل ہونا چاہیے۔
لیکن کہانی ابھی ختم نہیں ہوئی۔
PHP-FPM کو دوبارہ شروع کرنے کے بعد، میں نے adminer.php فائل کو واپس تبدیل کیا، صفحہ کو تازہ کیا، لیکن یہ ابھی تک خالی تھا۔ میں مکمل طور پر چکرا گیا تھا۔
وجہ 2: Nginx ترتیب کے اصول کی پابندیاں
یہ دوسری ممکنہ وجہ کی طرف جاتا ہے۔
Nginx کنفیگریشن فائل میں adminer.php کو محدود کرنے والے خاص اصول ہوسکتے ہیں۔
میں نے پہلے ہیسٹیا سی پی پینل میں Fail2Ban کو کنفیگر کیا تھا اور brute-force حملوں کو روکنے کے لیے adminer.php کے لیے ایک عین مطابق میچ رول لکھا تھا ۔ قاعدہ نے فائل کا نام adminer.php کو ہارڈ کوڈ کیا، لہذا ایک بار جب آپ نے اسے adminer1.php کا نام دیا، تو آپ نے اس Nginx اصول کو نظرانداز کیا اور عام طور پر اس تک رسائی حاصل کر سکتے تھے۔
خرابیوں کا سراغ لگانے کا طریقہ آسان ہے: Nginx کنفیگریشن میں ہارڈ کوڈ شدہ اندراجات تلاش کریں۔
sudo grep -rn "adminer.php" /etc/nginx/اگر آپ کو `location = /adminer.php { … }` جیسے اصول ملتے ہیں، تو اس کا مطلب ہے کہ Nginx اس مخصوص فائل نام کو خاص طور پر سنبھال رہا ہے۔ بس اسے حذف یا ترمیم کریں۔
وجہ 3: پی ایچ پی کی خرابی ڈسپلے کی ترتیبات
تیسری وجہ زیادہ لطیف ہے۔
پی ایچ پی اسکرپٹ کو روکا جاتا ہے یا ایک غلطی پھینک دیتا ہے، لیکن صفحہ ایرر ڈسپلے کو غیر فعال کر دیتا ہے (display_errors = Off)۔ پیداواری ماحول میں، پی ایچ پی ایک خالی صفحہ دکھا کر، پہلے سے طے شدہ غلطیوں کو چھپاتا ہے۔ اگر آپ کی انٹری فائل (مثلاً index.php) "./adminer.php" کو شامل کرنے کی کوشش کے دوران کسی وجہ سے کریش ہو جاتی ہے، تو صفحہ خالی ہو جائے گا۔
اس صورت حال میں، ایرر لاگ کو چیک کرنا سب سے قابل اعتماد طریقہ ہے:
# 查看Nginx错误日志
sudo tail -n 20 /var/log/nginx/error.log
# 或者查看HestiaCP对应域名的error日志
sudo tail -n 20 /var/log/nginx/domains/adminer.domain.com.error.logلاگ آپ کو سفید اسکرین کی اصل وجہ بتائے گا۔
سچ پوچھیں تو، میں نے آخر کار error.log کو چیک کرکے مسئلہ ڈھونڈ لیا۔ پتہ چلا کہ adminer.php ایک غیر موجود PHP ایکسٹینشن کو کال کر رہا تھا، اور display_errors آف تھا، اس لیے صفحہ خالی تھا، لیکن ایرر لاگ نے اسے واضح طور پر ریکارڈ کیا۔
حل اور خرابیوں کا سراغ لگانے کے اقدامات
اس واقعے نے مجھ پر گہرا اثر چھوڑا ہے۔
تکنیکی مسائل اکثر اتنے آسان نہیں ہوتے جتنے کہ سطح پر نظر آتے ہیں۔ ایک خالی adminer.php فائل پہلی نظر میں فائل کے مسئلے کی طرح لگ سکتی ہے، لیکن گہرائی میں کھودنے سے کیشنگ کا مسئلہ سامنے آسکتا ہے، مزید نیچے یہ کنفیگریشن کا مسئلہ ہوسکتا ہے، اور پھر بھی لائن کے نیچے یہ خود کوڈ کے ساتھ مسئلہ ہوسکتا ہے۔
اگر آپ پروگرامر نہیں ہیں، تو آپ کو لگتا ہے کہ یہ چیزیں آپ کے لیے غیر متعلقہ ہیں۔ لیکن اس کے بارے میں سوچیں: آپ جو بھی ایپ استعمال کرتے ہیں، ہر ویب صفحہ جسے آپ دیکھتے ہیں، پردے کے پیچھے ایک ایسا ہی نظام چلتا ہے۔ کیشنگ، کنفیگریشن، ایرر ہینڈلنگ—یہ تصورات درحقیقت ہر جگہ موجود ہیں۔
بالکل ہم انسانوں کی طرح۔ کئی بار، ہم جن "علامات" کو ظاہر کرتے ہیں، جیسے کہ تاخیر، اضطراب اور چڑچڑاپن، سطح پر کاہلی کی طرح لگ سکتے ہیں، لیکن گہرائی میں کھودنے سے، وہ غیر واضح اہداف، مزید کھودنے، ناکامی کے خوف، اور اس سے بھی زیادہ گہری، بچپن کے تجربات سے تشکیل پانے والی ذہنیت کی وجہ سے ہو سکتے ہیں۔
اصل وجہ کا پتہ لگا کر ہی ہم صحیح دوا تجویز کر سکتے ہیں۔
آخر میں، اگر آپ کو ایک خالی adminer.php فائل کا مسئلہ بھی درپیش ہے، تو اسے اس ترتیب میں چیک کریں:
سب سے پہلے، PHP-FPM کو دوبارہ شروع کریں اور کیشے کو صاف کریں، پھر Nginx کنفیگریشن کو چیک کریں، اور آخر میں error.log کو چیک کریں۔
زیادہ تر معاملات میں، پہلے دو اقدامات مسئلے کو حل کرنے کے لیے کافی ہیں۔
یقینا، اگر یہ اب بھی کام نہیں کرتا ہے، تو پھر error.log کو چیک کریں۔
یہ آپ کو جواب بتائے گا۔
چونکہ آپ نے ابھی تک یہ پڑھا ہے، اگر آپ کو یہ مفید لگا، تو براہ کرم اسے لائک اور شیئر کریں۔ اگر آپ پہلے اپ ڈیٹس حاصل کرنا چاہتے ہیں، تو آپ مجھے بھی فالو کر سکتے ہیں!
میرا مضمون پڑھنے کے لیے آپ کا شکریہ۔ اگلی بار ملتے ہیں۔
امید ہے کہ، مضمون "Adminer.php Access Blank؟ نام تبدیل کرنا عام طور پر کام کرتا ہے؟ وجوہات کا تجزیہ اور مسئلہ کو مکمل طور پر حل کرنے کے 3 اقدامات" آپ کے لیے مددگار ثابت ہوگا ۔
اس مضمون کا لنک بلا جھجھک شیئر کریں: https://www.chenweiliang.com/cwl-34403.html