Le debug true, c'est bien, c'est super bien ... par contre, le soucis c'est que ça salit le git history, faut le caler à debug, puis le remettre à prod. C'est pas bien grave dans l'absolu, mais n'est-ce pas possible dans un fichier hors versioning system ?

Le truc marrant, c'est que je dis ça, et évidemment dans mon fork work in progress de la lexpage, j'ai un magnifique système identique dans un fichier !

TchouLe debug true, c'est bien, c'est super bien ... par contre, le soucis c'est que ça salit le git history, faut le caler à debug, puis le remettre à prod. C'est pas bien grave dans l'absolu, mais n'est-ce pas possible dans un fichier hors versioning system ?

J'suis pas sûr de comprendre ce que tu demandes

Je comprends pas non plus. dans settings.py :

try:
  from settings_local import *
except ImportError:
   pass

settings_local.py: DEBUG = False

avec settings_local.py dans le .gitignore

__base.html est dans la liste des fichiers surveillés par git.

Donc pour tester une modif CSS, je change debug à true, donc je change le contenu d'un fichier dans le gestionnaire. Une fois ma modif faite, si j'ai le malheur d'oublier de re-basculer en mode prod, je te push une modif non souhaitée.

Il serai plus pertinent à mon sens d'avoir un fichier settings qui ne soit pas géré par git qui permette de basculer un tel flag. Comme ça pas de risque de laisser le debug à true sur le site de prod.

Edit : settings_local ? C'est settings_dev que j'ai sur mon fork et sur le dépot ... gniiii ? Mais oui, voilà, un fichier settings specifique dand le gitignore

Je ne suis pas sûr de mieux comprendre, mais en gros, la variable {{ debug }} dans les templates va automatiquement prendre la valeur du DEBUG qui se trouve dans les settings. Le fichier de settings du Lexpage est construit comme suit :
- Un settings_dev.py et un settings_prod.py (que vous n'avez pas).
- Ces deux fichiers chargent une configuration de base (settings_base.py)
- Le fichier settings.py (lu par défaut par Django en l'absence d'un autre fichier spécifiquement ciblé) charge, par défaut, settings_dev.py

Donc de base, sans paramètre, le serveur va lire settings, qui charge settings_dev, qui inclut settings_base. Vu que settings_dev définit DEBUG à True, tu es en débug.

A priori, tu n'a pas à changer la variable DEBUG. Si tu souhaites tester en "prod", oui, tu peux le faire, ou te créer un autre fichier settings_prodtchou.py avec ce qu'il faut dedans, et ensuite tu lances le serveur en ajoutant DJANGO_SETTINGS_MODULE=settings_prodtchou

Tu ne risques pas de pusher quelque chose de "mauvais" pour la prod : settings_dev n'est jamais accédé en prod, et de toute façon, je surveille toujours le contenu des pull requests (D'ailleurs, ce n'est pas nécessaire de m'envoyer les fichiers minifier, car je le ferai moi sur base de vos fichiers "non minifier". Je fais ça essentiellement pour en prendre l'habitude, et ne pas risquer d'avoir un pull request d'un inconnu qui souhaite juste injecter un vilain JS que je ne pourrai pas lire dans la version minifiée).

Ok, en fait j'aurais dû aller lire le code avant de sortir des conneries, tu as juste la logique de l'aiguillage dans le __base, pas le flag dedans comme je l'ai cru ... comme j'avais aussi eu l'info en mp, les deux disaient la même chose mais dans 2 logiques différentes, j'ai croisé les effluves, et c'est bien connu qu'il fallait pas.

Donc :

J'ai un peu de mal avec les tableaux imbriqués…

Ce code:
[ sign=[ sign=:)]Toto[ /sign]]Titi[ /sign]

Ça devrait être un "smiley avec une pancarte Toto" qui tient une pancarte Titi, non ?
Hé bien, ça donne ça:

En effet, il faut que je regarde pour changer l'ordre dans lequel les imbrications sont traitées.

[Edité : Bon, visiblement, il va falloir chipoter un peu. La regex qui s'occupe des panneaux est ci-dessous. En gros, elle est utilisée dans un substitute qui traite les éléments "non-overlappant" de gauche à droite. Je suppose qu'il faut pondre quelque chose dans le premier (.*?) pour rendre ça "un peu plus greedy mais pas trop". J'regarde à ça dès que j'ai un peu plus de temps....

r'\[sign=(.*?)\](.*?)\[/sign\]'

[Edité 2 : Cela dit, c'est pas primordial, je me demande même si idéalement, il ne faudrait pas interdire autre chose qu'un smiley après le [sign=.... ^^]

Merci !

Petit ajout discret sur Lexpage : les utilisateurs ayant posté un message sur le forum ont maintenant la possibilité de supprimer ce message si le message est vieux de maximum 5 minutes (et qu'il n'a pas été modéré).