EBS01

Membres
  • Compteur de contenus

    31
  • Inscription

  • Dernière visite

Tout ce qui a été posté par EBS01

  1. J'ai déjà eu des erreurs sur l'étape 0 lors de mes tests et c'était souvent car un fichier était utilisé par un autre processus.
  2. En effet, en cas d'erreur lors de la mise à jour, les messages d'erreur ne sont pas très explicites ? Tu as regardé dans la console du navigateur (touche F12 par exemple pour Firefox), il devrait y avoir un peu plus de détail sur l'erreur. Jérôme
  3. .htaccess - https

    C'est avec plaisir !
  4. .htaccess - https

    Je t'ai mis le fichier au 2 formats : 1- UTF-8 with BOM , 473 octets (qui doit provoquer ton erreur) 2- UTF-8 , 470 octets (qui doit fonctionner). htaccess_utf8WithBOM.TXT htaccess_utf8.txt
  5. .htaccess - https

    C'est sur que c'est un problème d'encodage, c'est pour cela que je te demandais de le convertir en UTF-8 without BOM. Comme je suis sur mon téléphone, je ne peux pas te le faire ?
  6. .htaccess - https

    Je ne vois rien de particulier (c'est bien le fichier qui pose problème ?) mais tu peux essayer de l'encoder en "UTF-8 without BOM" (avec notepad++ par exemple) car les 3 caractères en question sont bien des caractères invisibles en "Unicode BOM" mais que Apache voit (et ne reconnaît pas) lors de l'utilisation de ton htaccess
  7. .htaccess - https

    Non le fichier en lui même que je puisse l'ouvrir avec un de mes éditeurs de texte.
  8. .htaccess - https

    Tu peux me transmettre ton fichier ?
  9. .htaccess - https

    Bonjour, Dans ton message d'erreur il est noté Invalid command '\xef\xbb\xbf# Avec quel logiciel as-tu édité le fichier htaccess ? Il semblerait qu'il y ait des caractères incorrects (\xef est par exemple le caractère ï en unicode) Jérôme
  10. Sécurité, faille + divers

    Tout dépend de ce que tu as trouvé. S'il s'agit de "failles" après avoir modifié un (ou des) fichier(s) de Zwii (PHP, json) alors les développeurs ne pourront pas faire grand chose ; ça aidera juste les personnes qui sont moins à l'aise avec le code à comprendre ce qu'ils doivent vérifier avant d'installer tel ou tel plugins. Si par contre, sur un Zwii officiel et sans la moindre modification, tu as trouvé le moyen de te connecter sans mot de passe ou en tant qu'administrateur alors que tu ne l'est pas, à accéder directement à des fichiers (PHP, json, ressources), à récupérer la liste des utilisateurs/mots de passe, à modifier/supprimer des éléments sans être connecté avec un compte admin, etc. alors oui, il s'agit d'une vrai faille de sécurité. Jérôme
  11. Sécurité, faille + divers

    Bonsoir, Tout d'abord, bonne année 2019 à tous ! Pour les 2 "problèmes" de sécurité : 1- première règle, on ne clique jamais sur un lien (ou un bouton) provenant d'un mail sans vérifier le lien. Idem pour un plugin, toujours étudier un minimum son contenu ne serait-ce que pour vérifier qu'il ne récupère par des mots de passe pour les envoyer à une personne mal intentionnée... Ensuite peut-être rajouter dans zwii un message de confirmation avant de supprimer une page (y en a peut-être déjà un, je n'ai pas vérifié en ce 1er de l'an). 2- idem, vérifier les plugins...c'est de partout pareil, du moment que le code est en open-source, tout le monde peut l'étudier et créer un plugin "malsain". D'où ma prévision dans la gestion des plugins de proposer des plugins "officiels" (écrits ou vérifiés par l'équipe Zwii) et les "non-officiels" pour lesquels chaque utilisateur prendra la responsabilité de les déployer ou non. Jérôme
  12. Version 8.5.2 et la suite

    Bonjour, La v9 avance (pas que sur la gestion des plugins; je mets aussi à jour les librairies externes pour prendre les dernières versions) ... Je complèterais prochainement le sujet que j'ai ouvert pour indiquer l'avancement. Je prends note de ta 2ème remarque. Quelle est ta vision des choses ? Un fichier json par type de données (config, thème, données utilisateur, etc.) ? Il faut peut être ouvrir une discussion sur le sujet. Jérôme
  13. [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
  14. [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
  15. [A suivre] Atelier "plugins" #2

    Je n'ai pas toujours beaucoup de temps mais tu peux me poser tes questions.
  16. [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
  17. [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
  18. 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
  19. 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
  20. 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