EBS01

Membres
  • Compteur de contenus

    10
  • Inscription

  • Dernière visite

Réputation sur la communauté

14 Bien

À propos de EBS01

  • Rang
    Apprenti

Visiteurs récents du profil

100 visualisations du profil
  1. [A suivre] Atelier "plugins" #2

    Allez encore un petit message sur l'avancement. J'ai codé les parties suivantes : Téléchargement d'une archive tar.gz contenant un plugin Décompression de l'archive dans site/plugins Exécution de la fonction checkBeforeDeploy qui se trouve dans le plugin et effectuant divers contrôles; si OK ajout en base de la présence du plugin à l'état "Désactivé" Sauvegarde de la base Exécution de la fonction deploy qui se trouve dans le plugin qui permet de modifier les fichiers standards et modifier également les données en base (je suis partie du plugin group_adherent que je commence à bien connaître; la dernière étape de modification des id des groupes dans la base se fait donc automatiquement); si OK update de la base pour passer le statut du plugin à l'état "Activé" Je me suis fortement inspiré de la fenêtre faisant la mise à jour de zwii (affichage des étapes, message en cas d'erreur). Au niveau du plugin, il est constitué actuellement de la façon suivante : - A la racine, un fichier readme (écriture libre) et un fichier informations.json contenant différentes données (nom plugin, auteur, version, description, etc...) - Un répertoire deploy contenant un fichier deploy.php (avec 2 fonctions : checkBeforeDeploy et deploy qui sont appelées par Zwii ) - Un répertoire undeploy contenant un fichier undeploy.php (avec 2 fonctions : checkBeforeUndeploy et undeploy qui sont appelées par Zwii ) Reste à faire : Au point 2, récupérer les informations contenues dans le fichier json du plugin A l'étape 5, prévoir une sauvegarde des différents fichiers qui seront modifiés (la liste est contenue dans le fichier json du plugin) afin de pouvoir faire un rollback si besoin La partie undeploy Rendre le tout robuste Prévoir l'évolution en fin de mise à jour de Zwii pour réactiver les éventuels plugins présents et certainement plein d'autres choses que je n'ai pas encore creusées (par exemple pouvoir contrôler la structure correct du plugin après décompression, etc...)... Peut-être que début 2019, je pourrais proposer, sur une branche spécifique, une version beta à @cybertaf et @PeterRabbit pour avis. Jérôme
  2. [A suivre] Atelier "plugins" #2

    Pour info je suis en train de regarder pour implémenter un gestionnaire de plugin dans Zwii...je ne sais pas où cela va mener mais si ça va au bout cela sera en effet une version 9 et il faudra alors standardiser la conception des plugins. En gros voilà comment je vois les choses : 1- Une page listant les plugins installés (donc stockés dans le json) avec différents états : Activé, Désactivé, Erreur et Non applicable (cas ou zwii a été mis à jour et que le plugin qui était installé n'est plus compatible). Sur chaque plugin, possibilité de l'activer/désactiver/supprimer(boutons accessibles selon l'état) - Cette page d'affichage est faite et affiche les plugins présents dans le Json avec leur état et les boutons permettant de lancer les actions (qui ne sont pas codées pour le moment ...faut pas rêver ) 2- Sur cette page un bouton permettant d'afficher une liste de plugins disponibles pour la version de Zwii (mais non installés); là je ne sais pas si c'est réalisable facilement, je ne sais pas comment sont stockés les plugins et s'il y a la possibilité d'avoir un fichier listant les plugins avec différents infos (style fichier json que je pourrais parser) Pour chacune des lignes de cette liste, un bouton permettant de faire les étapes suivantes : Download du fichier dans 'site/plugins', décompression du fichier, contrôle de la possibilité d'installer le plugin, sauvegarde des différents fichiers qui seront modifiés, installation du plugin 3- Lors de la mise à jour de Zwii, le comportement actuel serait gardé (écrasement des fichiers) mais une étape supplémentaire serait ajoutée pour vérifier si tous les plugins enregistrés en base peuvent être redéployés; si oui cela sera fait, sinon le statut du plugin sera changé dans la "base" à "Non Applicable" Voilà pour une première version livrée en ????? Ensuite, il faudrait intégrer la détection de mise à jour disponible pour les plugins. Allez j'arrête de pourrir ton atelier ! Jérôme
  3. [A suivre] Atelier "plugins" #2

    Je n'ai pas toujours beaucoup de temps mais tu peux me poser tes questions.
  4. [A suivre] Atelier "plugins" #2

    Bonjour, quelques axes d'améliorations pour la création de plugin : 1) Prévoir l'installation en "2 passes" : première passe sans faire réellement les modifications, juste vérifier que toutes les chaînes que l'on doit remplacer existent si tout est ok, effectuer réellement les modifications. Sinon afficher un message d'erreur Pourquoi cela ? Imaginons que l'utilisateur souhaite installer le plugin (nommé B) mais qu'il a auparavant installé un autre plugin (nommé A) ayant touché les mêmes fichiers; si le plugin modifie 3 fichiers et que la modification du dernier fichier ne peut se faire car il ne retrouve le texte à changer, l'installation ne dit rien (aucune erreur) mais le plugin n'est pas installé correctement. 2) La fonction "str_replace" est bien mais la chaîne recherchée doit être exacte; si dans le fichier à modifier, il y a une quelques modifications avec des espaces en plus, des tabulations, etc...le remplacement ne se fera pas. Il est préférable d'utiliser des expressions régulières. C'est un peu plus complexe mais cela permet beaucoup de choses (petit outil en ligne pour tester des expressions régulières regex101.com) 3) il serait souhaitable de prévoir de stocker dans le fichier Json les informations des plugins installés. Lors d'une mise à jour Zwii, ce dernier devrait au minimum indiquer que des plugins sont présents et qu'il faudra les réinstaller à la suite de la mise à jour (là c'est le développeur Zwii qui doit prévoir cela). 4) Dans Zwii, il devrait y avoir une page permettant de lister les plugins présents et leur version (un exemple de plugin à développer....) et donner la possibilité de le désinstaller directement via cette interface. Cela sous-entend que le code de désinstallation doit être stocké dans un fichier permanent dans l'arborescence de Zwii qui serait déposé lors de l'installation (et non dans le fichier index.php comme maintenant) Je m'arrête là pour aujourd'hui. J'essaierai de déposer un plugin sur la proposition que j'ai évoquée dans ce message : Jérôme
  5. [Module] group_adherent

    Bonjour, suite à la mise à jour de mon site (que je n'avais pas fait depuis un petit moment) vers Zwii 8.4.8, j'ai dû ré-installer cette extension et j'en ai profité pour l'étudier plus en détails. J'ai donc apporté des adaptations; je joins le fichier zip au message pour te soumettre ces évolutions. Les principales modifications : Ne pas lire/écrire plusieurs fois le même fichier pour insérer les modification dans `core.php` et `user.php` la modification suivante ne fonctionnait pas car il n'y a avait pas le même nombre de tabulation dans mon fichier `user.php` $replace=str_replace('$userId = $this->getInput(\'userForgotId\', helper::FILTER_ID, true);' . "\n" . "\t" . "\t" . "\t" . 'if($this->getData([\'user\', $userId])) {', '$userId = $this->getInput(\'userForgotId\', helper::FILTER_ID, true);' . "\n" . 'if($this->getData([\'user\', $userId]))' . "\n" . 'if($this->getData([\'user\', $userId, \'group\']) != 1) {', $filecontent); je l'ai remplacé par une recherche via une expression régulière; De plus je pense que la substitution n'était pas vraiment juste car cela donnait ceux-ci // Le script d'origine ... $userId = $this->getInput('userForgotId', helper::FILTER_ID, true); if($this->getData(['user', $userId])) { // ... était remplacé par $userId = $this->getInput('userForgotId', helper::FILTER_ID, true); if($this->getData([user, $userId])) if($this->getData(['user', $userId, 'group']) != 1 { // --------------------------------------------------------------------------------- // J'ai modifié la substitution pour que cela devienne $userId = $this->getInput('userForgotId', helper::FILTER_ID, true); if($this->getData(['user', $userId]) && $this->getData(['user', $userId, 'group']) > self::GROUP_ADHERENT) { ce qui donne dans le code $pattern = '/(\$userId = \$this->getInput\(\'userForgotId\', helper::FILTER_ID, true\);\s+)(if\(\$this->getData\(\[\'user\', \$userId\]\))\) \{/'; $replacement = '${1}${2} && \$this->getData([\'user\', \$userId, \'group\']) > self::GROUP_ADHERENT) {'; $replace=preg_replace($pattern, $replacement, $filecontent); Ajout de contrôles pour éviter d'effectuer plusieurs fois le traitement si un utilisateur déploie le fichier d'install alors qu'il l'a déjà fait Ajout de la `timeZone` et de la `Local` dans les fichiers index.php Modifications inverses dans le fichier de désinstallation Dans le readme, il faudrait ajouter un commentaire dans le cas d'une ré-installation suite à une mise à jour de Zwii : pas nécessaire de modifier les indices des utilisateurs dans le fichier json puisque déjà fait. Maintenant à toi de voir ce qui faut garder ou pas Jérôme group_adherent 2.0.0_EBS.zip
  6. problème menu CLIC & sous menu possible?

    Bonjour, je suis nouvel utilisateur de ce CMS mais si tu ne souhaite pas que le menu "Parent" soit cliquable (c'est aussi mon cas) , il faut modifier la fonction showMenu qui se trouve dans le fichier core\core.php et remplacer la ligne <?php $items .= '<a href="' . helper::baseUrl() . $parentPageId . '"' . $active . $targetBlank . '>'; par <?php if($childrenPageIds){ $items .= '<a ' . $active . '>'; } else { $items .= '<a href="' . helper::baseUrl() . $parentPageId . '"' . $active . $targetBlank . '>'; } Explication : si le menu contient des enfants, ne pas mettre l'attribut href J'espère que l'équipe prendra en compte cette simple petit modif (ou alors qu'elle proposera dans la configuration la possibilité de choisir si on souhaite qu'un menu parent soit cliquable). Jérôme
  7. Nouveau Zwii User

    J'ai fait l'évolution du point 2 (ajout d'une adresse commune) en une quinzaine de minutes (le temps de comprendre un peu le mécanisme de Zwii qui est vraiment abordable). Si l'adresse est renseignée dans les paramètres généraux, le mail du formulaire de contact est systématiquement envoyé à cette adresse (le mécanisme de l'envoi à tous les membres d'un groupe restant toujours actif) Voici les modifications apportées dans les fichiers core/core.php: ligne 48, ajout de la valeur par défaut du nouveau paramètre de config commonEmail <?php ... private $defaultData = [ 'config' => [ 'analyticsId' => '', 'autoBackup' => true, 'cookieConsent' => true, 'favicon' => 'favicon.ico', 'homePageId' => 'accueil', 'maintenance' => false, 'commonEmail' => '', // ***** [[ADD]] Nouveau paramètre pour stocker une adresse mail commune 'metaDescription' => 'Zwii est un CMS sans base de données qui permet à ses utilisateurs de créer et gérer facilement un site web sans aucune connaissance en programmation.', 'social' => [ 'facebookId' => '', 'googleplusId' => '', 'instagramId' => '', 'pinterestId' => '', 'twitterId' => '', 'youtubeId' => '' ], 'timezone' => 'Europe/Paris', 'title' => 'Zwii, votre site en quelques clics !' ], ... core/module/config/config.php: line 175, sauvegarde de la donnée du nouveau paramètre <?php ... public function index() { // Soumission du formulaire if ($this->isPost()) { $this->setData([ 'config', [ 'analyticsId' => $this->getInput('configAnalyticsId'), 'autoBackup' => $this->getInput('configAutoBackup', helper::FILTER_BOOLEAN), 'maintenance' => $this->getInput('configMaintenance', helper::FILTER_BOOLEAN), 'cookieConsent' => $this->getInput('configCookieConsent', helper::FILTER_BOOLEAN), 'favicon' => $this->getInput('configFavicon'), 'homePageId' => $this->getInput('configHomePageId', helper::FILTER_ID, true), 'commonEmail' => $this->getInput('configCommonEmail', helper::FILTER_MAIL), // ***** [[ADD]] Sauvegarde de la valeur du paramètre commonEmail 'metaDescription' => $this->getInput('configMetaDescription', helper::FILTER_STRING_LONG, true), 'social' => [ 'facebookId' => $this->getInput('configSocialFacebookId'), 'googleplusId' => $this->getInput('configSocialGoogleplusId'), 'instagramId' => $this->getInput('configSocialInstagramId'), 'pinterestId' => $this->getInput('configSocialPinterestId'), 'twitterId' => $this->getInput('configSocialTwitterId'), 'youtubeId' => $this->getInput('configSocialYoutubeId') ], 'timezone' => $this->getInput('configTimezone', helper::FILTER_STRING_SHORT, true), 'title' => $this->getInput('configTitle', helper::FILTER_STRING_SHORT, true) ] ]); ... core/module/config/view/index/index.php: line 33, ajout de la zone de saisie du nouveau paramètre ... <?php echo template::textarea('configMetaDescription', [ 'label' => 'Description du site', 'value' => $this->getData(['config', 'metaDescription']) ]); ?> <?php // ***** [[ADD]] Ajout de la zone de saisie de l'adresse commune echo template::mail('configCommonEmail', [ 'help' => 'Saisissez une adresse mail commune.', 'label' => 'Email général', 'value' => $this->getData(['config', 'commonEmail']) ]); // ***** Fin ?> <?php echo template::select('configHomePageId', helper::arrayCollumn($this->getData(['page']), 'title', 'SORT_ASC'), [ 'label' => 'Page d\'accueil', 'selected' => $this->getData(['config', 'homePageId']) ]); ?> ... module/form/form.php: A partir de la ligne 187, modification de la constitution du tableau $to[] --> Si le paramètre commonEmail a été renseigné, l'ajouter à la liste des destinataire. <?php ... // Envoi du mail $sent = true; if ( self::$inputNotices === [] // ***** [[COMMENT]] Mis en commentaire de cette condition AND $group = $this->getData(['module', $this->getUrl(0), 'config', 'group']) ) { // Utilisateurs dans le groupe $to = []; // ***** [[ADD]] La condition mise en commentaire ci-dessus est ajoutée ici // Si envoi de mail au groupe if ($group = $this->getData(['module', $this->getUrl(0), 'config', 'group'])) { foreach ($this->getData(['user']) as $userId => $user) { if ($user['group'] === $group) { $to[] = $user['mail']; } } } // ***** [[ADD]] Si un email commun est configuré dans les pamètres, l'ajouter à la liste des destinataire if ($commonEmail = $this->getData(['config', 'commonEmail'])) { if (!is_null($commonEmail) AND strlen($commonEmail) > 0) { $to[] = $commonEmail; } } // FIN ADD if ($to) { // Sujet du mail $subject = $this->getData(['module', $this->getUrl(0), 'config', 'subject']); if ($subject === '') { $subject = 'Nouveau message en provenance de votre site'; } // Envoi le mail $sent = $this->sendMail( $to, $subject, 'Nouveau message en provenance de la page "' . $this->getData(['page', $this->getUrl(0), 'title']) . '" :<br><br>' . $content ); } } ... Quel est votre avis ? Jérôme
  8. Nouveau Zwii User

    Bonjour, j'ai découvert Zwii très récemment (moins de 5 jours) et je viens de le tester pour un de mes sites...j'ai été bluffé par la simplicité et l'efficacité de ce CMS à tel point que je viens de passer ce site (sous DotClear que je ne supportais pas) à Zwii. Ce site est pour une association qui gère une cantine scolaire; les bénévoles n'étant pas des informaticiens, il faut quelque chose de simple et avec un beau rendu. Je crois que j'ai trouvé ce qu'il faut . J'ai également ajouté le module group_adherent qui correspond parfaitement à nos besoins. Maintenant 2 petits reproches (quand même) ou du moins une demande d'évolution : 1- Il n'est pas possible de modifier un identifiant. J'avais fais tout la conversion du site en local avec un utilisateur ayant l'identifiant admin mais pour le site de prod, je voulais un identifiant moins simple. J'ai bien vu que le rechercher/remplacer dans le json ne fonctionnait pas car le cryptage du mot de passe prend en compte l'identifiant. ==> Ne serait-il pas possible d'implémenter une fonction spéciale pour permettre la modification de l'identifiant (qui implique donc aussi le changement de mot de passe). Pour l'histoire, dans mon cas, après avoir remplacer l'identifiant dans mon json, j'ai créé sur un second Zwii un user avec l'identifiant voulu j'ai recopié le password crypté dans mon le json de mon site. 2- Le deuxième point est plus important pour nous. Pour le formulaire de contact, le mail est envoyé à l'ensemble des utilisateurs d'un groupe donné; dans notre cas nous utilisons une adresse commune pour l'association et nous souhaitons, même s'il y a plusieurs administrateurs du site que les messages soient envoyés uniquement à cette adresse. Pour le moment j'ai modifié le form.php pour que la variable $to ne comporte que cette adresse. Il serait bien de pouvoir indiquer dans le paramétrage global du site (au même endroit où l'on définit les réseaux sociaux) une adresse mail générale; et au niveau du formulaire de contact de pouvoir sélectionner uniquement cette adresse. Et aller un dernier point, il serait bien de pouvoir indiquer que le mail envoyé via le formulaire de contact ai pour adresse d'expéditeur l'adresse qu'a saisi la personne (au lieu du noreply) afin de pouvoir faire une réponse directement (je sais que je peux faire un "transférer" mais c'est pour chipoter) Dans tous les cas, bon travail ! Jérôme