الملفات الثابتة (Static Files) هي تلك الملفات التي لا يمكن معالجتها أو إنشاؤها أو تعديلها عن طريق الخادم. الصور وملفات JavaScript وما إلى ذلك هي أنواع من المحتوى أو الملفات الثابتة. تحتوي الملفات الثابتة على جميع أنواع الملفات – من MPEG، وJPEG إلى PDF، وما إلى ذلك.
هناك مفهوم بسيط للعمل مع الملفات الثابتة. عندما يطلب المستخدم صفحة ويب، سينشئ الخادم صفحة HTML. بعد ذلك سيجمع الخادم كافة الملفات الثابتة المقابلة المتعلقة بتلك الصفحة. وأخيرا، يتم تقديم هذه البيانات كاملة للمستخدم. كما يمكننا أيضًا القول إن مواقع الويب الثابتة أسرع بكثير من مواقع الويب الديناميكية.
تحتاج مواقع الويب عمومًا إلى تقديم ملفات إضافية مثل الصور أو JavaScript أو CSS. في Django، نشير إلى هذه الملفات باسم الملفات الثابتة أو "Static Files". وهنا يوفر Django خاصية ووظيفة django.contrib.static لمساعدتك على إدارتها.
يشرح هذا المقال كيف يمكنك خدمة وإدارة هذه الملفات الثابتة. كما أنه يتناول الأساسيات وبعض أنماط الاستخدام الشائعة.
تكوين الملفات الثابتة (Configuring Static Files):
1. يجب عليك التأكد من تضمين ملفات django.contrib.static في INSTALLED_APPS.
2. في ملف الإعدادات، حدد STATIC_URL، على سبيل المثال:
STATIC_URL = "static/"
3. في القوالب الخاصة بك، استخدم علامة القالب الثابت لإنشاء عنوان URL للمسار النسبي المحدد باستخدام الاسم المستعار staticfiles STORAGES الذي كُوِّن.
{% load static %}
<img src="{% static 'my_app/titotech.jpg' %}" alt="My image">
4. قم بتخزين ملفاتك الثابتة في مجلد يسمى static في تطبيقك. على سبيل المثال my_app/static/my_app/titotech.jpg.
ملاحظة هامة:
بالإضافة إلى خطوات التكوين هذه، ستحتاج أيضًا إلى تقديم الملفات الثابتة فعليًا. في أثناء التطوير، إذا كنت تستخدم django.contrib.staticfiles، فسيتم ذلك تلقائيًا عن طريق runserver عند ضبط DEBUG على True. ولكن هذه الطريقة غير فعالة إلى حد كبير، وربما غير آمنة، لذلك فهي غير مناسبة للإنتاج.
من المحتمل أن يحتوي مشروعك أيضًا على أصول ثابتة غير مرتبطة بتطبيق معين. بالإضافة إلى استخدام /static داخل تطبيقاتك، يمكنك تحديد قائمة من الأدلة (STATICFILES_DIRS) في ملف الإعدادات الخاص بك حيث سيبحث Django أيضًا عن الملفات الثابتة. على سبيل المثال:
STATICFILES_DIRS = [
BASE_DIR / "static",
"/var/www/static/",
]
ويرجى الانتباه هنا إلى أنه قد نتمكن الآن من وضع ملفاتنا الثابتة مباشرةً في my_app/static/ (عوضا عن إنشاء دليل فرعي آخر لـ my_app)، ولكنها ستكون فكرة سيئة في الواقع. حيث سيستخدم Django أول ملف ثابت يجده ويتطابق اسمه، وإذا كان لديك ملف ثابت بالاسم نفسه في تطبيق مختلف، فلن يتمكن Django من التمييز بينهما. نحن بحاجة إلى أن نكون قادرين على توجيه Django إلى المكان الصحيح، وأفضل طريقة لضمان ذلك هي عن طريق تحديد namespacing بينهما. أي عن طريق وضع تلك الملفات الثابتة داخل دليل آخر مسمى باسم التطبيق نفسه.
يمكنك إنشاء أصول ثابتة لـ namespace في STATICFILES_DIRS عن طريق تحديد البادئات.
خدمة الملفات الثابتة في أثناء التطوير:
إذا كنت تستخدم django.contrib.staticfiles كما هو موضح أعلاه، فسيقوم runserver بذلك تلقائيًا عند ضبط DEBUG على True. إذا لم يكن لديك django.contrib.staticfiles في INSTALLED_APPS، فلا يزال بإمكانك تقديم الملفات الثابتة يدويًا باستخدام عرض ()django.views.static.serve. ولكن هذا غير مناسب للاستخدام في مرحلة الإنتاج.
على سبيل المثال، إذا تم تعريف STATIC_URL الخاص بك على أنه /static، فيمكنك القيام بذلك عن طريق إضافة المقتطف التالي إلى urls.py الخاص بك:
from django.conf import settings from django.conf.urls.static import static urlpatterns = [ # ... the rest of your URLconf goes here ... ] + static(settings.STATIC_URL, document_root=settings.STATIC_ROOT)
ملاحظة هامة:
تعمل هذه الوظيفة المساعدة فقط في وضع التصحيح (debug mode) وفقط إذا كانت البادئة المحددة محلية (على سبيل المثال، /static) وليست عنوان URL (على سبيل المثال، /http://static.tito4tech.com).
كما أن هذه الوظيفة المساعدة تخدم فقط المجلد STATIC_ROOT الفعلي؛ ولا يكتشف الملفات الثابتة مثل django.contrib.staticfiles.
وأخيرًا، تُقَدَّم الملفات الثابتة عبر غلاف في طبقة تطبيق WSGI. ونتيجة لذلك، لا تمر طلبات الملفات الثابتة عبر سلسلة البرامج الوسيطة العادية (middleware chain).
خدمة الملفات التي حُمِّلَت من قبل المستخدم في أثناء التطوير:
في أثناء التطوير، يمكنك تقديم ملفات الوسائط التي حُمِّلَت عن طريق المستخدم من MEDIA_ROOT باستخدام عرض ()django.views.static.serve. ولكن هذا غير مناسب للاستخدام في مرحلة الإنتاج.
على سبيل المثال، إذا عُرِّفَت MEDIA_URL الخاص بك على أنه /media، فيمكنك القيام بذلك عن طريق إضافة المثال التالي إلى ROOT_URLCONF:
from django.conf import settings from django.conf.urls.static import static urlpatterns = [ # ... the rest of your URLconf goes here ... ] + static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)
ملاحظة هامة:
تعمل هذه الوظيفة المساعدة فقط في وضع التصحيح وفقط إذا كانت البادئة المحددة محلية (مثل /media) وليست عنوان URL (مثل /http://media.tito4tech.com).
اختبارات على المشروع (Testing):
عند تشغيل الاختبارات التي تستخدم طلبات HTTP الفعلية عوضا عن عميل الاختبار المدمج (أي عند استخدام LiveServerTestCase المدمج)، يجب تقديم الأصول الثابتة على طول بقية المحتوى، حتى تقوم بيئة الاختبار بإعادة إنتاج الأصل الحقيقي كما هو الحال، ولكن LiveServerTestCase لا يحتوي إلا على وظيفة أساسية للغاية لخدمة الملفات الثابتة: فهو لا يعرف شيئًا عن ميزة المكتشفات في تطبيق staticfiles ويفترض أن المحتوى الثابت قد جُمِع بالفعل ضمن STATIC_ROOT.
ولهذا السبب، تقوم staticfiles بشحن django.contrib.staticfiles.testing.StaticLiveServerTestCase، وهي فئة فرعية من الفئة المضمنة التي لديها القدرة على خدمة الأصول جميعها بشفافية أثناء تنفيذ هذه الاختبارات بطريقة مماثلة جدًا لما حصلنا عليه في وقت التطوير باستخدام DEBUG = True، أي دون الحاجة إلى جمعها باستخدام Collectstatic أولاً.
نشر المشروع (Deployment):
يوفر django.contrib.staticfiles أمر إدارة ملائمًا لتجميع الملفات الثابتة في دليل واحد، حتى تتمكن من خدمتها بسهولة.
1. اضبط الإعداد STATIC_ROOT على الدليل الذي ترغب في عرض هذه الملفات منه، على سبيل المثال:
STATIC_ROOT = "/var/www/tito4tech.com/static/"
2. قم بتشغيل أمر إدارة Collectstatic:
python manage.py collectstatic
سيؤدي هذا إلى نسخ الملفات جميعها من مجلداتك الثابتة إلى الدليل STATIC_ROOT.
3. استخدم خادم ويب من اختيارك لخدمة الملفات.