Fichier .gitignore pour spip

Général
1

Bon Dimanche Spipeurs et Spipeuses,

Voila, J’essaie de versioner un projet spip avec GIT, quelqu’un aurait il une petite idee de fichier .gitignore pour spip 3.2 ?

Merci

2

Bonjour,

je serais également intéressé par la meilleur pratique conseillée ! Pour l’instant, j’utilise l’approche « tout ignorer, puis sélection de ce qui est à versionner » dans un .gitignore à la racine de spip :

# tout ignorer
*
# sauf .gitignore
!/.gitignore
# sauf dirs (dirs vides ne sont pas versionnés)
!*/
# puis des-ignore récursif des fichiers des dirs qu'on souhaite versionner
!/plugins/mon-plugin/**
!/squelettes/**

Mais il me semble que mon .gitignore a parfois été remplacé par celui de Spip, peut être à l’occasion des mises à jour via spip_loader.

Donc versionner depuis la racine de Spip, même si ça permet de conserver les squelettes et des plugins maisons ou retouchés dans un même dépôt, n’est peut être pas idéal.

3

Bonjour,

Je fais ça
docker/database/
docker/docker-entrypoint/.sql
plugins/auto/
.htaccess
IMG/
config/remove.txt
config/.ok
lib/*
local/*
tmp/*

4

je trouve bizarre de versionner tout le projets en fait. SPIP lui même est versionné. Les plugins sont versionnés. Tu n’aurais qu’à versionner ton squelette non ?

5

Versionner uniquement le squelettes/ exclu il me semble l’accès aux fonctionnalités de mes_options.php, non ? Il me semble que tout n’est pas accessible via squelettes/mes_fonctions.php, et/ou que c’est pas optimal au niveau performance [Edit: mes_fonctions a de meilleures performances d’après cousu-main].

Selon les projets, des fichiers utiles à versionner peuvent être entre autre : .htaccess, config/mes_options.php, squelettes/*, plugins/mon-squelette-en-plugin/*, plugins/mon-plugin-perso/*… les uns n’excluant pas les autres, et les fichiers utiles au projet n’étant pas forcément connus au moment d’initialiser le dépôt.

C’est l’intérêt que je trouve à versionner « à la racine ». Le plus proche serait peut être d’initialiser son dépot dans plugins/ et exclure plugins/auto/*, et packager son squelette en plugin, il ne manque alors que l’accès au .htaccess.

6

en general c’est mieux de packager tes squeletets en plugins :

  • tu a ton fichier plugins_options.php
  • tu peux indiquer les dépendances à des plugins

Donc avec ca tu versionne juste ton plugin-squelette. Si vraiment tu as un .htacess spécifique, tu le versionne à part…

7

Ça concerne très peu de chose. Pour ma part, je ne rencontre que très rarement des options qui nécessite d’être dans le dossier config/ (par ex define('_NO_CACHE', -1); mais ça n’a pas vocation à aller en prod).

Qq1 confirme/infirme ?

8

D’après cousu-main c’est l’inverse de ce que j’ai énnoncé : mes_options est chargé à chaque hit alors que mes_fonctions est mis en cache, donc mes_fonctions a de meilleurs performances !

9

Sacré Cousu Main :grin:

La question de la différence de perf était entre config/mes_options.php et squelettes/mes_options.php voir monplugin/monplugin_options.php :slight_smile:

10

les fichiers _options sont chargés à chaque hit, les fichiers _fonctions chargés selon le besoin.

11

haha, il a l’air bien renseigné :sweat_smile:

squelettes/mes_options.php est pris en compte ? Je pensais que ce n’était pas (encore) le cas. Bref désolé de diverger, le sujet est intéressant, merci pour vos conseils.

12

que je sache squelettes/mes_options.php ne marche pas, par contre si tu fais un squelette sous forme de plugins (ce qui est facile à faire et conseillé, cf https://geekographie.maieul.net/93), tu peux avoir prefixduplugins_options.php