روش اطلاع از اینکه صفحهء جاری در چه فاصله ای از ریشهء پروژه قرار گرفته است

[freeman99]

من یه فایل دارم که توی صفحات مختلفی اینکلود میشه (اسمش رو بذاریم inc.php). مثلا در فایل somepage.php که در ریشهء پروژه قرار داره، و همچنین در فایل somepage2.php که در یک ساب دایرکتوری (مثلا به اسم subdir) تحت ریشهء پروژه قرار داره.
حالا توی inc.php یک لینک دارم که به فایلی در دایرکتوری ریشهء پروژه اشاره میکنه (مثلا به target.php).
حالا طبیعتا این فایل inc.php وقتی توی somepage.php اینکلود میشه آدرس href لینک HTML که تولید میکنه اینه: target.php
اما وقتی توی somepage2.php اینکلود میشه باید آدرس لینک رو به ‎../target.php تغییر بده.
پس ما باید در فایل inc.php کدی داشته باشیم که این رو تشخیص بده که الان فاصلهء صفحه تا ریشهء پروژه چقدره، و به اون تعداد از .. برای بالا رفتن در سلسله مراتب دایرکتوری ها استفاده کنه.
میخوایم روشی باشه که تاحد ممکن خودکار باشه و نیاز به نوشتن کد دستی و آپدیت دستی درصورت تغییر مکان صفحات پروژه نداشته باشه. وگرنه من مثلا قبلا در ابتدای صفحاتی که در subdir قرار داشتن متغییری تعریف کرده بودم به این شکل:

$index_dir='../';
و برای تولید لینک ها ازش استفاده میکردم.
در صفحاتی که در ریشهء پروژه بودن مقدار این متغییر خالی بود چون نیازی نبود هیچ چیزی به ابتدای آدرس نسبی لینک ها اضافه بشه و فقط نام فایل هدف واقع در ریشهء پروژه کافی بود.

من در این مورد سرچ کردم اما در صفحات پیدا شده نتایج یا اینطور بگم که روشهای چندان مرتبطی پیدا نکردم. شایدم باید کیوردها و روش سرچ خودم رو اصلاح میکردم. بهرحال خودم تعدادی از متغییرهای PHP رو که ممکنه بشه ازشون برای این کار استفاده کرد بررسی و تست کردم. تست ها چندتا فایل داره که براتون ضمیمه کردم. چون کدهای نمایش داده شده در این فروم بعضا خراب میشن دیگه اونا رو درج نمیکنم و در فایل ضمیمه میتونید مشاهده کنید.
اما خروجی این اسکریپت های تست بطور مثال به این شکله:
البته قبلش بگم که آدرسی که در مرورگر دادیم به این شکله:

http://localhost/project1/subdir/test.php/ooo/?p
و خروجی اسکریپت:

ROOT: D:/Program Files/EasyPHP-5.3.9/www/project1/

REQUEST_URI: /project1/subdir/test.php/ooo/?p

PHP_SELF: /project1/subdir/test.php/ooo/

DOCUMENT_ROOT: D:/Program Files/EasyPHP-5.3.9/www

SCRIPT_FILENAME: D:/Program Files/EasyPHP-5.3.9/www/project1/subdir/test.php

SCRIPT_NAME: /project1/subdir/test.php

ما از اجزای اضافه در انتهای آدرس استفاده کردیم تا بفهمیم در کدوم متغییرها کدامیک از این اجزای اضافه وجود دارن یا ندارن، چون این اجزای اضافه از نظر کارکرد صحیح برنامه در تمام شرایط مشکل ایجاد میکنن.
البته اینو بگم که تمام این متغییرها از ‎$_‎SERVER هستن بجز ROOT که از طریق این کد بدست اومده:

define('ROOT', str_replace('\\', '/', __DIR__).'/');
و این کد در فایلی بنام root.php که در ریشهء پروژه قرار داره هست که در ابتدای تمام صفحات اینکلود میشه.

خب، همونطور که مشاهده میکنید REQUEST_URI شامل آدرس مسیر کاملی میشه که در مرورگر وارد شده (البته این آدرس دامین رو شامل نمیشه و بخاطر همین گفتم آدرس مسیر)، منجمله تمام اجزای بعد از اسکریپت (مثلا Query string). پس این متغییر برای کار ما مناسب نیست.

در متغییر PHP_SELF هم با اینکه Query string نمیاد اما اون اطلاعاتی که به شکل آدرس دایرکتوری های مجازی در انتهای آدرس اسکریپت اضافه میشن میان (ooo). پس این متغییر هم برای کار ما مناسب نیست.

در متغییر DOCUMENT_ROOT مشاهده میکنیم که آدرس ریشه کل وب سایت رو میده و نه آدرس ریشهء پروژه و باید به این نکته دقت کرد (اگر پروژه رو در ریشهء وب خودمون قرار داده بودیم متوجه این مسئله نمیشدیم، اما به ذهنم رسید و بخاطر همین پروژه رو در یک پوشه خاص خودش در ریشهء وب گذاشتم)، و دائم دارم میگم ریشهء پروژه و نه ریشهء وب یا ریشه، به همین خاطر.
پس این متغییر هم عملا به درد ما نمیخوره.

در متغییر SCRIPT_FILENAME مشاهده میکنیم که آدرس کامل اسکریپت ما، و بدون اجزای اضافی URL، وجود داره. بنابراین این متغییر برای کار ما مناسب بنظر میاد.

در متغییر SCRIPT_NAME مشاهده میکنیم که آدرس تحت وب اسکریپت بصورت کامل و بدون اجزای جانبی آمده. شاید فکر کنیم که از این متغییر هم برای هدف ما (تعیین فاصله تا ریشهء پروژه) میشه استفاده کرد، ولی بعد توضیح میدم که چه مشکلی داره.

روشی که من بهش رسیدم اینه:

echo 'Number of \'..\'s needed: ';
echo substr_count($_SERVER['SCRIPT_FILENAME'], '/', strlen(ROOT));
یعنی ما در SCRIPT_FILENAME به میزان طول ROOT جلو میریم و تعداد اسلش های رو که از اونجا تا انتهای رشته وجود دارن میشماریم. به تعداد این اسلش ها باید در آدرس لینک خودمون از ‎../‎ استفاده کنیم. البته من نمیگم لزوما از عین همین کد به همین شکل شمارش کردن استفاده میکنیم، بلکه روش کلی کار رو دارم به یک شکل نشون میدم و شاید بشه کد مربوطه رو با توابع دیگر و به شکلهای دیگری هم نوشت (اما بهرحال ما با همین دو متغییر خاص کار میکنیم).

البته در این راه حل ما بر روی وجود متغییر SCRIPT_NAME در محیط اتکا کردیم، که باید مطمئن بشیم به خوبی همه جا پشتیبانی میشه. من روی این مسئله مطمئن نیستم چون چند سال قبل سر اینطور متغییرها افرادی میگفتن و در نت هم در منابعی آمده بود که این متغییرها در بعضی نسخه ها/(وب)سرورها/محیط ها/OS ها/... ممکنه در دسترس نباشن (حالا شاید به بعضی شرایط و کانفیگ های خاص اونا هم بستگی داشته باشه). پس اگر اطلاعاتی در این زمینه دارید بفرماید.

راستی بعد میگم که چرا استفاده از SCRIPT_NAME میتونه موجب ایجاد یک باگ پنهان بشه.

یه مورد دیگه هم که باید بگم اینه که شاید بگید خب شما که بهرحال مثلا در صفحه ای که در سابدایرکتوری قرار داره اومدی root.php رو با کد ‎require '../root.php';‎ اینکلود کردی، یعنی بهرحال مجبور بودی از .. در این صفحه استفاده کنی و یه مشخصه ای از اینکه این صفحه در این سطح در سابدایرکتوری تحت دایرکتوری ریشه قرار داره توش قرار دادی، پس صفحهء شما بازم نیاز به تعیین دستی در این زمینه داره و کاملا خودکار و مستقل و تاثیرناپذیر از تغییر مکان نیست، پس میتونستی از همون روش متغییر index_dir که خودت گفتی استفاده کنی. اما باید بگم در اون صورت مجبور بودم متغییر index_dir رو در صفحاتی که در ریشه قرار دارن هم اضافه کنم، و این کمی کثیف و کار اضافی بنظر میرسه. البته نه دقیقا مجبور هم نبودم! میتونستم در صفحات ریشه این متغییر رو اصلا درج و تعریف نکنم و بجاش در inc.php از تابع isset برای تشخیص وجود این متغییر استفاده کنم. خب اگر فکر کنیم شاید هم دست آخر ببینم این روش هم میشه و حتی ساده تر و مناسب تره! ولی بهرحال من تا اینجا این متغییرها و خواصشون رو تست کردم و یک روش خودکار برای بخشی از کاری طراحی کردم که شاید بعضی مزایایی داشته باشه و یا در بعضی موارد دیگر هم به درد بخوره و فکر میکنم شاید بعضی وقتا اینکه مسائل رو از هم جدا نگه داریم از نظر اصول و آینده نگری بهتر باشه (یعنی حالا چکار داریم به root.php و با این مسئله قاطیش نکنیم شاید در آینده اصلا یه داستان دیگری داشتیم).

[ravand]

خیلی طولانی می نویسی آدم حوصله ی خوندن این همه مطلب رو نداره. اشپیلن خدا بیامرز هم که توی این انجمن مطلب می نوشت نوشته هاش مثل شما طولانی بود . بهش میگفتم بهش بر میخورد! :لبخند: یکی از راز های موفقیت در وبلاگ نویسی خلاصه نویسی.
من برای این مشکل امدم از دستور زیر استفاده کردم:

$mo=$_SERVER['DOCUMENT_ROOT'].'/post/';
فکر میکنم توی هاست لینوکس فقط کار کنه.

[MMSHFE]

freeman99 همون اشپیلن سابقه جناب ravand
اکانت قبلیش مسدود شد اکانت جدید ساخته.

ضمناً روشی که گفتین توی ویندوز هم جواب میده.

[freeman99]

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

$mo=$_SERVER['DOCUMENT_ROOT'].'/post/';
فکر میکنم توی هاست لینوکس فقط کار کنه.
فکر کنم منظورم رو متوجه نشدی.
الان این دایرکتوری post که گذاشتی چیه؟ ریشهء پروژه؟ دایرکتوری مورد هدف آدرس لینک؟ من گفتم میخوام چیزی رو hardcode نکنم در این زمینه. برنامه باید خودش تشخیص بده که ریشهء پروژه کجاست. من میخوام از طریق همون متغییرهایی که از قبل در برنامه تعریف شدن، اسکریپت خودش بصورت خودکار آدرس ریشهء پروژه رو بدست بیاره.
البته به اینم اشاره کرده که جای دیگه عملا بنوعی hardcode استفاده شده (چون اگر هیچ کجا ریشهء پروژه به شکلی مشخص نشده باشه که وب سرور چه میدونه، از کجا میخواد اونو بهمون بده)، ولی من فکر کردم بهتره استفاده از اونو فقط به همون قسمت محدود کنم و مسائل رو به هم وابسته نکنم. هرچند باید بیشتر روش فکر کنم ببینم جنبه های مختلفش چی میتونه باشه و شاید دست آخر از همون استفاده کردم.

ضمنا من این کدها و تست و بحث رو گذاشتم چون کلا درمورد این گونه متغییرهای مختلف SERVER اطلاعات خوبی میده و نکات مهمی رو مطرح میکنه که خیلی از مبتدی ها نمیدونن. این نکات حتی به بعضی مسائل امنیتی هم ارتباط داره.

[MMSHFE]

<?php
$root = explode('/', str_replace('\\', '/', $_SERVER['DOCUMENT_ROOT']));
$path = explode('/', str_replace('\\', '/', dirname(__FILE__)));
echo '<pre>' . print_r($root, true) . '</pre>' . PHP_EOL;
echo '<pre>' . print_r($path, true) . '</pre>' . PHP_EOL;
$diff = array_diff($path, $root);
echo '<pre>' . print_r($diff, true) . '</pre>' . PHP_EOL;
/* Output:
Array
(
[0] => var
[1] => www
[2] => html
)

Array
(
[0] => var
[1] => www
[2] => html
[3] => rootpath
)

Array
(
[3] => rootpath
)
*/
?>
اتفاقاً ravand درست جواب داد دوست عزیز. شما وقتی مسیر رو از DOCUMENT_ROOT بدی دیگه نیاز نیست مسیر نسبی بدی. مسیر مطلق رو از محل ریشه پروژه میدی و میایی جلو. اگه خواستی با روش خودت هم کار کنی، کافیه توی کدی که دادم، از diff$ یه count بگیری و به همون تعداد /.. درج کنی.

[freeman99]

یه نکته ای که بنده اشاره کردم و ظاهرا هیچکدام دقت نکردید این بود که بنده این کد خاص رو در یک فایل اینکلودی دارم، نه در خود همون صفحه. این فایل اینکلودی میتونه در یک سطح دایرکتوری دیگه باشه و بنابراین نمیتونم از __FILE__ استفاده کنم چون __FILE__ آدرس کامل اون فایل اینکلودی رو میده، نه آدرس صفحهء اصلی.

یعنی مثلا بجای خروجی:

Array

(

[3] => rootpath

)


که شما گرفتی میشه:

Array
(
[3] => rootpath
[4] => include
)
البته اگر از این کد شما استفاده کنیم.
درحالیکه من میخوام آدرس صفحهء اصلی رو (نه خود فایل اینکلود شده) از نظر وب بدست بیارم. متغییرهای آدرس فیزیکی روی سرور اینجا درست کار نمیکنن.

[MMSHFE]

خوب در اینصورت هم میشه بجای __FILE__ از $_SERVER['SCRIPT_FILENAME'] استفاده کرد.

[MMSHFE]

برای رهایی از تمام این دردسرها هم میشه اینطوری کار کنین:

defined('ADDR') or define('ADDR', 'http://localhost/mysite/');
defined('ROOT') or define('ROOT', str_replace('\\', '/', dirname(__FILE__));
این کد رو توی فایلی که همه جا اینکلود میشه (مثل config) بگذارین و بعد همه جا آدرس مطلق بدین. هرجا نیاز به include بود از ثابت ROOT استفاده کنید و هرجا نیاز به آدرسدهی سمت کلاینت بود (مثل src عکسها یا href لینکها) از ADDR استفاده کنید. درنهایت میشه به راحتی با تغییر این ثابتها (درصورت تغییر مکان پروژه) همه جا دوباره به آدرس صحیح رسید.

آدرس دهی نسبی دیگه تقریباً منسوخ شده و بجز در مواردی مثل داخل فایلهای CSS و... استفاده نمیشه.

[freeman99]

البته فکر کنم روش شما یه اشکال اصلی دیگه هم داره.
ریشهء پروژه لزوما در یک دایرکتوری پایین تر از DOCUMENT_ROOT نیست، بلکه ممکنه هرچند دایرکتوری عمق داشته باشه.
مثلا ریشهء پروژه اگر /subdir1/rootpath/ باشه، روش شما باعث میشه به subdir1 آدرس بدیم، درحالیکه ریشهء واقعی پروژه در یک سطح پایین تر است.
اینا نکاتی بود که بنده همه رو در نظر گرفتم و در توضیحات هم سعی کردم همه جزییات لازم رو اشاره کنم بخاطر همین.

[MMSHFE]

همه این مشکلات با آدرس دهی مطلق و استفاده از ثابتها قابل برطرف کردنه و نیازی نیست اینقدر سربار محاسباتی واسه تولید هر لینک و توی هر درخواست، به برنامه تحمیل کنید.

[freeman99]

برای رهایی از تمام این دردسرها هم میشه اینطوری کار کنین:
[PHP]defined('ADDR') or define('ADDR', 'http://localhost/mysite/');
...
این کد رو توی فایلی که همه جا اینکلود میشه (مثل config) بگذارین و بعد همه جا آدرس مطلق بدین. ... و هرجا نیاز به آدرسدهی سمت کلاینت بود (مثل src عکسها یا href لینکها) از ADDR استفاده کنید. درنهایت میشه به راحتی با تغییر این ثابتها (درصورت تغییر مکان پروژه) همه جا دوباره به آدرس صحیح رسید.

بله این روش رو قبلا دیده بودم. دقیقا بنده خواستم از اضافه شدن اینطور روشهای دستی و hardcode کردن که با تغییر محیط نیاز به اصلاح داشته باشن پرهیز کنم.


آدرس دهی نسبی دیگه تقریباً منسوخ شده و بجز در مواردی مثل داخل فایلهای CSS و... استفاده نمیشه.
واسه چی چرا منبع و سندش چی؟
آدرس دهی نسبی هم مزایا و کاربردهای خودش رو داره خب.
البته شاید نهایت منم به این برسم که همین روش کانفیگ دستی در کل راحتتره و روشهای دیگه ارزش پیچیدگیشون رو ندارن یا دچار ضعفهایی هستن و در بعضی شرایط خاص به مشکل میخورن. ولی فعلا دنبال خودکار کردن تاحد امکان هستم و اینکه تعداد این موارد رو به حداقل برسونم.

[freeman99]

همه این مشکلات با آدرس دهی مطلق و استفاده از ثابتها قابل برطرف کردنه و نیازی نیست اینقدر سربار محاسباتی واسه تولید هر لینک و توی هر درخواست، به برنامه تحمیل کنید.
مهندس فکر نمیکنم اونقدری سربار محاسباتی داشته باشه که این مسئله جزو پارامترهای تاثیرگذار محسوب بشه.
یک عملیات رشته ای ساده ای هست با چندتا متغییر و تابع معمولی درونی که قاعدتا سرعتشون خیلی بالاست و منابع ناچیزی مصرف میکنن.
ضمنا ما نمیخوایم برای هر لینک هربار این کد رو تکرار کنیم، بلکه در صفحاتی که نیازه یک بار این کد رو اجرا میکنیم و نتیجه رو توی یک متغییر یا ثابت ذخیره میکنیم و بعد در همهء لینک هایی که در اون صفحه و در اسکریپت های اینکلود شده تولید خواهند شد از اون متغییر استفاده میکنیم (میتونیم قبل از اجرای کد در هر اسکریپت اینکلود شده، اول چک کنیم که آیا اون متغییر/ثابت از قبل تعریف شده یا نه و اگر تعریف شده بود یعنی این کد و پردازش قبلا صورت گرفته و میتونیم از مقدارش استفاده کنیم - گذشته از اینکه حالا فرضا این کد در فایلهای اینکلود شده در هرکدام یک بار هم اجرا بشه بازم بار پردازشی بحساب آمدنی نداره).

[MMSHFE]

واسه چی چرا منبع و سندش چی؟
منبع و سند اینکه توی هیچ پروژه و فریمورک بزرگ و امروزی دیگه ازش استفاده نمیشه.

آدرس دهی نسبی هم مزایا و کاربردهای خودش رو داره خب.
خودکار کردن همیشه سربارهایی داره. مزایا و کاربردهای آدرس دهی نسبی هم به اندازه عیب و ایرادها و سربارهایی که توی آدرسدهی میگذاره نیست. برای مثال اگه بخوایم وارد مباحث سیستم عامل بشیم هم میبینی که پیداکردن و دنبال کردن inodeها (برای رسیدن به parent و...) زحمت بیشتری به File System میده تا اینکه بیایم از مسیر ریشه مستقیم بریم پایین تا به فایل برسیم.

[MMSHFE]

ضمنا ما نمیخوایم برای هر لینک هربار این کد رو تکرار کنیم، بلکه در صفحاتی که نیازه یک بار این کد رو اجرا میکنیم و نتیجه رو توی یک متغییر یا ثابت ذخیره میکنیم و بعد در همهء لینک هایی که در اون صفحه و در اسکریپت های اینکلود شده تولید خواهند شد از اون متغییر استفاده میکنیم (میتونیم قبل از اجرای کد در هر اسکریپت اینکلود شده، اول چک کنیم که آیا اون متغییر/ثابت از قبل تعریف شده یا نه و اگر تعریف شده بود یعنی این کد و پردازش قبلا صورت گرفته و میتونیم از مقدارش استفاده کنیم - گذشته از اینکه حالا فرضا این کد در فایلهای اینکلود شده در هرکدام یک بار هم اجرا بشه بازم بار پردازشی بحساب آمدنی نداره).

این عمل توی هر درخواست داره تکرار میشه.

[freeman99]

منبع و سند اینکه توی هیچ پروژه و فریمورک بزرگ و امروزی دیگه ازش استفاده نمیشه.
بله شاید.
راستی چرا آدرس ریشه رو با دامین بدیم؟ نمیشه بخش دامین رو برداریم؟ چون در HTML نیازی نیست آدرس مطلق و شامل دامین داده بشه.
منظورم این کده:

defined('ADDR') or define('ADDR', 'http://localhost/mysite/');


خودکار کردن همیشه سربارهایی داره. مزایا و کاربردهای آدرس دهی نسبی هم به اندازه عیب و ایرادها و سربارهایی که توی آدرسدهی میگذاره نیست. برای مثال اگه بخوایم وارد مباحث سیستم عامل بشیم هم میبینی که پیداکردن و دنبال کردن inodeها (برای رسیدن به parent و...) زحمت بیشتری به File System میده تا اینکه بیایم از مسیر ریشه مستقیم بریم پایین تا به فایل برسیم.

این میشه بحثهای بهینه سازیهای جزیی که میدونید در گذشته چقدر روش بحث و جنجال داشتیم :لبخند:
سربار داره ولی اساسا هرکاری بکنی هرجور حساب کنی این سربار بازم در برابر عظمت پردازشهای برنام های امروزی و قدرت و منابعی که کامپیوترها دارن و باید داشته باشن، ناچیزه و بحساب نیامدنی. اینطور بخوایم فکر کنیم که توی زبانهای سطح بالا دوباره باید سطح پایین فکر کنیم و از خیلی امکانات راه دست اونا استفاده نکنیم و کار خودمون رو سخت کنیم بخاطر این مقدارهای ناچیز سربار که در خیلی مسائل دیگر هم هست. ولی البته نمیگم که این جزییات ریز رو در هیچ پروژه و هدفی درنظر نمیگیریم و لحاظ نمیکنیم، ولی در یه سایت و پروژهء معمولی و شخصی و یا چیزی که در مقیاس و کارهای بزرگ و ترافیک های واقعا سنگینی نمیخواد اجرا بشه و تعداد زیادی از این عملیات در کدهای برنامه وجود ندارن بنظر من هیچ دلیل منطقی وجود نداره که بخوایم به این بهینه سازیهای واقعا جزیی حتی فکر هم بکنیم!
اساسا خودکارسازی خودش پارامتر خیلی مهم و مفیدیه در تقریبا تمام چیزها و اهداف. یکی از چیزهایی هم که در یک مقاله ای راجع به فلسفهء یونیکس فکر کنم قبلا ترجمه کردم بودم همین بود اشاره کرده بود که وقتی میتونید کاری رو خودکار کنید و بذارید کامپیوتر بجاتون انجام بده همین کار رو بکنید (حتی تولید کد برنامه رو). این فقط بخاطر کم کردن زحمت خودمون نیست، بلکه دخالت و خطاهای انسانی رو هم در کل و در نهایت کاهش میده.

[MMSHFE]

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

[freeman99]

این عمل توی هر درخواست داره تکرار میشه.
دیگه خدایی فکر نمیکردم این حرف رو بزنی :متعجب:
مهندس این دیگه معمولا شدیدترین درجهء جزیی بودن بار پردازشیه که در عمل در اکثر موارد میتونه وجود داشته باشه!
در هیچ منبعی هیچ برنامه نویس معتبری نمیاد به همچین چیزایی گیر بده. شما منابع مربوط به فلسفه و اصول بهینه سازی (نه خود متدهای فنیش رو) رو بخونی مثال از بهینه سازیهای افراطی و بی فایده و حتی مضر از جهات دیگر که زدن قطعا شامل چنین مواردی میشه، بلکه مثالهایی که میزنن اغلب بهینه سازیهای به مراتب درشت تری از این هم هستن.
اون همه هم بنده مقاله براتون ترجمه کردم این همه منبع هست که دربارهء بهینه سازی خواستن ذهنیت درستی بدن و از افراط در این زمینه جلوگیری کنن، پس چی دارن میگن راجع به چی صحبت میکنن؟ دیگه این موارد در این حد جزوش نباشه که هیچی باقی نمیمونه برای حرف زدن!

[MMSHFE]

بحث رو به حاشیه و Off Topic نکشون. شما گفتی چطور میشه تعداد پوشه اختلاف بین مسیر جاری و مسیر ریشه رو بدست آورد. من هم روشش رو گفتم. دیگه میخوای با روش خودت کار کنی یا با ترکیب روشی که گفتم و مقادیری مثل SCRIPT_FILENAME و... به خودت مربوط میشه. تاپیک قفل شد.