Servir le Javascript, les images et le CSS avec Django a toujours été une grande question pour les débutants.
J’avais fais un giga article pour expliquer comment servir les fichiers statiques avec ce framework, mais j’ai réalisé ensuite que les gens n’avaient pas forcément accès aux fichiers de configuration du serveur.
Parfois, tout ce qu’ils ont c’est un pauvre fichier .htaccess. Tout n’est pas perdu, avec une petite règle de rewrite :
AddHandler fcgid-script .fcgi RewriteEngine On RewriteRule /static/ /chemin/vers/dossier/racine/apache/static RewriteCond %{REQUEST_FILENAME} !-f RewriteRule ^(.*)$ site.fcgi/$1 [QSA,L]
Attention à ce que /static/ corresponde bien à l’arborescence complète de sous dossiers de /chemin/vers/dossier/racine/apache/ et à settings.STATIC_ROOT
.
Par exemple :
AddHandler fcgid-script .fcgi RewriteEngine On RewriteRule /sous/dossier/static/ /chemin/vers/dossier/racine/apache/sous/dossier/static RewriteCond %{REQUEST_FILENAME} !-f RewriteRule ^(.*)$ site.fcgi/$1 [QSA,L]
Et settings.STATIC_ROOT = "/sous/dossier/static/"
.
En effet, on fait un rewrite ici, on ne sert pas le sous dossier directement.
P.S: ça va sans le dire, mais ça va mieux en le disant, c’est de la prod, donc faut faire un manage.py collectstatic
avant, et s’assurer d’avoir les bonnes valeurs pour settings.STATIC_ROOT
et settings.STATIC_URL
/
un article qui tombe bien avec l’actu nginx qui devient closed source …
Nginx qui devient closed source ? J’ai lu qu’ils sortaient nginx plus, une version closed source de nginx, pas que nginx devenait closed source. J’ai raté un truc ?
Moralité ?
Sauver un poisson rouge, ne coder pas avec Django.
Moi par exemple j’code en pure WSGI (via mod_wsgi) et j’ennuie tout ceux qui auront quelque chose à y redire :o
Moins de framework, plus de Python. \o/
Petite coquille, c’est “manage.py collectstatic” pour ceux qui auraient essayé sans le “t”.