- D'un côté c'est super pratique de faire cohabiter plusieurs webapps ensemble, de l'autre c'est quand même assez lourd de se trimbaler zwms, mysql, php, etc en autant d'exemplaire que de webapps.
- L'idée de jongler avec les ports pour rendre chaque webapp autonome ça marche bien mais ça n'aide pas à ce que d'autres contribuent à maintenir ou ajouter des webapps portable parce qu'il faut avoir un peu compris la logique qu'il y a derrière (notamment l'intérêt du startup.ini : c'est en anglais et fastidieux à tester). Alors que des développeurs qui savent installer des CMS sur un serveur ayant une configuration assez basique il y en a plein.
- Ensuite, je trouve ça tout à fait pertinent de regrouper les fichiers web et la base de donnée dans un même dossier mais en l'état il y a un pb de sécurité (dont on avait déjà parlé) du fait que la bdd est dans le dossier de la webapp au lieu d'être à côté.
- Enfin, ZazouMiniWebServer n'étant officiellement plus maintenu, ça pose un problème de pérennité du WebappsManager (cela dit peut-être que dans 10 ans plus personne n'utilisera de logiciels portables ou de pc sous windows ).
Du coup, je verrais plutôt les choses comme ça :
- Un WM (WebappsManager) unique contenant Nginx en remplacement de ZMWS (par nature, la version windows est portable et à mon avis c'est un choix durable), MySQL, PHP, Adminer et/ou PhpMyAdmin pour ceux qui en on l'habitude.
Il existe des projets similaires qui vont dans ce sens : WT-NMP, NMP, Winginx, Whimp ou encore celui là.
En pratique ça signifie que le WM est inclus dans le core de la Framakey. Concernant PhpMyAdmin, en terme de poids on fait tellement d'économie à côté que ce n'est plus si gênant que ça de l'ajouter mais à la limite on peut très bien le proposer comme un supplément installable via synapps.
- Concernant la structure on garde à peu près la même, exemple avec Wordpress :
WordpressPortable/
~~~~~~~~~~~~~~~>App/
~~~~~~~~~~~~~~~~~~~>AppInfo (contenu habituel mais plus besoin de startup.ini)
~~~~~~~~~~~~~~~~~~~>www/
~~~~~~~~~~~~~~~~~~~>logs/
~~~~~~~~~~~~~~~>Data/
~~~~~~~~~~~~~~~~~~~>mysql/ (et uniquement ce dossier)
~~~~~~~~~~~~~~~~~~~>master.sql (et fichiers d'export)
~~~~~~~~~~~~~~~>Other/ (comme actuellement sans FWM)
~~~~~~~~~~~~~~~~~~~~>Tools/
~~~~~~~~~~~~~~~~~~~~>CreationLanceur.exe
~~~~~~~~~~~~~~~>WordpressPortable.exe
- Que fait le lanceur ?
- Vérifie qu'il y a bien un dossier ../../Framakey/WebAppManager (ou ../Framakey/WebAppManager si Wordpress n'est pas installé dans le dossier "Apps", ie utilisation hors contexte de la framakey). Sinon, il télécharge le WM et le dézippe. Ce point là ne se produirait que si on a téléchargé la webapps en standalone sur framakey.org. Donc si jamais le dézippage est une fonctionnalité trop compliquée à coder en ahk, on peut aussi utiliser un .exe auto extractible. Il y aurait donc le WM inclus dans le core et une version .exe.
- Crée un lien symbolique dans le dossier mysql/data du WM pour faire pointer vers "Apps/WordpressPortable/Data/mysql/"
- Modifie le "server block" dans la config Nginx pour qu'il prenne en compte le "site" Wordpress.
- Lance le WM. C'est à dire fait tourner les serveurs Nginx et Mysql et affiche le menu dans la barre de notification
- Ouvre le navigateur (tant qu'à faire Framafox) sur localhost/wordpress et affiche le menu spécifique à Wordpress dans la barre de notif
- Par rapport au menu unique actuel on se retrouverait donc avec 2 (ou plus) menus, Wordpress et WM :
Par défaut sur Wordpress :
> Ouvrir - Aide - Site Officiel - Support Officiel - Article Framalibre - Support Framakey
> Sous-menu Scripts : Export bdd - Réinit bdd (ces 2 là étaient en scripts génériques) - Réinit log/pass - Réinit config - Ouvrir wp-admin.php - Editer wp-setting.php - Editer scripts.ini
> Quitter : supprime lien symbolique Mysql et server block Nginx ; puis vérifie s'il est la dernière webapp au quel cas on ferme aussi le WM sinon on recharge la config serveur.
Dans le menu WM :
> Config avancée - Infos - Aide WM - A propos
> Sous-menu Scripts : Editer php.ini - Ouvre localhost/phpinfo.php - Editer scripts.ini du WM
> Sous-menu Mysql : idem actuellement avec phpmyadmin en plus
> Sous-menu Nginx : idem menu ZMWS actuel
> Quitter : supprime tous les liens symboliques Mysql et servers blocks Nginx ; ferme le WM et toutes les webapps ouvertes.
Présenté de telle manière, ça me semble plus intéressant et compréhensible pour l'utilisateur débutant. Ça peut peut-être l'inciter à essayer de comprendre comment marche wordpress avant d'être noyé sous les infos plus techniques du WM (config serveur, php.ini, mysql, etc)
EDIT :
Points positifs
- Réduction de la taille des fichiers : bon pour la clé et pour le temps de téléchargement
- Maintenance réduite : quand on mets à jour le WM, l'effet est immédiat pour toutes les webapps d'un coup (pas intérêt à se planter côté dev ).
- Développement simplifié :
- en gros, on a juste à faire une installation de la webapp
- s'il y a des chemins absolus dans la bdd ou dans les fichiers de conf on garde le startup.ini mais ça devrait rester marginal.
- et du coup, on peut se permettre de peaufiner les scripts.ini
- et même envisager un script de synchronisation ftp avec un serveur de prod.
- en gros, on a juste à faire une installation de la webapp
- Utilisation réseau simplifiée : puisqu'il n'y a plus de gestion des ports, il suffit de donner l'ip de la machine sur laquelle tourne le WM et l'utilisateur aura accès à toutes les webapps en fonctionnement. Ça évite aussi les problèmes de configuration du pare-feu.
- Stabilité/rapidité : parce qu'un seul processus serveur/php/sql est lancé pour toutes les webapps
- Sécurité : cloisonnement www/sql et une seule modification à faire pour sécuriser l'accès à la bdd
- Pérennité : logiciels très utilisés et maintenus
-
JosephK
- Messages : 2221