• en
  • Langue : fr

L’application de gestion des fichiers statiques (staticfiles)

django.contrib.staticfiles recueille les fichiers statiques à partir de chacune des applications (et de tous les autres endroits que vous spécifiez) en un seul endroit qui peut facilement être utilisé en production.

Voir aussi

Pour une introduction à l’application et quelques exemples d’utilisation des fichiers statiques, voir Gestion des fichiers statiques (par ex. images, JavaScript, CSS). Pour obtenir des instructions sur le déploiement des fichiers statiques, voir Déploiement des fichiers statiques.

Réglages

Voir réglages de staticfiles pour plus de détails sur les réglages suivants :

Commandes d’administration

django.contrib.staticfiles propose trois commandes d’administration.

collectstatic

django-admin collectstatic

Recueille les fichiers statiques dans le répertoire STATIC_ROOT.

Lorsque deux fichiers ont le même nom, le problème est résolu par défaut d’une façon similaire à la façon dont fonctionne la résolution des gabarits : le premier fichier trouvé est utilisé. En cas d’incertitude, la commande findstatic peut vous montrer quels sont les fichiers trouvés.

Lors des prochains lancements de collectstatic (si STATIC_ROOT n’est pas vide), les fichiers ne sont copiés que si leur date de modification est plus récente que la date de modification du fichier dans STATIC_ROOT. Ainsi, si vous supprimez une application de INSTALLED_APPS, il est recommandé d’utiliser l’option --clear afin de supprimer les fichiers statiques obsolètes.

La recherche des fichiers utilise le réglage STATICFILES_FINDERS. Par défaut, Django parcourt tous les emplacements définis dans STATICFILES_DIRS et dans le répertoire 'static' des applications figurant dans le réglage INSTALLED_APPS .

La commande d’administration collectstatic appelle la méthode post_process() du système de stockage STATICFILES_STORAGE après chacune de ses exécutions et lui passe une liste des chemins qu’elle a trouvés. La méthode reçoit également toutes les options de ligne de commande de collectstatic. C’est utilisé par la classe CachedStaticFilesStorage par défaut.

Par défaut, les fichiers collectés reçoivent les autorisations du réglage FILE_UPLOAD_PERMISSIONS et les répertoires reçoivent les autorisations de FILE_UPLOAD_DIRECTORY_PERMISSIONS. Si vous souhaitez des autorisations différentes pour ces fichiers ou répertoires, vous pouvez créer une sous-classe des classes de stockage des fichiers statiques et spécifier les paramètres file_permissions_mode ou directory_permissions_mode. Par exemple :

from django.contrib.staticfiles import storage

class MyStaticFilesStorage(storage.StaticFilesStorage):
    def __init__(self, *args, **kwargs):
        kwargs['file_permissions_mode'] = 0o640
        kwargs['directory_permissions_mode'] = 0o760
        super(MyStaticFilesStorage, self).__init__(*args, **kwargs)

Définissez ensuite le réglage STATICFILES_STORAGE à 'chemin.vers.MyStaticFilesStorage'.

New in Django 1.7:

La possibilité de surcharger file_permissions_mode et directory_permissions_mode est nouvelle dans Django 1.7. Auparavant, les permissions de fichiers et de répertoires utilisaient toujours les réglages FILE_UPLOAD_PERMISSIONS et FILE_UPLOAD_DIRECTORY_PERMISSIONS.

Certaines options couramment utilisées sont :

--noinput

Ne pose AUCUNE question à l’utilisateur.

-i <pattern>
--ignore <pattern>

Ignore les fichiers ou les répertoires correspondant à ce motif de style « glob ». Peut être utilisé plusieurs fois pour ignorer plusieurs chemins.

-n
--dry-run

Exécute la commande normalement, mais sans toucher réellement au système de fichiers.

-c
--clear

Efface les fichiers existants avant d’essayer de copier ou de lier le fichier d’origine.

-l
--link

Crée un lien symbolique vers chaque fichier au lieu de copier.

--no-post-process

N’appelle pas la méthode post_process() du moteur de stockage configuré dans STATICFILES_STORAGE.

--no-default-ignore

N’ignore pas les motifs de style « glob » `` ‘CVS’, ``'.*' et '*~' qui sont normalement toujours ignorés.

Pour une liste complète des options, reportez-vous à l’aide des commandes elles-mêmes en exécutant :

$ python manage.py collectstatic --help

findstatic

django-admin findstatic

Recherche un ou plusieurs chemins relatifs en fonction des chercheurs activés.

Par exemple :

$ python manage.py findstatic css/base.css admin/js/core.js
Found 'css/base.css' here:
  /home/special.polls.com/core/static/css/base.css
  /home/polls.com/core/static/css/base.css
Found 'admin/js/core.js' here:
  /home/polls.com/src/django/contrib/admin/media/js/core.js

Par défaut, tous les emplacements trouvés sont utilisés. Pour ne renvoyer que le premier chemin relatif trouvé, utilisez l’option --first:

$ python manage.py findstatic css/base.css --first
Found 'css/base.css' here:
  /home/special.polls.com/core/static/css/base.css

Il s’agit d’une outil de débogage ; vous verrez exactement quel fichier statique sera trouvé pour un chemin donné.

En mettant le drapeau --verbosity à 0, vous pouvez supprimer les explications complémentaires et obtenir uniquement les noms de chemins :

$ python manage.py findstatic css/base.css --verbosity 0
/home/special.polls.com/core/static/css/base.css
/home/polls.com/core/static/css/base.css

D’autre part, en mettant l’option --verbosity à 2, vous pouvez obtenir la liste de tous les répertoires qui ont été recherchés :

$ python manage.py findstatic css/base.css --verbosity 2
Found 'css/base.css' here:
  /home/special.polls.com/core/static/css/base.css
  /home/polls.com/core/static/css/base.css
Looking in the following locations:
  /home/special.polls.com/core/static
  /home/polls.com/core/static
  /some/other/path/static
New in Django 1.7:

La possibilité de lister les répertoires qui ont été recherchés a été ajoutée.

runserver

django-admin runserver

Remplace la commande de base runserver si l’application staticfiles est installée, et ajoute automatiquement le service des fichiers statiques ainsi que les nouvelles options ci-dessous.

--nostatic

Utilisez l’option --nostatic pour désactiver entièrement le service des fichiers statiques avec l’application staticfiles. Cette option n’est disponible que si l’application staticfiles fait partie du réglage INSTALLED_APPS de votre projet.

Exemple d’utilisation :

django-admin runserver --nostatic
--insecure

Utilisez l’option --insecure pour forcer le service des fichiers statiques avec l’application staticfiles même quand le réglage DEBUG est à False. En utilisant cette option, vous reconnaissez le fait que c’est totalement inefficace et très probablement non sécurisé. Cette option est uniquement destinée au développement en local et ne devrait jamais être utilisée en production. Elle n’est disponible que si l’application staticfiles se trouve dans le réglage INSTALLED_APPS de votre projet. runserver --insecure ne fonctionne pas avec la classe CachedStaticFilesStorage.

Exemple d’utilisation :

django-admin runserver --insecure

Stockages

StaticFilesStorage

class storage.StaticFilesStorage

Une sous-classe du moteur de stockage FileSystemStorage qui utilise le réglage STATIC_ROOT comme emplacement de base dans le système de fichiers et le réglage STATIC_URL comme URL de base.

storage.StaticFilesStorage.post_process(paths, **options)

Cette méthode est appelée par la commande d’administration collectstatic après chacune de ses exécutions. Elle reçoit les stockages et chemins locaux des fichiers trouvés sous la forme d’un dictionnaire, ainsi que les options de ligne de commande.

Le stockage CachedStaticFilesStorage utilise cette classe en coulisses pour remplacer les chemins par leur équivalent « haché » et mettre à jour le cache de manière appropriée.

ManifestStaticFilesStorage

New in Django 1.7.
class storage.ManifestStaticFilesStorage

Une sous-classe du moteur de stockage StaticFilesStorage qui modifie les noms des fichiers qu’elle traite en ajoutant le hâchage MD5 du contenu du fichier au nom de fichier. Par exemple, le fichier css/styles.css serait également enregistré en tant que css/styles.55e7cbb9ba48.css.

Le but de ce stockage est de continuer à servir les anciens fichiers au cas où certaines pages se réfèrent encore à ces fichiers, par exemple parce qu’elles sont mises en cache par vous-même ou un serveur mandataire externe. En outre, cela est très utile si vous souhaitez appliquer des en-têtes à date d’expiration très lointaine aux fichiers déployés pour accélérer le temps de chargement des pages lors des visites ultérieures.

Le moteur de stockage remplace automatiquement dans les fichiers enregistrés les chemins qui correspondent aux autres fichiers enregistrés par les chemins des copies en cache (en utilisant la méthode post_process()). Les expressions régulières utilisées pour rechercher ces chemins (django.contrib.staticfiles.storage.HashedFilesMixin.patterns) couvrent par défaut la règle @import et l’instruction url() des feuilles de style CSS. Par exemple, le fichier 'css/styles.css' avec le contenu

@import url("../admin/css/base.css");

serait remplacé par l’appel de la méthode url() du moteur de stockage ManifestStaticFilesStorage, enregistrant finalement un fichier 'css/styles.55e7cbb9ba48.css' avec le contenu suivant :

@import url("../admin/css/base.27e20196a850.css");

Pour activer le stockage ManifestStaticFilesStorage, vous devez vous assurer que les conditions suivantes sont remplies :

  • le réglage STATICFILES_STORAGE contient 'django.contrib.staticfiles.storage.ManifestStaticFilesStorage'

  • le réglage DEBUG contient False

  • vous utilisez la balise de gabarit staticfiles static pour faire référence aux fichiers statiques dans vos gabarits

  • vous avez recueilli tous les fichiers statiques en utilisant la commande d’administration collectstatic

Comme la création du hachage MD5 peut diminuer la performance de votre site Web, staticfiles stocke automatiquement la correspondance des noms hachés pour chaque fichier traité dans un fichier nommé staticfiles.json. Cela se produit une seule fois au moment où vous exécutez la commande collectstatic.

Comme il faut que la commande collectstatic ait été lancée, ce stockage ne doit normalement pas être utilisé lors de l’exécution des tests car collectstatic n’est pas exécutée dans une configuration de test normale. Lors des tests, vérifiez que le réglage STATICFILES_STORAGE est défini sur autre chose, comme par exemple la valeur par défaut 'django.contrib.staticfiles.storage.StaticFilesStorage'.

storage.ManifestStaticFilesStorage.file_hash(name, content=None)

La méthode utilisée lors de la création du nom haché d’un fichier. Doit renvoyer une empreinte de hachage pour le nom de fichier donné et son contenu. Par défaut, on calcule un hachage MD5 à partir du contenu comme mentionné ci-dessus. N’hésitez pas à redéfinir cette méthode pour utiliser votre propre algorithme de hachage.

CachedStaticFilesStorage

class storage.CachedStaticFilesStorage

CachedStaticFilesStorage est une classe semblable à la classe ManifestStaticFilesStorage mais utilise l’infrastructure de cache de Django pour stocker les noms hachés des fichiers traités au lieu d’un fichier manifeste statique nommé staticfiles.json. C’est surtout utile dans les situations dans lesquelles vous n’avez pas accès au système de fichiers.

Si vous souhaitez remplacer certaines options du moteur de cache utilisé pour le stockage, il vous suffit de spécifier une entrée particulière dans le réglage CACHES en la nommant 'staticfiles'. Par défaut, c’est le moteur de cache 'default' qui est utilisé.

Balises de gabarit

static

Utilise la configuration de stockage STATICFILES_STORAGE pour créer l’URL complète à partir du chemin relatif, par exemple :

{% load static from staticfiles %}
<img src="{% static "images/hi.jpg" %}" alt="Hi!" />

L’exemple précédent équivaut à l’appel de la méthode url d’une instance de STATICFILES_STORAGE avec "images/hi.jpg". Ceci est particulièrement utile lorsque vous utilisez un moteur de stockage non local pour déployer des fichiers comme indiqué dans Fichiers statiques sur un service cloud ou un CDN.

Si vous souhaitez récupérer une URL statique sans l’afficher, vous pouvez effectuer un appel un peu différent :

{% load static from staticfiles %}
{% static "images/hi.jpg" as myphoto %}
<img src="{{ myphoto }}" alt="Hi!" />

Utilisation de gabarits Jinja2

Voir django.template.backends.jinja2.Jinja2 pour des informations sur l’utilisation de la balise static avec Jinja2.

Le module finders

Le module finders (découverte des fichiers statiques) de staticfiles possède un attribut searched_locations qui est une liste de chemins de répertoires dans lesquels des fichiers statiques ont été recherchés. Exemple d’utilisation :

from django.contrib.staticfiles import finders

result = finders.find('css/base.css')
searched_locations = finders.searched_locations
New in Django 1.7.

L’attribut searched_locations a été ajouté.

Autres utilitaires

Il existe quelques autres utilitaires en plus de l’application staticfiles pour gérer les fichiers statiques :

Vue pour l’utilisation des fichiers statiques en développement

Les outils concernant les fichiers statiques sont principalement conçus pour aider à déployer correctement les fichiers statiques en production. Cela implique généralement de dédier un serveur distinct pour les fichiers statiques, ce qui induit de trop nombreuses actions supplémentaires lorsque l’on développe en local sur un environnement de développement. Ainsi, l’application staticfiles est fournie avec une vue à la va-vite que vous pouvez utiliser pour s’occuper du service des fichiers lors du développement local.

views.serve(request, path)

Cette fonction de vue sert les fichiers statiques lors du développement.

Avertissement

Cette vue ne fonctionne que si le réglage DEBUG vaut True.

C’est parce que cette vue est totalement inefficace et probablement non sécurisée. Elle n’est destinée qu’au développement en local et ne devrait jamais être utilisée en production.

Changed in Django 1.7:

Cette vue génère dorénavant une exception Http404 au lieu d’une exception ImproperlyConfigured lorsque DEBUG contient False.

Note

Pour deviner les types de contenu des fichiers servis, cette vue exploite le module mimetypes de la bibliothèque Python standard, qui se base elle-même sur la correspondance des types de fichiers de la plate-forme sous-jacente. Si vous trouvez que cette vue ne renvoie pas les bons types de contenu pour certains fichiers, il est plus que probable que la correspondance des types de fichiers de la plate-forme doit être mise à jour. Ceci peut par exemple être réalisé par l’installation ou la mise à jour du paquet mailcap sur une distribution Red Hat, ou du paquet mime-support sur une distribution Debian.

Cette vue est automatiquement activée par runserver (avec le réglage DEBUG à True). Pour utiliser la vue avec un autre serveur de développement local, ajoutez le code suivant à la fin de la configuration d’URL principale :

from django.conf import settings
from django.contrib.staticfiles import views

if settings.DEBUG:
    urlpatterns += [
        url(r'^static/(?P<path>.*)$', views.serve),
    ]

Remarque : le début du motif (r'^static/') devrait correspondre au réglage STATIC_URL.

Comme c’est un peu fastidieux, il existe aussi une fonction utilitaire qui fait cela pour vous :

urls.staticfiles_urlpatterns()

Cela renvoie le motif d’URL approprié pour servir les fichiers statiques et peut être ajouté à la liste de motifs d’URL déjà définie. Utilisez-la comme ceci :

from django.contrib.staticfiles.urls import staticfiles_urlpatterns

# ... the rest of your URLconf here ...

urlpatterns += staticfiles_urlpatterns()

Cette fonction examine le réglage STATIC_URL et connecte la vue de service des fichiers statiques en conséquence. N’oubliez pas de définir le réglage STATICFILES_DIRS approprié pour faire savoir à django.contrib.staticfiles où rechercher les fichiers en plus des fichiers dans les répertoires des applications.

Avertissement

Cette fonction utilitaire ne fonctionne que si DEBUG vaut True et que le réglage STATIC_URL n’est ni vide ni une URL complète comme http://static.example.com/.

C’est parce que cette vue est totalement inefficace et probablement non sécurisée. Elle n’est destinée qu’au développement en local et ne devrait jamais être utilisée en production.

Cas de test particulier pour permettre le « test en live »

class testing.StaticLiveServerTestCase

Cette sous-classe de test unitaire TestCase hérite de django.test.LiveServerTestCase.

Tout comme sa classe parente, vous pouvez l’utiliser pour écrire des tests qui impliquent le fonctionnement du code testé et de son exploitation par des outils de test à travers HTTP (par ex. Selenium, PhantomJS, etc.), et pour lesquels il est nécessaire que les fichiers statiques soient également disponibles.

Mais étant donné qu’elle fait appel à la vue django.contrib.staticfiles.views.serve() présentée plus haut, elle peut servir de manière transparente au moment de l’exécution des tests les ressources statiques mises à disposition par le moteur de découverte de staticfiles. Cela signifie que vous n’avez pas besoin de lancer collectstatic préalablement ou dans le cadre de la configuration des tests.

New in Django 1.7:

StaticLiveServerTestCase est nouveau dans Django 1.7. Précédemment, cette fonctionnalité était fournie par django.test.LiveServerTestCase.

L’infrastructure des « sites »
L’infrastructure de syndication par flux
Back to Top