Page 2 sur 6Précédent 1, 2, 3, 4, 5, 6 SuivantWebApps : bugs et features requests

[Roromis]

Bonjour,
J'ai essayé DokuWiki, sa à l'air de fonctionner à merveille.
Je n'ai eut aucun bug.

Une petite faute de frappe dans la page de présentation (la fenêtre qui s'ouvre au début):

Il est frotement recommandé de lire la documentation si vous voulez faire des modifications (voir le menu "Site Officiel")

Merci.

[ma-b]

Bonjour ici !
Ci dessous 4 exemples des messages d'erreurs que je vois apparaitre, ainsi que le résultat une fois plusieurs 10aines de ces messages écartés...
Pour le contexte : Windows Vista Familial Premium, et une extraction toute fraiche du DokuWikiPortable..

Donc vraisemblablement ZMWS ne localise pas correctement les bibliothèques nécessaires... mais je ne sais pas trop pour le moment ou aller retoucher les configs...

[Pseudogaetan]

Bonsoir,

Je pencherai pour un problème de pare-feu essayer de le/les désactiver.

Amicalement,
Pseudogaëtan.

[Jorm]

Salut à tous,
et pis aussi bravo et merci pour la participation au développement de ces applis !

@pyg
Juste une remarque, pourrais-tu "valider" officiellement les versions stables des webapps sur la page où il y a la liste : http://framakey.org/WebApp/Index. En surfant sur ce forum, on voit que la majorité des bugs de certaines sont corrigé mais depuis l'extérieur.. ben un peu moins.
Le truc c'est qu'il y a toujours le post-it " Ces applis sont en bêta donc toujours pas 100 % stable".

Certaines webapps n'ont plus le lien "plus d'infos" sous leur nom, peut-on en déduire qu'elle sont prêtes à l'emploi ? (dokuwiki, spip, et d'autres)

Stp, rajoute juste un truc qui rassure tout le monde sous les applis qui marchent bien du genre "Celle-là, c'est ok. Normalement y a plus de bugs. Si il en reste, contactez-nous." D'une part, ça rassure les utilisateurs et ils vont moins hésiter à en télécharger (je parle d'abord pour moi bien sûr ), d'autre part, si il reste des bugs non détéctés, vous aurez un retour des utilisateurs finaux (= testeurs a posteriori) pour les identifier.

Merci d'avance.

[JosephK]

Ben en fait elles sont encore toutes plus ou moins en beta parce qu'on pas beaucoup de retour. (en passant le services google sont presque tous en beta et bizarrement ça fait moins peur )
Alors ça peu vouloir dire que le Framakey Webapps Manager est super bien foutu, mais en réalité c'est surtout la cohabitation entre plusieurs webapps qui pourrait être instable et là on a encore moins de retour donc bon...
Après il manque des petits trucs ici ou là pour finaliser proprement les choses comme les scripts spécifiques, les traductions anglaises, des icônes trop moches à changer...
Pour une webapp, la portabilisation en soi c'est rien et c'est (très) stable. C'est le reste le plus compliqué

Sinon, le lien "plus d'info" il veut juste dire "plus d'info", en fait il faudrait qu'on fasse les pages pour celles qui manquent. (d'ailleurs, je vais de ce pas mettre les liens pour inviter à créer la page)

[fat115]

Bonjour,

Une question (qui se transformera en feature request si la réponse est négative) : Est-il possible de lancer plusieurs commandes l'une après l'autre à l'aide des scripts (spécifiques ou génériques) ?
Ça m'éviterai de devoir créer un batch auquel il faut passer des paramètres pour enchainer 3-4 commandes (mysql et renommage de fichiers), la solution du batch ne me paraissant pas très propre.

Pour plus d'infos, c'est pour réaliser via un script le point 2 de ce message : viewtopic.php?p=259358#p259358

Autres points tant que j'y pense :
- Dans SPIPPortable et PMBPortable (et à priori une grosse partie des WebpApps je pense), le script PHPInfo échoue : la valeur que retourne {$zmws_webdir} vaut False. Pour PMBPortable, j'ai contourné en remplaçant {$zmws_webdir} par http://127.0.0.1:{$zmws_port}

- Toujours dans scripts.generic.ini, les scripts d'export et de réinitialisation de la base ne sont utilisables que si la WebApp est la seule lancée, le numéro de port de mysql n'est pas précisé.
Pour résoudre ce bug, il sufftit de passer "-P {$mysql_port}" en option de la commande mysql ou mysqldump, on a alors :

Code: Tout sélectionner

[ExportDB]
Name=Export database
Name_fr=Exporter la base de données

Description=Export the Whole database
Description_fr=Sauvegarde la totalité de la base dans \Appinfo\{$CurrentDate}.sql {@CRLF}Attention: MySQL doit être actif.

Type=COMMAND
Query={@ComSpec} /c {$mysql_bin_path}\mysqldump -P {$mysql_port} --opt {$DatabaseName} -u root > {$appinfo_path}\export-{$appShortName}-{$CurrentDate}.sql
Done=Executed: {@ComSpec} /c {$mysql_bin_path}\mysqldump -P {$mysql_port} --opt {$DatabaseName} -u root > {$appinfo_path}\export-{$appShortName}-{$CurrentDate}.sql
Done_fr=Action executée : {@ComSpec} /c {$mysql_bin_path}\mysqldump --opt {$DatabaseName} -u root > {$appinfo_path}\export-{$appShortName}-{$CurrentDate}.sql {@CRLF}Rendez vous dans le dossier {$appinfo_path} pour récupérer votre sauvegarde.

[ResetDB]
Name=Reset database
Name_fr=Réinitialiser la base de données.
Description=Reset the database. USE WITH CAUTION!
Description_fr=Réimporte la base de données par défaut. Vous perdrez TOUTES vos modifications !!!
Type=COMMAND
Query={@ComSpec} /c {$mysql_bin_path}\mysql.exe -P {$mysql_port} -u root -e "source {$appinfo_path}\master.sql" {$DatabaseName}
Done_fr=Script terminé.

[pyg]

Une question (qui se transformera en feature request si la réponse est négative) : Est-il possible de lancer plusieurs commandes l'une après l'autre à l'aide des scripts (spécifiques ou génériques) ?
Ça m'éviterai de devoir créer un batch auquel il faut passer des paramètres pour enchainer 3-4 commandes (mysql et renommage de fichiers), la solution du batch ne me paraissant pas très propre.

Non, et c'est pas simple à mettre en oeuvre, malheureusement...
Le plus simple reste pour le moment de créer un batch avec plusieurs commandes, et d'executer ce dernier avec un script de commande

- Dans SPIPPortable et PMBPortable (et à priori une grosse partie des WebpApps je pense), le script PHPInfo échoue : la valeur que retourne {$zmws_webdir} vaut False. Pour PMBPortable, j'ai contourné en remplaçant {$zmws_webdir} par http://127.0.0.1:{$zmws_port}

Ha ça, ça doit être une boulette de ma part

- Toujours dans scripts.generic.ini, les scripts d'export et de réinitialisation de la base ne sont utilisables que si la WebApp est la seule lancée, le numéro de port de mysql n'est pas précisé.

Re-boulette, re-

Pour résoudre ce bug, il sufftit de passer "-P {$mysql_port}" en option de la commande mysql ou mysqldump

Merci de la correction

Bon, ben merci beaucoup pour cette petite liste de bugs, je me la note de côté, et je m'attaque aux corrections dès que possible.
Pour le coup des scripts multiples, je ne dis pas que c'est impossible, mais c'est vraiment casse-pieds à développer, donc n'attends pas après moi...

[Invité]

Ben en fait elles sont encore toutes plus ou moins en beta parce qu'on pas beaucoup de retour. (en passant le services google sont presque tous en beta et bizarrement ça fait moins peur )
Alors ça peu vouloir dire que le Framakey Webapps Manager est super bien foutu, mais en réalité c'est surtout la cohabitation entre plusieurs webapps qui pourrait être instable et là on a encore moins de retour donc bon... [...]
Pour une webapp, la portabilisation en soi c'est rien et c'est (très) stable. C'est le reste le plus compliqué

Message reçu JosephK, merci pour ces éclaircissements.
Je note que tout le business webapp est toujours en bêta pour le moment .

D'ailleurs, en parlant de retour de bugs, j'ai essayé d'ouvrir DokuWiki portable et il y a eu quelque chose de bizarre, un message disant "ouverture de MySQL" s'est affiché . Je croyais pourtant que les fichiers étant de simple *.txt, il n'y avai pas de base de données.
Deuxième souci : impossible de quitter DokuWiki par un clic droit sur l'icone dans la barre des tâches. Clic droit --> quitter DokuWiki --> affichage de la bulle "fermeture de MySQL" (re-?), affichage de la bulle "fermeture de ZMWS". Et pis ça ne se ferme pas, ces deux message continue d'apparître l'un après l'autre. Je n'ai pas trouvé comment l'arrêter.
Bon j'ai juste fait le test une fois sur le PC d'un pote et je n'ai pas réessayé, mon ordi personnel étant sou Linux/Ubuntu.

Navré de pouvoir apporter ma pierre technique à l'édifice, je ne connais absolument rien à la programmation sinon que desfois il y a des accolades (ou pas ?).

[Jorm]

Suis désolé !
j'avais oublié de me connecter avant de poster le message précédent. Donc juste pour info, le message rapportant le bug DokuWiki sur l'ouverture de MySQL et la fermeture perpétuelle de MySQL et ZMWS était bien de moi.

Jorm

[fat115]

Le démarrage de MySQL correspond au comportement par défaut des Webapps.

Pour l'éviter, il faut placer la ligne NeedMySQL=false dans la section WebAppSpecific du fichier \dokuWikiPortable\App\AppInfo\appinfo.ini apparemment.

Pour l'erreur en sortie, pas la moindre idée je n'utilise pas cette Webapp, désolé