Bonjour, je suis actuellement en version 14 et souhaite passer vers la 16.
J’ai enregistrer votre script mais voilà je n’ai pas de htdocs ni dans dolibarr ni dans dolibarrdata.
Il y a quelques années aucun soucis pour faire les mise à jour moi même et là malgré ma lecture sur le forum je n’y arrive pas
La dernière maj à été faite par softaculous et je me demande si ce dernier ne dégage pas certains dossier.
Puis je ajouter moi même htdocs?
Bon j’ai ajouté htdocs, votre script se lance correctement, tout est vert a la fin il indique avoir télecharger… mais je suis toujours en 14 et dans Maj de dolibarr aucune possibilité de maj
Bonjour The_Lobsters,
petit conseil pour la mise à jour : pour utiliser CPanel chez o2switch actuellement, NE JAMAIS FAIRE de mise à jour via CPanel !
Après la première installation de Dolibarr, CPanel supprime le répertoire « install » qui est nécessaire pour mettre en place un plan comptable par exemple.
Ensuite j’ai déjà essayé un update via CPanel et ça m’a tout cassé (ça date un peu, c’était en v12, je n’ai plus les problèmes rencontrés).
Pour le répertoire htdocs, je n’en ai pas sur mon installation et le script fonctionne très bien.
Le script doit juste être à la racine de ton répertoire Dolibarr, c’est tout.
Dans mon cas c’est : https://monsiteweb/dolibarr/doli_install.php
J’ai pu mettre à jour plusieurs fois et je suis actuellement en v15.0.3.
Et je n’oublie pas de protéger en recréant le fichier install.lock dans le rep de data de dolibarr 
Bon l’installation en 15.0 est en cours je ferais ensuite la 16…
Grosse erreur de ma part, le script fonctionne à merveille, il devrait être de base à Dolibarr.
au moment de choisir la version à installer bin je ne choisissais Developp, voila.
Sinon mutmut pour ma part j’ai MAJ pendant des années avec Cpanel via softaculous sans soucis, mais je dois de nouveau le faire manuellement car Planet Hoster ne fournit plus softaculous apparemment.
Cordialement
bonjour,
httpdocs ? car htdocs existe aussi
Je l’ai placé dans httpdocs, mais planté 
@ksar ce script est absolument parfait …
a) bravo
b) merci
Je vais le faire tourner sur le refrain d’un pote d’il y a quelques années qui disait un truc du genre « c’est bon, mangez-en »
@erics merci 
Il y a surement des améliorations à faire, j’ai par exemple, jamais automatisé la recherche de la derniére version stable, mais ce script me fait gagner pas mal de temps.
Aprés, je me suis aussi demandé si cela ne vaudrait pas le coup de le transformer en module, a voir si j’ai le temps et la motivation un jours.
1 « J'aime »
Carrément, veux tu que je creuse un peu l’idée du module ?
Je pense qu’il faudrait que le script d’install reste autonome.
Si tu as le temps oui bien sur !
Après, je ne l’ai pas fait aussi parce qu’il existe déjà ce genre de modules sur le Dolistore: exemple : Mise À Jour
@libremaster en fait j’ai toujours trouvé étrange qu’un tel mécanisme ne soit pas nativement présent dans le coeur de dolibarr … en regardant tous les autres projets dans lesquels j’ai un peu passé de temps j’ai noté que c’était un peu « le sens de l’histoire » (wordpress, gravcms, dokuwiki, nextcloud etc. proposent tous d’une manière ou d’une autre un mécanisme de « self upgrade »).
dokuwiki par exemple a un module complémentaire de mise à jour. Lorsqu’une upgrade est dispo un message est affiché à l’administrateur, je clique sur « upgrade » et le module de mise à jour me dit à chaque fois « attention, mettez à jour le module de mise à jour avant d’essayer de mettre à jour le coeur », c’est astucieux, en procédant ainsi le développeur se garde la possibilité de faire un correctif spécifique du process de mise à jour …
@ksar pour en revenir à ton code ce qui me semblerait le plus « urgent » serait d’implémenter le « nettoyage » je veut dire par la que - après lecture rapide - il semblerait que ton script fasse un unzip de la version demandée. C’est top, ça écrase tous les anciens fichiers mais par contre j’ai l’impression qu’il ne supprime pas les fichiers qui étaient présents dans la version précédente.
Le pb c’est que ça peut laisser des vieux fichiers potentiellement vulnérables sur certains aspect « sécu ».
J’aurais bien imaginé un truc du genre lecture du fichier xml de la version existante pour collecter tous les noms de fichiers qui étaient livrés par cette version(v16 par exemple), ensuite unzip de la v17, diff de la liste des fichiers par rapport à la nouvelle version et delete des fichiers « qui n’ont pas été livrés » dans le zip d’upgrade. C’est par exemple ce que fait dokuwiki.
Ça ne touchera pas aux fichiers manuellement ajoutés par l’utilisateur mais au moins ça supprimera les fichiers de l’ancienne version de dolibarr.
Quand à la collision avec le module sur le dolistore je ne l’avais pas vu … c’est effectivement une situation délicate :-/
Hello,
Comment un tel script ou module gère-t-il les check de version php ?
Je viens de faire lexperience (en staging) dune mise à jour dune vieille base (v10) vers la develop. Ca a plante entre parce que je suis parti dune install en php 8, mais j’imagine que j’aurai pu avoir le problème inverse en étant sur un php 5.4…
Est ce que ce serait envisageable de prevoir un arret avant de tenter la mise à jour si la version ne correspond pas à la fourchette visée ?
Bonne soirée
1 « J'aime »
L’idée d’un script léger et indépendant avant la première installation est d’éviter de devoir envoyer un gros fichier pour ceux qui n’ont pas une connexion internet rapide.
Ensuite, le processus de mise à jour (et pourquoi pas réparation/contrôle de l’installation) peut être intégré dans Dolibarr mais devrait pouvoir fonctionner seul sans aucune dépendance à des librairies Dolibarr pour le cas où quelque chose marche mal.
@libremaster 100% d’accord, c’est une évidence ! la proposition de mettre en module le script de @ksar n’était pas du tout exclusif dans ma tête mais complémentaire :
- le script d’install d’un côté
- le module de l’autre (avec proposition pour intégration dans le coeur) pour les upgrades
mais bon vu qu’il existe déjà un module sur le dolistore pour ça …
Tous ces systèmes ont un défault majeur, il n’est pas possible d’annuler une mise à jour de manière simple.
Il existe le gestionnaire de paquets nix qui permet de revenir aux états antérieurs, et de configurer son installation de manière déclarative.
Bonjour,
Passage du script en V1.1.0, avec la possibilité de télécharger les différentes branches du GitHub de Dolibarr.
1 « J'aime »
Bonjour,
Merci pour le boulot !
Petites questions
-
Pendant la mise à jour, ne serait-il pas plus secure d’ajouter un fichier « upgrade.unlock », à partir de la v18, plutôt que de supprimer le « install.lock » ?
-
Pensez-vous le proposez en tant que PR sur le core ?
Bonne journée
Bonjour,
Effectivement, évolution à prévoir.
L’intégration dans le core n’est pas possible. En résumé : @eldy défend le fait qu’une mise à jour d’un CRM c’est quelque chose de sensible qui doit être fait uniquement par des gens qui ont les compétences pour le faire, et que donc ça ne doit pas être accessible en click-click-click.
Je comprends tout à fait ce point de vue, mais, comme pour chaque limitation mis en place, l’utilisateur « avancé » va chercher/trouver des moyens de contourner, et c’est là où mon script aide.
Quelques posts plus haut, on s’est posé la question de la mise en module de ce script.
Mais comme ça existe déjà : Mise À Jour
Je n’ai pas pris le temps de le faire.
@eris :
C’est normalement fait par le script d’installation de Dolibarr : migrate_delete_old_files() : dolibarr: dolibarr_18.0/htdocs/install/upgrade2.php Source File
C’est déjà la cas en v18: pour une mise à jour, il faut placer le fichier « upgrade.unlock » plutôt qu’effacer le « install.lock »
Supprimer le fichier install.lock fonctionnera aussi, mais cela rend aussi accessible temporairement l’usage des fonctions admin (install, création de compte, repair) alors qu’on a besoin que de l’accès aux fonction upgrade. Donc l’usage du upgrade.unlock est plus recommandé pour une mise à jour.
2 « J'aime »
