Merci Laurent.

En attendant j'ai pu m'en sortir de manière malpropre :p

/*
if (PHP_SAPI != 'cli') {
    echo "Wrong way";
    exit(1);
}*/

Nigoki a dit :
Je comprends tout à fait la lourdeur de la compatibilité.

Après m'être renseigné, le PHP CLI n'est pas disponible dans un environnement mutualisé chez OVH étant donné la levée de certaine restriction, par exemple max_execution_time à 0 (illimité).

Du coup, pas de Jelix 1.3 :/

pourquoi ?

perso je ne me vois pas faire un coup de createapp en live sur un site que je vais produire de 0

donc AMHA le createapp n'est pas à sa place sur un site en prod créer de rien. je créerai plutot l'appli localement et la mettrai une fois (presque) prête en ligne

non ?

J'ai l'habitude de travailler directement sur un serveur distant.

Je n'aime pas non plus développer sur un environnement Windows (mon ordi perso) et c'est la misère si je dois mettre la base de données à jour du serveur après avoir commit mes modifs de scripts en SVN étant donné qu'on va travailler à 2 ou 3 sur ce projet.

Bonjour,

Ben on n'a pas les mêmes méthodes de travail, php mysql étant portables, tout autant que l'éditeur que j'utilise ; l'os m'indiffère.

Après développer directement sur un serveur de prod implique des risques et c'est pire quand on ne versionne pas à 3 dev ou qu'on code sur le serveur directement. Du coup je préfère amplement un clone ( de mes sources) en local quand mon code est pret je le push sur le depot (peu importe où il est) et ensuite sur le serveur de prod faire un pull des sources, c'est très serein.

Et non ce n'est pas la misère pour la base de données non plus, Jelix ayant tout prévu pour les mises à jour mais bon je dois me tromper puisque je code seul et ai des habitudes de dev au sein d'une team ...:)

et c'est la misère si je dois mettre la base de données à jour du serveur après avoir commit mes modifs de scripts en SVN étant donné qu'on va travailler à 2 ou 3 sur ce projet.

Et donc normalement, tu dois aussi commiter les scripts SQL ou autre qui permettent de mettre à jour la base de données et autres données. C'est un peu plus de travail (et encore, recopier les requêtes que te donne phpmyadmin, ça ne prend pas des heures), mais ça facilite beaucoup plus les choses. Surtout quand il faut mettre à jour la version de recette pour faire tester, puis la version en production. Si à chaque fois tu dois faire les modifs à la main, il y a de forte chance d'oublier des manips ou de ne pas les faire comme il faut. Et boom la prod.

Bref, travailler tous sur un même serveur, et sans procédure de mise à jour, c'est les embêtements assurés, non seulement en phase de dév, mais aussi et surtout en phase de déploiement et de mise à jour.

Foxmask +1

J'utilise le système de mise à jour de Jelix sur des "vrais" projets, et je peux dire que c'est que du bonheur[1] : on récupère les dernières sources du projet, on lance l'update de jelix, et on a une version du site opérationnelle comme chez les autres développeurs du projet. pas de question à se poser. Et comme chacun lance les mises à jour sur son poste, cela permet de vérifier que les scripts de mises à jour fonctionnent bien, et alors les mises à jour du site en recette et en prod se font les yeux fermés, en quelques secondes. Temps d'indisponiblité du site pour les utilisateurs : 0.

PS: on n'est pas obligé d'utiliser le système de mise à jour automatique de Jelix, il n'est pas forcément adapté aux processus de mise en production de l'entreprise où on travaille. En revanche, il est indispensable d'avoir processus/système de mise à jour fiable et automatique, nécessitant le moins de manipulation humaines possibles. Les mises à jour à la main, c'est à réserver pour les pages perso ;-)

Merci pour vos conseils.

En fait pour un module il faut fournir les scripts SQL de mise à jour/Création de date dans le dossier install avant de commit les modifications ?