Dominique a écrit : ↑08 nov. 2019, 13:51
Je voulais juste profiter de la phase de tests.
Par contre, le code n'est pas tout a fait prêt. Peut être une semaine ou 2. Tant pis, je ferai pas à pas après, ça ne devrait pas être si dramatique.
Est-ce que créer une nouvelle base test_ol copiée depuis "test" pourrait plus facilement te permettre de tout casser sereinement sur dom.refuges.info ?
Ou sinon, pas de problème pour laisser plus longtemps le serveur virtuel cloné si tu veux : il est disponible sur l'IP 212.83.143.141 (tous les identifiants sont identiques, c'est juste que aucune url ne pointe dessus, donc dom.refuges.info ne pointe pas dessus, mais ça peut se faire sur une nouvelle url ou en utilisant la manip du fichier hosts :
https://www.wistee.fr/configuration-nom ... hosts.html )
Dominique a écrit : ↑08 nov. 2019, 13:51
Une question juste pour le plaisir de la poser : tu ne voudrais pas profiter repasser en MySql par hasard ?
ça me titille...
un hébergement mutualisé en php/postgresql c'est plutôt assez rare, donc pénible de faire tourner le code de wri ailleurs. Comme on a un serveur spécial pour wri, c'est moins un problème, mais quand même, en terme de maintenance ça sort de mes procédures habituelles, je suis plus habitué à MySQL (ou Mariadb) que postgresql.
Bref, j'y pense...
Mais ça fait un peu avancer et reculer cette histoire. J'ai quelques procédures WRI (pour recharger les départements, les réserves natuelles) qui sont conçues pour postgresql, je ne m'en sers pas souvent mais j'ignore si je vais pouvoir les convertir facilement en MySQL-GIS
Sans compter qu'il faut évidement valider que nos requêtes GIS par PDO actuelles sont compatibles.
Potentiellement un peu de galères quoi...
je n'utilise quasiment pas
j'utilise lui :
https://sly.refuges.info/adminersly/adminer.php
Plus général, mais plus pratique pour faire des requêtes je trouve.
Dominique a écrit : ↑08 nov. 2019, 13:51
Pour phpbb, il semble indispensable de le faire en même temps. ça fait trop longtemps que je tergiverse.
Le message d'erreur sur 7.0 est bizarre : phpbb 3.2.* devrait marcher de PHP 5.5 à 7.2. J'ai plusieurs sites en prod et en tests avec plein de variantes PHP / PHPBB et je n'ai jamais eu de pb.
C'est un message de NOTICE, donc sans conséquence autre que de s'afficher si on force son affichage, sinon, ça tourne (en apparence) sans problème si on n'active pas les NOTICE, ce qu'aucun hébergeur ne devrait faire par défaut.
Dominique a écrit : ↑08 nov. 2019, 13:51
Par contre, il faut en même temps mettre les nouveaux fichiers et passer une moulinette sur la base. Raison pour laquelle je recule ce moment d’ailleurs.
Faudra voir comment on procède
- pour les tests
- pour le basculement
Je suis en train de faire quelques tests d'upgrade avec la base de test et ça plante complètement. J'investigue et je reviens avec qque chose qui marche.
On peut passer tout le serveur, donc
www.refuges.info autant que dom/sly/.../.refuges.info sur php7.0+postgres 9.6+debian 9 ce week end, d'après les tests que j'ai fais, rien ne semble être cassé. (bien que je n'ai pas de tests unitaires)
De là, tu aura peut-être moins de problème sur une version plus récente de phpBB avec php 7.0 et on aura avancé d'un cran en débugant par étapes.
De là, on pourra ensuite mettre par exemple MySQL pour faire des tests en parallèle ou envisager d'avancer vers une debian 10 avec postgresql 11 et php 7.2
Ou alors on peut rester encore un peu avec le clone que j'ai créé et tester dessus le phpBB récent, mais à terme, ce clone sera détruit (pas les données à jour) donc il faudra refaire sur le serveur de prod, mais en nottant ou en créant une branch sur git, ça peut faire aussi.
Bref, que des solutions, ton avis ?