You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Recentraliser fichiers dans l'arborescence de l'application #375
Le fait d'avoir migré la conf et les logs dans /etc/ est intéressant pour la mise à jour de l'application.
Cependant c'est moins lisible et surtout ça bloque les possibilités d'un serveur multi-instance de GeoNature.
En regardant, les applis WEB ne font pas ça (Drupal, Lizmap....). C'est plutôt une logique d'application lourde locale.
Après discussion avec Amandine, on partirait sur un répertoire var/ dans GeoNature avec un répertoire log et un répertoire config.
A voir pour les modules externes si on garde la possibilité de les avoir en dehors de GeoNature, ou si on fait un répertoire external_modules à côté de contrib.
je vote pour tout mettre dans le répertoire de l'appli.
Il faut aussi un tmp dont on pourra personnaliser l'effacement selon le besoin et non brutalement à chaque reboot du serveur (ou du poste de travail du developpeur)
Pas mal de changement dans arborescence de l'application:
Suppresion du répertoire /etc/geonature
Les fichiers de configuration sont regroupés dans le dossier config de GeoNature et de chacun des modules.
Pour le coeur : config/geonature_config.toml
Pour les modules, dans le répertoire du module: config/conf_gn_module.toml
Création d'un dossier var/log qui contient les logs d'installation (db + serveur)
Création d'un dossier tmp à l’intérieur du projet pour stocker les scripts d'installation provisoires.
Création d'un dossier external_modules ou on retrouve tous les gn_modules installés (activé ou non). Chaque gn_module est en fait un lien symbolique vers là ou se trouve le module sur la machine.
La table gn_commons.t_modules contient deux champs qui contrôlent l'activation du module, respectivement pour le frontend et le backend: active_frontend et active_backend. Cela permet d'activer le backend d'un module qui à un frontend exterieur à GeoNature (et inversement).
Regroupement de tous les scripts d'installation dans un dossier install à la racine du projet
Pour migrer de l'ancienne structure à la nouvelle, executer le script install/migration/beta4tobeta5.sh
Activity
gildeluermoz commentedon May 15, 2018
je vote pour tout mettre dans le répertoire de l'appli.
Il faut aussi un
tmpdont on pourra personnaliser l'effacement selon le besoin et non brutalement à chaque reboot du serveur (ou du poste de travail du developpeur)TheoLechemia commentedon Jun 14, 2018
Pas mal de changement dans arborescence de l'application:
Suppresion du répertoire
/etc/geonatureLes fichiers de configuration sont regroupés dans le dossier
configde GeoNature et de chacun des modules.Pour le coeur :
config/geonature_config.tomlPour les modules, dans le répertoire du module:
config/conf_gn_module.tomlCréation d'un dossier
var/logqui contient les logs d'installation (db + serveur)Création d'un dossier
tmpà l’intérieur du projet pour stocker les scripts d'installation provisoires.Création d'un dossier
external_modulesou on retrouve tous les gn_modules installés (activé ou non). Chaque gn_module est en fait un lien symbolique vers là ou se trouve le module sur la machine.La table
gn_commons.t_modulescontient deux champs qui contrôlent l'activation du module, respectivement pour le frontend et le backend:active_frontendetactive_backend. Cela permet d'activer le backend d'un module qui à un frontend exterieur à GeoNature (et inversement).Regroupement de tous les scripts d'installation dans un dossier
installà la racine du projetPour migrer de l'ancienne structure à la nouvelle, executer le script
install/migration/beta4tobeta5.shGrosses modif de l'arborescence de l'application #375
camillemonchicourt commentedon Jun 14, 2018
Banzai !