@bazooka07 Je vois tout à fait la discussion dont tu parles sur Twitter, j'avais essayé d'aider cette personne non francophone. Je ne suis pas une utilisateur avancée de PluXml mais sur des questions de prise en main "basique" je peux aider en anglais ou en français.
@P3ter J'aimerais aider à la traduction anglaise de la documentation basique "Installer / Utiliser / Personnaliser / Développer", quel(s) outil(s) recommandes-tu ?
BD humoristiques, illustrations choupi et réflexions libristes-friendly sur PetitLutinArtiste.fr
J'attends toujours une rubrique anglophone dans ce forum.
Pour une traduction rapide, j'utilise google translation mais c'est loin d'être parfait. Il faut le passage d'un humain pour corriger des erreurs de traduction ou des tournures de phrase bizarres.
Techniquement parlant, je t'invite à aller faire un tour sur Github pour voir les sources de la documentation du Wiki de PluXml. C'est par là :
Toute la mise en forme du wiki est générée par un utilitaire Markdown.
Il te faut apprendre le langage Markdown pour créer les fichiers sources en anglais. C'est un langage assez simple qui s'apprend rapidement.
Pour voir à quoi cela ressemble sur Github vas dans le dossier ou rubrique "docs". Descends encore dans un sous dossier pour trouver un fichier avec l'extension ".md" . C'est un fichier au format markdown.
Quand on clique sur le nom du fichier, on a le rendu final de la page. Pour voir à quoi ressemble le source de la page, clique sur le bouton "raw". "Raw" signifie forme brute.
Après il te faudrait apprendre quelques base d'un utilitaire qui s'appelle git pour proposer tes traductions pour le wiki.
Il te faudra créer aussi un compte sur Github.com. c'est gratuit et simple à utiliser. Cela va très bien pour faire du travail collaboratif.
J'ai un compte Github mais pour le moment je n'ai que des projets personnels dessus. Je n'ai encore jamais fait de travail collaboratif, alors c'est une très bonne occasion pour m'y mettre :)
Je n'ai pas de souci avec le Mardown, mais c'est plutôt la procédure à suivre avec git qu'il me faut apprendre pour pouvoir proposer mes traductions : il faut cloner le projet, ajouter mes traductions puis faire une pull request ?
BD humoristiques, illustrations choupi et réflexions libristes-friendly sur PetitLutinArtiste.fr
Merci beaucoup @Petit_Lutin de proposer ton aide ;-)
Tous les fichiers source (en markdown) du wiki sont disponibles sur Github. J'ai mis à jour le readme avec la procédure d'installation de Mkdocs. Malheureusement ce dernier ne gère pas le multilingue et pour l'instant, je n'ai pas d'autre idée que de créer deux instances du wiki l'une en français l'autre en anglais. J'ai créé la branche multilang en ce sens.
Donc, si tu connais git et github, tu peux cloner cette branche, traduire l'instance "en" (en modifiant directement les fichiers ".md"), puis faire une pull request, ou bien tu peux aussi télécharger le zip de la branche multilang, traduire et me renvoyer le zip modifié.
Encore merci.
EDIT : félicitation pour ta formation de dev web ! ;-)
Je vais donc cloner la branche multilang et traduire les fichiers ".md" de l'instance "en", et faire une pull request après. Utiliser git ne pourra que me faire progresser ^^
BD humoristiques, illustrations choupi et réflexions libristes-friendly sur PetitLutinArtiste.fr
Pour ma part, j'aime avoir un moyen simple de sauver l'ensemble des données d'un site en sauvant un seul répertoire. De plus, en terme de sécurité, j'aime pouvoir déplacer le répertoire "data" hors du répertoire visible par internet.
Dans ce sens, je vais surement proposer une modification au niveau de la gestion des dossiers "data", "plugins" et "themes" pour sécuriser tout ça.
EDIT: Je vois que la future version propose déjà presque ça ! C'est top, mais il me semble que ça devrait plutôt se trouver dans le fichier "config.php" justement...
EDIT 2 : Pull Request proposée, logiquement c'est aussi stable et ça permet de séparer toutes les données "volatiles" ailleurs de manière simple.
EDIT 3 Alors en fait, il reste des PLX_ROOT devant plein de constantes de type "chemin" et ça casse tout partout quand on veut déplacer le répertoire "data/". Je vais tâcher de passer partout pour fixer ça.
Le dossier data contient des images, des pdf, des document (open)office, des archives zip qui nécessitent un accès direct.
les dossiers de plugins contiennent très souvent des scripts Javascript qui ont besoin de liens direct
idem pour les thèmes avec des feuilles de style CSS, des images et des scripts Javascript.
Mais il a des améliorations plus simples que j'ai déjà proposé il y a plusieurs années à faire :
mettre dans un dossier "assets" tous les fichiers du dossier "core/lib/" qui ne sont pas de scripts PHP
déplacer le dossier "core/lib" en dehors du "DocumentRoot" du serveur HTTP
pouvoir renommer le dossier de données "data" facilement en changeant facilement sa valeur dans le fichier config.php à la racine du site, fichier qui devrait être lui aussi en dehors du "DocumentRoot". Et ce dossier de données doit se créer entièrement à l'installation s'il n'existe pas.
Cela complique légèrement l'installation mais tant que cela si c'est expliqué simplement.
Par contre, cela risque de coincer chez les hébergeurs qui ne permettent pas de changer le "DocumentRoot", par exemple les pages persos de Free.
Je viens de télécharger la version master du 18 avril
Lorsque je lance l'install:
Parse error: syntax error, unexpected '' (T_ENCAPSED_AND_WHITESPACE), expecting '-' or identifier (T_STRING) or variable (T_VARIABLE) or number (T_NUM_STRING) in E:\htdocs\testing-PluXml\PluXml-2020-04-18\install.php on line 439
Apparement il y a eu un souci dans la fusion d'un commit.
J'ai envoyé un push-request (PR) pour corriger cela (#415: https://github.com/pluxml/PluXml/pull/415 )
Attends qu'il soit fermé pour refaire un test.
Après ce correctif j'accède bien à la page d'accueil pour l'installation.. je saisis les paramètres et je fais install.
Message d'erreur :
Main PluXml theme not found (./themes/) !
Effectivement il y a un petit souci.
La fonction plxUtils::cdataCheck() a évolué pour éviter d'avoir dans les fichiers .xml ce genre de choses:
<![CDATA[]]>
Mais cela oblige à reprendre la génération des fichiers .Xml.
Rien de méchant. Laissez-moi 48 heures pour corriger le tir.
Pour faciliter le passage de PluCSS à Knacss, serait-il possible de créer un genre d'annuaire qui aiderait à trouver les correspondances?
Ou bien ça n'a pas de sens?
Pour avoir commencé à regarder de près Knacss dans le cadre de PluXml 6, il peut y avoir une correspondance pour certains éléments basiques, comme les "alertes" par exemple, mais le système de grille est très différents (plus simple d'ailleurs, que celui de PluCSS ou de Bootstrap) et nécessite des changements dans la structure HTML des pages.
Bonjour
Pour etre sur d'avoir bien compris, sur github la version master correspond à la future version 6 et la version 5.8.3 correspond à la 5.8.3 RC avec au fur et à mesure des correctifs?
Bonjour, oui c'est bien ça. Bien sûr la branche 5.8.3 est mergée dans master au fil de l'eau. Une fois la version 5.8.3 publiée, un tag sera créé et la branche sera supprimée pour éviter les confusions.
Utiliser Knacss me semble une excellente idée, léger et fiable et évolutif, il garde la même logique que PluXML.
Par contre, utiliser un framework comme LARAVEL me fait un peu peur. N'étant pas développeur j'ai réussi à comprendre assez facilement le fonctionnement de PluXML, par contre je n'ai jamais réussi à m'approprier le fonctionnement d'un framework moderne.
On ne basculera pas PluXml sur un framework de ce type, pour le garder le plus simple et léger possible ;-)
J'ai fait quelques essais sur Laravel pour d'autres projets et ça n'apporterai pas grand chose à PluXml.
Pareil, PluXML, malgré quelques traces du temps qui passe, reste le CMS le plus simple à bricoler (devant Grav, Bludit...). On arrive toujours à sortir ce que l'on souhaite. :-)
Autre remarque, pourquoi ne pas générer les dossiers /plugins/ et /data/ à l'installation ?
Ainsi lors d'une mise à jour on ne risque pas d'écraser nos fichiers existants.
C'est vrai qu'il ne reste pas grand chose dans le dossier data, quelques fichiers .htaccess, qui ne servent à rien avec un serveur Nginx en passant
Je pense qu'on pourrait également proposer de renommer data et plugins à l'installation.
Bonjour,
Pour un hacker, il est facile de savoir si par exemple le site http://mon-site.com est propulsé par PluXml.
Il suffit d'essayer de se connecter à la page http://mon-site.com/core/admin/.
S'il a connaissance d'une faille de sécurité dans PluXml ou dans un de ses plugins, il pourra alors accomplir son forfait.
Evidemment, il ne va pas vérifier à la main l'existence de cette page. Il a un stupide bot qui scanne tout l'internet pour lui.
Pour reprendre le célèbre dicton, "Pour vivre heureux, vivons cachés", l'idée est de pouvoir renommer ce dossier à sa convenance ce dossier pendant ou après l'installation.
C'est relativement facile à faire. Cela fait l'objet du Pull-Request (PR) suivant : https://github.com/pluxml/PluXml/pull/443
Une fois ce PR appliqué, il suffit de :
renommer le dossier core/admin en, par exemple, core/ckilepatron
d'ajuster dans le fichier la constante PLX_ADMIN_PATH avec ce nouveau nom
de supprimer le lien d'accès à la page d'authentification dans le bas de la page d'accueil du site
Etant utilisateur de Pluxml depuis un certain temps, je souhaite aussi donner mon avis.
Avant tout pour la question CSS, je pense que qu'il faut garder Plucss, je pense que ça ne vaut pas la peine
de passer Knacss. Ou alors autant passer à Bootstrap. Pour ma part, de toute manière
si vous décidez de passer à Knacss, je finirai comme même par le bootstraper. Après il y a aussi materializecss qui fait de belles choses.
Donc je pense que c'est plutôt une perte de temps de changer le CSS, puis au moins ça laisse la liberté aux gens de faire ce qu'ils veulent.
Donc Je pense qu'il faut plutôt se concentrer sur les optimisations et la sécurité.
Je m'y connais pas assez en cryptographie mais peut-être actualiser la méthode de hash si c'est possible.
Permettre aux gens de sécuriser et optimiser plus facilement leur site, avec les sécurityHeaders, la gestion des cookies, le cache des plugins.
Optimiser le code php, afin de garder Pluxml le plus léger et le plus compatible possible.
Faire une base de plugins remise à jour à chaque sortie de nouvelle monture, qui permette d'étendre les possibilités de Pluxml.
Donc pour moi la 583 est sur la bonne voie, sur que tout le monde va pas être d'accord avec moi, mais ça reste mon avis.
Bonne soirée, bonne réflexion
Réponses
@bazooka07 Je vois tout à fait la discussion dont tu parles sur Twitter, j'avais essayé d'aider cette personne non francophone. Je ne suis pas une utilisateur avancée de PluXml mais sur des questions de prise en main "basique" je peux aider en anglais ou en français.
@P3ter J'aimerais aider à la traduction anglaise de la documentation basique "Installer / Utiliser / Personnaliser / Développer", quel(s) outil(s) recommandes-tu ?
BD humoristiques, illustrations choupi et réflexions libristes-friendly sur PetitLutinArtiste.fr
@Petit_Lutin
J'attends toujours une rubrique anglophone dans ce forum.
Pour une traduction rapide, j'utilise google translation mais c'est loin d'être parfait. Il faut le passage d'un humain pour corriger des erreurs de traduction ou des tournures de phrase bizarres.
Techniquement parlant, je t'invite à aller faire un tour sur Github pour voir les sources de la documentation du Wiki de PluXml. C'est par là :
Sources sur Github
Toute la mise en forme du wiki est générée par un utilitaire Markdown.
Il te faut apprendre le langage Markdown pour créer les fichiers sources en anglais. C'est un langage assez simple qui s'apprend rapidement.
Pour voir à quoi cela ressemble sur Github vas dans le dossier ou rubrique "docs". Descends encore dans un sous dossier pour trouver un fichier avec l'extension ".md" . C'est un fichier au format markdown.
Quand on clique sur le nom du fichier, on a le rendu final de la page. Pour voir à quoi ressemble le source de la page, clique sur le bouton "raw". "Raw" signifie forme brute.
Après il te faudrait apprendre quelques base d'un utilitaire qui s'appelle git pour proposer tes traductions pour le wiki.
Il te faudra créer aussi un compte sur Github.com. c'est gratuit et simple à utiliser. Cela va très bien pour faire du travail collaboratif.
Tu travailles sur Mac ?
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
@bazooka07 Je suis sur Windows.
J'ai un compte Github mais pour le moment je n'ai que des projets personnels dessus. Je n'ai encore jamais fait de travail collaboratif, alors c'est une très bonne occasion pour m'y mettre :)
Je n'ai pas de souci avec le Mardown, mais c'est plutôt la procédure à suivre avec git qu'il me faut apprendre pour pouvoir proposer mes traductions : il faut cloner le projet, ajouter mes traductions puis faire une pull request ?
BD humoristiques, illustrations choupi et réflexions libristes-friendly sur PetitLutinArtiste.fr
Merci beaucoup @Petit_Lutin de proposer ton aide ;-)
Tous les fichiers source (en markdown) du wiki sont disponibles sur Github. J'ai mis à jour le readme avec la procédure d'installation de Mkdocs. Malheureusement ce dernier ne gère pas le multilingue et pour l'instant, je n'ai pas d'autre idée que de créer deux instances du wiki l'une en français l'autre en anglais. J'ai créé la branche multilang en ce sens.
Donc, si tu connais git et github, tu peux cloner cette branche, traduire l'instance "en" (en modifiant directement les fichiers ".md"), puis faire une pull request, ou bien tu peux aussi télécharger le zip de la branche multilang, traduire et me renvoyer le zip modifié.
Encore merci.
EDIT : félicitation pour ta formation de dev web ! ;-)
Merci @P3ter ! :)
Je vais donc cloner la branche multilang et traduire les fichiers ".md" de l'instance "en", et faire une pull request après. Utiliser git ne pourra que me faire progresser ^^
BD humoristiques, illustrations choupi et réflexions libristes-friendly sur PetitLutinArtiste.fr
Un petit conseil :
Il vaut mieux envoyer des petits PUSH REQUEST (PR) régulièrement plutôt que d'attendre d'avoir tout fini.
C'est plus facile à fusionner avec la branche de référence s'il y a d'autres modifications en parallèle.
Au minimum un PR par page voire plus.
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
Bien noté !
BD humoristiques, illustrations choupi et réflexions libristes-friendly sur PetitLutinArtiste.fr
Coucou,
Pour ma part, j'aime avoir un moyen simple de sauver l'ensemble des données d'un site en sauvant un seul répertoire. De plus, en terme de sécurité, j'aime pouvoir déplacer le répertoire "data" hors du répertoire visible par internet.
Dans ce sens, je vais surement proposer une modification au niveau de la gestion des dossiers "data", "plugins" et "themes" pour sécuriser tout ça.
EDIT: Je vois que la future version propose déjà presque ça ! C'est top, mais il me semble que ça devrait plutôt se trouver dans le fichier "config.php" justement...
EDIT 2 : Pull Request proposée, logiquement c'est aussi stable et ça permet de séparer toutes les données "volatiles" ailleurs de manière simple.
EDIT 3 Alors en fait, il reste des PLX_ROOT devant plein de constantes de type "chemin" et ça casse tout partout quand on veut déplacer le répertoire "data/". Je vais tâcher de passer partout pour fixer ça.
@Mindiell
Ce n'est pas si simple :
Mais il a des améliorations plus simples que j'ai déjà proposé il y a plusieurs années à faire :
Cela complique légèrement l'installation mais tant que cela si c'est expliqué simplement.
Par contre, cela risque de coincer chez les hébergeurs qui ne permettent pas de changer le "DocumentRoot", par exemple les pages persos de Free.
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
Bonjour,
Il y a aussi un petit plugin qui fait une partie du travail BackUpAll. Je te retrouve le lien un peu plus tard
Bonjour,
Je viens de télécharger la version master du 18 avril
Lorsque je lance l'install:
Parse error: syntax error, unexpected '' (T_ENCAPSED_AND_WHITESPACE), expecting '-' or identifier (T_STRING) or variable (T_VARIABLE) or number (T_NUM_STRING) in E:\htdocs\testing-PluXml\PluXml-2020-04-18\install.php on line 439
Apparement il y a eu un souci dans la fusion d'un commit.
J'ai envoyé un push-request (PR) pour corriger cela (#415: https://github.com/pluxml/PluXml/pull/415 )
Attends qu'il soit fermé pour refaire un test.
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
C'est mergé, merci pour la correction.
Après ce correctif j'accède bien à la page d'accueil pour l'installation.. je saisis les paramètres et je fais install.
Message d'erreur :
Main PluXml theme not found (./themes/) !
Effectivement il y a un petit souci.
La fonction plxUtils::cdataCheck() a évolué pour éviter d'avoir dans les fichiers .xml ce genre de choses:
<![CDATA[]]>
Mais cela oblige à reprendre la génération des fichiers .Xml.
Rien de méchant. Laissez-moi 48 heures pour corriger le tir.
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
Voir PR #421: https://github.com/pluxml/PluXml/pull/421
ou git clone --depth 1 -b cdata-2004 https://github.com/kazimentou/PluXml.git
Juste tester pour une installation complète. Je vais regarder pour mettre à jour un "vieux site".
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
C'est mergé sur PluXml 5.8.3 (master).
L'installation complète est maintenant fonctionnelle.
Pour une installation complete ou pour une mise à jour, c'est OK
Merci
Bonjour,
Pour faciliter le passage de PluCSS à Knacss, serait-il possible de créer un genre d'annuaire qui aiderait à trouver les correspondances?
Ou bien ça n'a pas de sens?
Pour avoir commencé à regarder de près Knacss dans le cadre de PluXml 6, il peut y avoir une correspondance pour certains éléments basiques, comme les "alertes" par exemple, mais le système de grille est très différents (plus simple d'ailleurs, que celui de PluCSS ou de Bootstrap) et nécessite des changements dans la structure HTML des pages.
Bonjour
Pour etre sur d'avoir bien compris, sur github la version master correspond à la future version 6 et la version 5.8.3 correspond à la 5.8.3 RC avec au fur et à mesure des correctifs?
Bonjour, oui c'est bien ça. Bien sûr la branche 5.8.3 est mergée dans master au fil de l'eau. Une fois la version 5.8.3 publiée, un tag sera créé et la branche sera supprimée pour éviter les confusions.
Utiliser Knacss me semble une excellente idée, léger et fiable et évolutif, il garde la même logique que PluXML.
Par contre, utiliser un framework comme LARAVEL me fait un peu peur. N'étant pas développeur j'ai réussi à comprendre assez facilement le fonctionnement de PluXML, par contre je n'ai jamais réussi à m'approprier le fonctionnement d'un framework moderne.
On ne basculera pas PluXml sur un framework de ce type, pour le garder le plus simple et léger possible ;-)
J'ai fait quelques essais sur Laravel pour d'autres projets et ça n'apporterai pas grand chose à PluXml.
Bonjour;à tous, me présente.
Développeur passionné, et nouveau membre sur le forum je souhaite véritablement féliciter la ligne de conduite actuelle.
PluXml est un outil formidable.
Je développe actuellement un outil statistique, sans base de données très ergonomique, puissant et respectant la vie privée des utilisateurs.
Je vais très certainement le proposer un plugin pour pluXML. La légèreté de PluXml est un véritable atout.
Bien évidemment il y a des améliorations à apporter et je pense travailler sur ce projet.
Laravel, Symphony etc . . Sont à mes yeux des outils inutiles, trop gourmand et au final à mes yeux peu stable car trop complexe.
Pareil, PluXML, malgré quelques traces du temps qui passe, reste le CMS le plus simple à bricoler (devant Grav, Bludit...). On arrive toujours à sortir ce que l'on souhaite. :-)
Autre remarque, pourquoi ne pas générer les dossiers /plugins/ et /data/ à l'installation ?
Ainsi lors d'une mise à jour on ne risque pas d'écraser nos fichiers existants.
C'est vrai qu'il ne reste pas grand chose dans le dossier data, quelques fichiers .htaccess, qui ne servent à rien avec un serveur Nginx en passant
Je pense qu'on pourrait également proposer de renommer data et plugins à l'installation.
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
Bonjour,
Pour un hacker, il est facile de savoir si par exemple le site http://mon-site.com est propulsé par PluXml.
Il suffit d'essayer de se connecter à la page http://mon-site.com/core/admin/.
S'il a connaissance d'une faille de sécurité dans PluXml ou dans un de ses plugins, il pourra alors accomplir son forfait.
Evidemment, il ne va pas vérifier à la main l'existence de cette page. Il a un stupide bot qui scanne tout l'internet pour lui.
Pour reprendre le célèbre dicton, "Pour vivre heureux, vivons cachés", l'idée est de pouvoir renommer ce dossier à sa convenance ce dossier pendant ou après l'installation.
C'est relativement facile à faire. Cela fait l'objet du Pull-Request (PR) suivant :
https://github.com/pluxml/PluXml/pull/443
Une fois ce PR appliqué, il suffit de :
de supprimer le lien d'accès à la page d'authentification dans le bas de la page d'accueil du site
Et c'est tout
Accès à mon dépôt de plugins et thèmes
installe PluXml plus vite que ton ombre avec kzInstall2
Bonjour,
Etant utilisateur de Pluxml depuis un certain temps, je souhaite aussi donner mon avis.
Avant tout pour la question CSS, je pense que qu'il faut garder Plucss, je pense que ça ne vaut pas la peine
de passer Knacss. Ou alors autant passer à Bootstrap. Pour ma part, de toute manière
si vous décidez de passer à Knacss, je finirai comme même par le bootstraper. Après il y a aussi materializecss qui fait de belles choses.
Donc je pense que c'est plutôt une perte de temps de changer le CSS, puis au moins ça laisse la liberté aux gens de faire ce qu'ils veulent.
Donc Je pense qu'il faut plutôt se concentrer sur les optimisations et la sécurité.
Je m'y connais pas assez en cryptographie mais peut-être actualiser la méthode de hash si c'est possible.
Permettre aux gens de sécuriser et optimiser plus facilement leur site, avec les sécurityHeaders, la gestion des cookies, le cache des plugins.
Optimiser le code php, afin de garder Pluxml le plus léger et le plus compatible possible.
Faire une base de plugins remise à jour à chaque sortie de nouvelle monture, qui permette d'étendre les possibilités de Pluxml.
Donc pour moi la 583 est sur la bonne voie, sur que tout le monde va pas être d'accord avec moi, mais ça reste mon avis.
Bonne soirée, bonne réflexion