رفع خطای Static در Django روی هاست پایتون؛ راهنمای Static و Media

اول مشخص کنید کدام فایل به مقصد نمی‌رسد

اگر صفحهٔ جنگو باز می‌شود اما ظاهر آن به‌هم‌ریخته است، از درخواست همان فایل CSS در مرورگر شروع کنید. اگر ظاهر صفحه سالم است اما عکس کاربر نمایش داده نمی‌شود، ابتدا نشانی عکس و محل نگهداری فایل آپلودشده را بررسی کنید. برای رفع خطای static در Django باید سه چیز را کنار هم ببینید: نشانی تولیدشده در HTML، محل واقعی فایل و قانونی که درخواست عمومی را به آن محل می‌رساند. دستور collectstatic فقط بخش گردآوری فایل‌های استاتیک را انجام می‌دهد. فایل‌های رسانه‌ای کاربران چرخهٔ جداگانه‌ای دارند و معمولاً باید در فضایی پایدار نگهداری شوند که با انتشار نسخهٔ بعدی پاک نشود.

یک آزمون کوچک پیش از هر تغییر بزرگ انجام دهید. در یک صفحه که مشکل دارد، یک CSS ناموفق انتخاب کنید. نشانی کامل آن را بردارید، ببینید مرورگر چه وضعیتی گزارش می‌کند و نوع پاسخ را یادداشت کنید. همین کار را روی یک تصویر آپلودشده انجام دهید. در بیشتر پروژه‌ها همین دو مشاهده کمک می‌کند کار از «سایت روی هاست به‌هم ریخته» به گزارشی قابل پیگیری تبدیل شود. وقتی به پشتیبانی گزارش می‌دهید، زمان درخواست، نشانی فایل و کد پاسخ را بدهید. نام کاربری، رمز، محتوای فایل خصوصی و مقدار متغیرهای محرمانه را از گزارش حذف کنید.

فهرست مطالب

• تشخیص با ابزار Network مرورگر
• تفاوت فایل استاتیک و رسانهٔ کاربر
• اجرای collectstatic و بررسی خروجی
• نگاشت مسیر عمومی در هاست
• حفاظت و بکاپ Media
• انتشار، کش و برگشت نسخه
• چک‌لیست خرید هاست پایتون برای یک پروژهٔ Django
• پرسش‌های متداول

تشخیص با ابزار Network مرورگر

 

درخواست واقعی را پیدا کنید

صفحهٔ مشکل‌دار را باز کنید و در ابزار توسعهٔ مرورگر وارد زبانهٔ Network شوید. در حالی که ابزار باز است یک بار صفحه را بارگذاری کنید. از فیلتر CSS، JS یا Img برای محدود کردن نتایج استفاده کنید. روی درخواست خطادار کلیک کنید و URL، وضعیت، نوع محتوا و مقصد نهایی بعد از تغییر مسیر را ببینید. گاهی نشانی اولیه کاملاً درست است اما پاسخ نهایی از صفحهٔ ورود، صفحهٔ خطای سایت یا حتی یک دامنهٔ قدیمی می‌آید. چنین پاسخی ممکن است وضعیت ۲۰۰ داشته باشد. بررسی بدنه و هدر Content-Type در اینجا از خود عدد وضعیت ارزش بیشتری دارد.

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

کد پاسخ چگونه مسیر بررسی را تعیین می‌کند؟

در پاسخ ۴۰۴ ابتدا بررسی کنید فایل زیر همان مسیر نسبی در مقصد مورد انتظار موجود است. اگر فایل وجود دارد، مسیر عمومی یا میزبان درخواست را بررسی کنید. در پاسخ ۴۰۳ ابتدا مشخص کنید منبع باید عمومی باشد یا خصوصی. برای یک منبع عمومی، کاربر اجراکنندهٔ سرویس و سیاست دسترسی مسیر اهمیت دارد. برای رسانهٔ خصوصی، ۴۰۳ گاهی رفتار درست سیستم است. در پاسخ ۲۰۰ با محتوای HTML، بدنهٔ پاسخ و زنجیرهٔ تغییر مسیر را بررسی کنید تا مشخص شود کدام بخش درخواست فایل را به صفحه تبدیل کرده است. خطای ۵۰۰ را با زمان و شناسهٔ درخواست در لاگ همان سرویس تطبیق دهید.

گاهی ابزار Network درخواست را با عبارتی مانند blocked نشان می‌دهد و پاسخ واقعی از سرور در اختیار شما نیست. برای نمونه، صفحهٔ HTTPS ممکن است نشانی HTTP یک فایل را درخواست کند و مرورگر آن را مسدود کند. Console در این وضعیت شرح روشن‌تری می‌دهد. همچنین به خطاهای بارگذاری فونت یا سیاست‌های مرورگر توجه کنید. رفع چنین خطایی با اصلاح نشانی، پروتکل یا تنظیم متناسب با همان نوع منبع آغاز می‌شود. ابتدا مطمئن شوید درخواست واقعاً به سرور رسیده و سپس دربارهٔ جمع‌آوری فایل یا تغییر مجوز تصمیم بگیرید.

نمونهٔ کاربردی: فایل CSS با وضعیت ۲۰۰ و پاسخ HTML

فرض کنید یک پروژهٔ آموزشی روی دامنهٔ آزمایشی نصب شده است. صفحهٔ ورود سالم باز می‌شود و درخواست فایل اصلی CSS هم ظاهراً وضعیت ۲۰۰ دارد. در بخش Response صفحهٔ اصلی سایت را می‌بینید. این نشانه با یک مسیریابی عمومی که درخواست فایل را هم به برنامه می‌دهد سازگار است. نشانی CSS را مستقیماً درخواست کنید و نام دامنه و پیشوند را ثبت کنید. بعد از پنل یا پشتیبانی بخواهید مشخص کند چه لایه‌ای فایل‌های این پیشوند را سرو می‌کند. وقتی همان URL پاسخ CSS با نوع محتوا و بدنهٔ درست داد، صفحه را دوباره بارگذاری کنید. به این ترتیب تغییر با یک معیار دقیق تأیید می‌شود.

تفاوت فایل استاتیک و رسانهٔ کاربر

Static ورودی انتشار است

فایل‌های CSS، JavaScript، فونت و تصاویر طراحی معمولاً همراه کد یا خروجی ساخت رابط کاربری نسخه‌بندی می‌شوند. اگر فایل‌های رابط با یک ابزار ساخت تولید می‌شوند، خروجی آن باید پیش از collectstatic در مسیری قرار بگیرد که Django بتواند آن را پیدا کند. بعضی تیم‌ها این ترتیب را در محیط توسعه رعایت می‌کنند و در محیط انتشار فقط مرحلهٔ Python را اجرا می‌کنند. نتیجه می‌تواند ظاهری کامل روی لپ‌تاپ و یک صفحهٔ بدون استایل روی هاست باشد. برای رفع مشکل، نام و مسیر نسبی یک فایل مشخص را از ابتدا تا انتهای زنجیره دنبال کنید.

در تنظیمات معمول ذخیره‌سازی محلی، STATIC_URL پیشوند یا نشانی‌ای است که در HTML برای دسترسی به فایل دیده می‌شود. STATIC_ROOT دایرکتوری خروجی گردآوری فایل‌ها است. STATICFILES_DIRS در صورت نیاز مسیرهای ورودی اضافی را معرفی می‌کند. این سه تنظیم را جداگانه در برگهٔ استقرار بنویسید. اگر از یک backend ذخیره‌سازی بیرونی استفاده می‌کنید، رفتار جمع‌آوری و محل خروجی تابع پیکربندی آن backend است. بنابراین از همان تنظیماتی که محیط عملیاتی بارگذاری می‌کند نمونه بگیرید و فرض یکسان بودن همهٔ محیط‌ها را کنار بگذارید.

Media دادهٔ کاربران و برنامه است

یک تصویر پروفایل یا سندی که کاربر فرستاده، در طول عمر برنامه ایجاد می‌شود و ممکن است فقط همان یک نسخه در محیط واقعی موجود باشد. در تنظیمات محلی معمول، MEDIA_ROOT محل نگهداری فایل‌ها و MEDIA_URL نشانی دسترسی عمومی به فایل‌های مجاز است. فایل‌های خصوصی ممکن است اصلاً مسیر عمومی نداشته باشند و از راه کنترل‌شده تحویل داده شوند. نسخهٔ پایدار سایت باید بتواند فایل‌های قبلی را پس از انتشار نسخهٔ جدید پیدا کند. بنابراین در طراحی انتشار، رسانه را از دایرکتوری نسخه‌ای که هر بار جایگزین می‌شود جدا کنید.

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

اجرای collectstatic و بررسی خروجی

«run the collectstatic command when static files change» — مستندات رسمی Django

محیط اجرای دستور را با محیط سایت تطبیق دهید

پیش از اجرا، در محیط مجازی پروژه وارد شوید و از همان تنظیماتی استفاده کنید که برنامهٔ مقصد بارگذاری می‌کند. اگر چند فایل تنظیمات دارید، فقط نام ماژول فعال و مسیرهای غیرمحرمانهٔ مربوط به استاتیک را بررسی کنید. فرمان را از محل پروژه‌ای اجرا کنید که manage.py مورد انتظار در آن قرار دارد. در ساختارهایی با چند نسخهٔ هم‌زمان، مسیر نسخهٔ در حال اجرا را با مسیر نسخه‌ای که روی آن فرمان اجرا می‌کنید مقایسه کنید. خروجی درست در پوشهٔ نسخهٔ اشتباه، از دید کاربر همچنان یک خطای استاتیک است.

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

از پیدا کردن فایل تا بررسی گردآوری

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

python manage.py findstatic css/site.css --verbosity 2
python manage.py collectstatic --dry-run --noinput
python manage.py collectstatic --noinput

بررسی نمونه در مسیر خروجی

یک فایل مدیریت، یک فایل اختصاصی پروژه و یک فایل تولیدشدهٔ رابط را انتخاب کنید. برای هر کدام مسیر نسبی را با نشانی‌ای که مرورگر مصرف می‌کند مقایسه کنید. اگر ذخیره‌سازی مبتنی بر manifest دارید، ممکن است نام خروجی شامل شناسهٔ محتوایی باشد. در چنین حالتی نام نهایی را از HTML واقعی یا manifest همان نسخه بگیرید. باز کردن یک نام قدیمی که در هیچ صفحه‌ای استفاده نمی‌شود، معیاری برای سلامت نسخهٔ فعلی نیست.

تطبیق manifest با نسخهٔ برنامه

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

یک معیار پذیرش برای نسخهٔ جدید

آزمون پذیرش ساده این است که برای سه منبع نمونه، هم درخواست صفحه و هم درخواست مستقیم هر فایل با نتیجهٔ صحیح برگردد. نوع محتوا و بدنهٔ پاسخ را نیز بررسی کنید. اگر پروژه چند دامنه یا زیردامنه دارد، آزمون را روی دامنه‌ای اجرا کنید که کاربران واقعاً باز می‌کنند. نتیجهٔ مثبت یک ابزار داخلی یا اجرای موفق فرمان، تنها بخشی از این آزمون است. معیار نهایی آن است که صفحهٔ عملیاتی منابع درست همان نسخه را دریافت کند.

نگاشت مسیر عمومی در هاست

مسئول سرو فایل را پیدا کنید

یک برنامهٔ جنگو ممکن است صفحه را از یک فرایند Python تحویل دهد و فایل‌های استاتیک را وب‌سرور، سامانهٔ ذخیره‌سازی یا سازوکار دیگری عرضه کند. معماری پروژهٔ خودتان را با رسم سه خانه روی کاغذ مشخص کنید: مرورگر، نقطهٔ ورود عمومی و مقصد فایل. زیر نقطهٔ ورود بنویسید دامنه و مسیر چگونه تشخیص داده می‌شوند. زیر مقصد بنویسید فایل در چه مکانی و با چه نام نسبی نگهداری می‌شود. اگر میان این دو کش یا پراکسی قرار دارد، آن را هم اضافه کنید. هنگام دیدن ۴۰۴، هر خانه یک سؤال مشخص برای بررسی فراهم می‌کند.

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

الگوی بررسی برای دامنه و زیردامنه

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

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

آزمون تغییر مسیر و نوع محتوا

برای تشخیص بهتر، در پاسخ فایل سه نشانه را بررسی کنید. اول وضعیت اولیه و نهایی. دوم نوع محتوا. سوم بخشی از بدنه که نشان دهد فایل درست برگشته است. یک CSS مورد انتظار باید پاسخ مناسب CSS داشته باشد و مشاهدهٔ عنوان صفحهٔ ورود در بدنه نشان می‌دهد درخواست از مسیر دیگری عبور کرده است. روی تصویر هم می‌توانید پاسخ را در مرورگر باز کنید و انتظار داشته باشید همان عکس نمونه دیده شود. صرف داشتن پسوند درست در URL هیچ‌کدام از این نشانه‌ها را تضمین نمی‌کند.

مشاهده	محتمل‌ترین سؤال بعدی	معیار تأیید
CSS خطای ۴۰۴ دارد	فایل نهایی در مقصدی که درخواست به آن می‌رسد وجود دارد؟	همان URL پاسخ CSS می‌دهد
تصویر عمومی ۴۰۳ است	مسیر مجاز و هویت سروکننده مشخص است؟	فایل نمونه با سیاست مجاز خوانده می‌شود
درخواست فایل HTML برمی‌گرداند	تغییر مسیر، fallback یا صفحهٔ خطا کدام است؟	بدنهٔ پاسخ واقعاً محتوای مورد انتظار است
فقط منابع نسخهٔ جدید مشکل دارند	فایل و manifest از یک انتشار آمده‌اند؟	نسخهٔ صفحه و فایل‌های هش‌دار هماهنگ‌اند
تصویر خصوصی برای همه باز است	آیا مسیر تحویل کنترل دسترسی دارد؟	کاربر مجاز فایل را می‌بیند و درخواست ناشناس رد می‌شود

مجوز خواندن فایل و نقش حساب اجراکننده

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

اگر برنامه هنگام آپلود خطا می‌دهد، مسیر بررسی با شکست دانلود متفاوت است. در آپلود، برنامه باید اجازهٔ ایجاد فایل یا دسترسی به backend ذخیره‌سازی داشته باشد. پس از ایجاد، مسیر تحویل باید بتواند مطابق سیاست فایل را بخواند. یک گزارش دقیق مشخص می‌کند آیا در همان لحظهٔ ارسال خطا دیده شده، یا فرم موفق بوده و فقط لینک فایل مشکل دارد. در حالت دوم کلید فایل ثبت‌شده را با مقصد ذخیره مقایسه کنید. گاهی رکورد به کلیدی درست اشاره می‌کند اما همان فایل در محیط مقصد منتقل نشده است.

حفاظت و بکاپ Media

دسترسی عمومی را از فایل خصوصی جدا کنید

تصویر مقالهٔ عمومی و مدارک مشتری دو کلاس دادهٔ متفاوت هستند. پیش از تعریف MEDIA_URL، یک فهرست از گروه‌های فایل بسازید و کنار هر گروه بنویسید چه کسی باید آن را بخواند. فایل عمومی می‌تواند از مسیر مستقیم در دسترس قرار گیرد، به شرط آنکه این رفتار برای نوع داده مناسب باشد. فایل خصوصی به مسیری نیاز دارد که هویت و اجازهٔ درخواست‌کننده را کنترل کند. محل ذخیره، روش لینک‌سازی و سیاست کش را بر همین اساس انتخاب کنید. در محیط آزمایشی، آزمون را هم با حساب مجاز و هم بدون نشست اجرا کنید.

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

انتقال فایل‌ها در کنار داده‌های برنامه

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

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

نمونهٔ کاربردی: عکس‌های قدیمی پس از انتشار جدید ناپدید شده‌اند

فرض کنید پس از یک انتشار، عکس‌هایی که همان روز بارگذاری شده‌اند دیده می‌شوند اما عکس‌های قدیمی در صفحهٔ پروفایل ۴۰۴ دارند. نخست یک رکورد قدیمی و یک رکورد جدید را کنار هم بررسی کنید. اگر نشانی هر دو از یک ساختار پیروی می‌کند، مقصد ذخیرهٔ فعال را ببینید. شاید پوشهٔ رسانه به نسخهٔ جدید وابسته شده و فقط فایل‌های جدید در آن وجود دارند. در این سناریو، بازگرداندن فایل‌های قبلی به محل پایدار و اصلاح اتصال انتشار به آن محل از بازتولید فایل استاتیک جداست.

قبل از اجرای اصلاح روی محیط اصلی، با کپی مجاز چند فایل در محیط آزمایشی مسیر را بررسی کنید. سپس تأیید کنید انتشار یک نسخهٔ جدید مسیر داده را عوض نمی‌کند. از مسیر ذخیره و مجوزهای لازم یک یادداشت عملیاتی کوتاه تهیه کنید. وقتی بعداً همکار دیگری برنامه را مستقر می‌کند، باید بداند پوشهٔ نسخه می‌تواند جایگزین شود و دادهٔ کاربران از مسیر تعریف‌شدهٔ مستقل خوانده می‌شود. همین توضیح کوچک می‌تواند عیب تکرارشونده را از فرایند انتشار حذف کند.

انتشار، کش و برگشت نسخه

انتشار را با چند آزمون قابل تکرار ببندید

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

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

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

دو مرورگر ممکن است رفتار متفاوتی نشان دهند، چون یکی HTML قدیمی در حافظه دارد یا از مسیر متفاوتی به محتوا می‌رسد. در پنجرهٔ خصوصی یا با غیرفعال کردن کش در ابزار توسعه، همان صفحه را آزمایش کنید. سپس نشانی فایل در HTML قدیمی و جدید را کنار هم بگذارید. اگر فایل جدید از نشانی مورد انتظار خوانده می‌شود و فقط بعضی نشست‌ها ظاهر قدیمی دارند، بررسی کش HTML منطقی است. اگر منبع جدید در همهٔ نشست‌ها ۴۰۴ دارد، ابتدا موجود بودن فایل و نگاشت مسیر را بررسی کنید.

برای منابع تغییرناپذیر دارای نام محتوایی، نام جدید می‌تواند نسخهٔ تازه را مشخص کند. با این حال HTML ممکن است مدتی به نام نسخهٔ قبلی اشاره کند. اگر انتشار بلافاصله خروجی قدیمی را پاک کند، حتی با سالم بودن فایل‌های جدید تعدادی از کاربران فایل قبلی را پیدا نمی‌کنند. پیش از تغییر سیاست پاک‌سازی، به مدت نگهداری HTML، نحوهٔ بازگشت نسخه و فضای واقعی سرو توجه کنید. در سرویس‌های اشتراکی، جزئیات این سیاست را از پنل یا پشتیبانی بپرسید و بر اساس پاسخ تأییدشده تصمیم بگیرید.

برگشت نسخهٔ کد را از بازیابی فایل کاربران جدا کنید

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

برای رسانه، تغییر نسخه نباید فایل‌هایی را که کاربر در این فاصله آپلود کرده حذف کند. در سناریوی بازیابی کامل، مشخص کنید چه بازه‌ای ممکن است نیاز به همگام‌سازی داشته باشد و چه کسی تصمیم بازیابی را می‌گیرد. در گزارش داخلی فرق «برگشت کد»، «جایگزینی خروجی استاتیک» و «بازیابی داده» را روشن کنید. همین تفکیک باعث می‌شود هنگام رخداد، برای رفع یک خطای CSS سراغ بکاپ همهٔ اطلاعات نروید.

مثال کاربردی: مدیریت جنگو سالم است اما رابط سفارشی بدون استایل است

اگر صفحهٔ مدیریت درست بارگذاری می‌شود، حداقل بخشی از استاتیک برنامه از دامنهٔ مورد آزمایش خوانده می‌شود. برای رابط سفارشی از قالب یا HTML واقعی مسیر فایل را بگیرید. بررسی کنید خروجی مرحلهٔ ساخت رابط در زمان جمع‌آوری حاضر بوده است. اگر نبود، ترتیب انتشار را اصلاح کنید. اگر حاضر بود، نام فایل و مسیر زیرپوشه را در findstatic و سپس در خروجی واقعی بررسی کنید. ممکن است منابع مدیریت و رابط سفارشی از دو پیشوند جدا استفاده کنند. سلامت یکی فقط داده‌ای برای محدود کردن بررسی است.

پس از اصلاح، تست را روی صفحه‌ای انجام دهید که کاربر خطا را در آن دیده است. صرف دیدن یک فایل در پوشهٔ پروژه به معنی رفع مشکل نیست. مرورگر باید همان فایل را از همان URL با نوع محتوا و وضعیت درست بگیرد. اگر پروژه چند نسخه دارد، زمان انتشار و شناسهٔ نسخهٔ بررسی‌شده را ثبت کنید. این یادداشت برای بعد مفید است زیرا نشان می‌دهد چه چیزی در زنجیره از دست رفته بود و کدام آزمون از بازگشت آن جلوگیری می‌کند.

چک‌لیست خرید هاست پایتون برای یک پروژهٔ Django

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

اول نسخهٔ Django و Python، روش اجرای برنامه و مدل استقرار را مشخص کنید. بعد بپرسید آیا اجرای فرمان مدیریت پروژه با محیط درست امکان دارد و کدام شخص می‌تواند نگاشت استاتیک را تغییر دهد. اگر تیم فقط دسترسی محدود به پنل دارد، بپرسید تغییر مسیر استاتیک از داخل پنل انجام می‌شود یا با درخواست به پشتیبانی. در پاسخ، دنبال یک نمونهٔ عملی برای یک URL و محل فایل باشید. جملهٔ کلی «از Django پشتیبانی می‌شود» برای مشخص کردن مراحل اجرایی کافی نیست.

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

نیاز پروژه	پرسش پیش از خرید	نتیجهٔ قابل آزمایش
اجرای فرمان مدیریت Django	چه دسترسی‌ای برای اجرای collectstatic دارم؟	یک فرمان نمونه در محیط صحیح اجرا می‌شود
سرو CSS و JavaScript	چه کسی مسیر عمومی فایل‌ها را تنظیم می‌کند؟	یک CSS از URL عمومی با پاسخ صحیح می‌آید
نگهداری آپلود کاربر	مسیر پایدار و محدودهٔ بکاپ چیست؟	پس از تعویض نسخه، فایل نمونه هنوز موجود است
رسانهٔ خصوصی	بررسی مجوز در مسیر تحویل چگونه انجام می‌شود؟	درخواست ناشناس رد و درخواست مجاز موفق می‌شود
بازگشت انتشار	روش نگهداری فایل‌های نسخهٔ قبل چیست؟	نسخهٔ قبلی با دارایی‌های خودش قابل آزمایش است

یک سؤال خوب برای پشتیبانی چه شکلی دارد؟

به‌جای درخواست عمومی برای «فعال کردن استاتیک»، شرح دهید که پروژه چه نشانی‌ای تولید می‌کند و فایل نمونه کجا قرار دارد. نمونهٔ متن این است: «برنامهٔ Django در دامنهٔ آزمایشی اجرا می‌شود. برای یک فایل CSS، URL و مسیر نسبی را ثبت کرده‌ام. فایل در خروجی جمع‌آوری موجود است اما همان URL در مرورگر HTML برمی‌گرداند. لطفاً بفرمایید کدام تنظیم پنل درخواست این پیشوند را به محل خروجی وصل می‌کند.» در درخواست واقعی، نشانی عمومی نمونه و زمان آزمون را اضافه کنید و اطلاعات محرمانه را حذف کنید.

اگر هنوز در مرحلهٔ انتخاب سرویس هستید، از صفحهٔ هاست پایتون وطن هاست شروع کنید و پرسش‌های جدول را با نیازهای پروژه تطبیق دهید. برای مقایسهٔ شیوهٔ اجرای پروژه‌ها، راهنمای انتخاب هاست برای Django و Flask را بخوانید. اگر پروژه در حال جابه‌جایی است، چک‌لیست انتقال پروژهٔ پایتون به شما کمک می‌کند ترتیب انتقال محیط، پایگاه داده و آزمون را مشخص کنید. برای یک سایت مکمل که به اجرای برنامهٔ Python وابسته نیست، صفحهٔ هاست لینوکس را جداگانه متناسب با نیاز همان سایت بررسی کنید.

الگوی ثبت نتیجه برای تیمی که چند محیط دارد

اگر پروژه روی محیط توسعه، آزمایش و تولید اجرا می‌شود، یک رکورد کوتاه برای هر محیط نگه دارید. در آن، دامنهٔ عمومی، روش اجرای برنامه، مسیر نسبی یک فایل استاتیک نمونه و نام backend رسانه را بنویسید. یک ستون دیگر به نتیجهٔ آزمون اختصاص دهید. نوشتن «همه‌چیز درست است» ارزش کمی دارد. نتیجه‌ای مثل «درخواست مستقیم CSS در دامنهٔ آزمایش موفق است اما در تولید صفحهٔ ورود را نشان می‌دهد» تفاوت را قابل بررسی می‌کند. اطلاعات احراز هویت را در این برگه وارد نکنید.

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

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

یک اجرای آزمایشی با فایل کم‌حجم و بی‌خطر

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

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

در گزارش پشتیبانی چه اطلاعاتی مفید است؟

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

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

چرا با DEBUG روشن فایل‌ها باز می‌شوند و پس از استقرار خراب‌اند؟

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

آیا اجرای collectstatic فایل‌های آپلودی کاربران را منتقل می‌کند؟

این فرمان به فایل‌های استاتیک مربوط است. فایل‌هایی که کاربر آپلود کرده است به سازوکار ذخیره‌سازی رسانه و سیاست انتقال همان محیط وابسته‌اند. در جابه‌جایی پروژه، پایگاه داده و فایل‌های رسانه‌ای مرتبط را با یک برنامهٔ هماهنگ منتقل و بعد از انتقال چند نمونهٔ قدیمی و جدید را باز کنید.

اگر CSS خطای ۴۰۴ بدهد، از کجا شروع کنم؟

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

چه تفاوتی میان STATIC_ROOT و STATIC_URL وجود دارد؟

STATIC_ROOT در الگوی محلی محل خروجی گردآوری است. STATIC_URL نشانی یا پیشوندی است که مرورگر برای درخواست منابع می‌بیند. رابطهٔ میان آن‌ها را سروکنندهٔ فایل یا backend عملیاتی تعیین می‌کند. نام این دو تنظیم را همراه یک فایل نمونه در مستند استقرار بنویسید.

چرا فقط چند تصویر بعد از مهاجرت شکسته‌اند؟

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

آیا رسانهٔ خصوصی باید از MEDIA_URL عمومی باز شود؟

پاسخ به سیاست دسترسی پروژه بستگی دارد. اگر فایل برای گروهی محدود است، تحویل آن باید کنترل مجوز را رعایت کند. برای بررسی، همان منبع را با حساب مجاز و بدون حساب باز کنید و انتظار هر پاسخ را از قبل ثبت کنید. عمومی بودن تصویرهای تزئینی دلیلی برای عمومی کردن فایل‌های خصوصی کاربران نیست.

جمع‌بندی

برای رفع خطای static در Django از یک درخواست واقعی شروع کنید و مسیر مرورگر تا محل فایل را قدم‌به‌قدم دنبال کنید. اجرای جمع‌آوری وقتی نتیجه می‌دهد که فایل مورد انتظار از همان نشانی عمومی و با پاسخ درست خوانده شود. برای رسانه نیز نگهداری پایدار، سیاست دسترسی و بازیابی آزموده‌شده سه نیاز جداگانه‌اند. پیش از خرید یا مهاجرت، همین سناریوها را با یک پروژهٔ نمونه روی سرویس هاست پایتون وطن هاست و امکانات تأییدشدهٔ آن بسنجید. نتیجه را به شکل URL و معیار پذیرش ثبت کنید تا در انتشار بعدی همان آزمون قابل تکرار باشد.

منابع فنی: استقرار فایل‌های استاتیک، مرجع staticfiles و چک‌لیست استقرار Django.