PluXml 5.2 le CMS propulsé à l'XML est de sortie

Posté par  . Édité par ZeroHeure, Benoît Sibaud et palm123. Modéré par patrick_g. Licence CC By‑SA.
Étiquettes :
24
11
août
2013
Internet

On en parle peu, et pourtant c'est un système de gestion de contenu (SGC ou CMS pour les anglophones) qui avance à grand pas.
Contrairement à d'autres SGC (Wordpress, Drupal, Spip, etc.) PluXml ne s’appuie pas sur une base de donnée (Mysql, Postgresql, etc.) mais sur des fichiers XML.

La version 5.2 a vu en plus de l'amélioration de son fonctionnement interne, la réécriture d’une partie du moteur des plugins pour accélérer leur chargement et réduire la mémoire occupée, mais aussi la possibilité de créer un patron personnalisé pour la page d'accueil du site en plus de celles des articles, catégories et pages statiques…

PluXml est vraiment un CMS léger, mais facilement modifiable et extensible (voir le wiki et le blog pour la création des plugins)
Mais ce qui étonne le plus, c'est surtout sa rapidité, le temps de création, et d'affichage des pages étant tout simplement "hallucinant"

Un SGC(*) à découvrir d'urgence donc !

Ses principales caractéristiques (reprises du site) :

  • Aucune base de données requise
  • Multi-utilisateurs avec des niveaux d'autorisations différents
  • Pages statiques, catégories, gestion des tags
  • Gestion des commentaires
  • Gestionnaire de médias : images, documents
  • Traduit en 10 langues (français, allemand, anglais, espagnol, italien, néerlandais, polonais, portugais, roumain, russe)
  • Thèmes personnalisables
  • Plugins
  • Réécriture d'urls (nécessite le module apache mod_rewrite)

Notes:
(*) aucun rapport avec le Stargate Command ;-)

Aller plus loin

  • # typo

    Posté par  (site web personnel) . Évalué à 3.

    Petit problème dans la liste

    L'explication du "Le SGC*" est devenu un élément de la liste

    • [^] # Re: typo

      Posté par  . Évalué à 4.

      Voilà c'est mieux?

      "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay

      • [^] # Re: typo

        Posté par  . Évalué à 2. Dernière modification le 12 août 2013 à 01:25.

        Dans le même genre, dans le titre « … est de sorti_e_ ».

        Merci.

    • [^] # Re: typo

      Posté par  . Évalué à 4.

      Pour moi le SGC c'est là où se trouve la porte des étoiles.

  • # Traduction

    Posté par  (site web personnel) . Évalué à 6.

    L'interface d'admin est-elle également traduite, au moins en anglais ? C'est la seule chose que j'attends avant de pouvoir enpaqueter ça pour Debian…

    • [^] # Re: Traduction

      Posté par  . Évalué à 1.

      malheureusement non, une contribution à proposer ;-)

      http://lsm2013.out.airtime.pro:8000/lsm2013.ogg Ecoutez Radio RMLL !

    • [^] # Re: Traduction

      Posté par  . Évalué à 2.

      Bonjour

      Oui, l'interface d'admin est traduite en 10 langues. Chaque utilisateur connecté peut choisir sa langue

      • [^] # Re: Traduction

        Posté par  . Évalué à 1.

        bizarre, même en passant les réglages en 'en' mon admin reste en fr

        http://lsm2013.out.airtime.pro:8000/lsm2013.ogg Ecoutez Radio RMLL !

      • [^] # Re: Traduction

        Posté par  (site web personnel) . Évalué à 5.

        Ah, génial, je viens d'essayer et ça fonctionne à merveille ! Bon, eh bien je sais quel est le prochain paquet Debian que je ferai. Enfin, quand j'aurai rattrapé mon retard dans pas mal de choses tout de même…

    • [^] # Re: Traduction

      Posté par  (site web personnel) . Évalué à 4.

      Ah, et à propos de traduction, on truc qui serait génial, ce serait d'utiliser la langue appropriée pour chaque visiteur.

  • # Le meilleur CMS

    Posté par  . Évalué à 6.

    Je l'utilise depuis 3 ans, car au début car mon serveur n'était pas assez puissant pour faire tourner une usine à gaz telle que wordpress. Et pour moi c'est vraiment le meilleur CMS au monde, très simple, léger, et surtout très facile à bidouiller au niveau des CSS. Je n'en changerai pour rien au monde.

  • # PluXml

    Posté par  . Évalué à 2.

    Merci pour l'info, je ne connaissais point.
    Test en vue donc !

  • # je vais me faire enflammer

    Posté par  . Évalué à 2.

    Autant le contenu doit être accrocheur, exempt de faute(s) (bien que normalement déjà une, c'est de trop), autant le titre doit être irréprochable.

    Pour ma part, je ne le suis absolument pas (irréprochable), c'est la raison pour laquelle je n'ai encore pas fait de titre.

    Par contre: "trucmuche, le bazar qui secoue est de sortiE" (ici j'exagère en plaçant le e en majuscule, mais c'est pour la bonne cause).

    Enfin, pour ce que j'en dis.

    Amicalement.

  • # parlons en et partageons

    Posté par  . Évalué à 6.

    Bonjour,

    Quelle bonne surprise, ça cause Pluxml !

    Lecteur assidu, je décide donc de m'inscrire.

    J'ai découvert Pluxml il y a peu de temps. En quête d'un CMS, si possible "simple", adapté à un usage "maison" sur petit serveur à base d'atom, ayant la particulartié de se passer des BdD Postgres, Mysql, Mariadb, Sqlite.

    La réponse: Pluxml

    J'ai donc pris de mon temps pour étudier le logiciel, avec pour résultat un serveur Nginx+Pluxml en fonction. L'installation en elle-même est ultra simple, cependant je ne m'en suis pas tenu qu'à cela.

    Utilisateur de la distribution Funtoo, j'ai donc investi un temps pour créer un ebuild Pluxml. Je préviens avant tout qu'il s'agit pour moi de prendre en main le système de création des ebuild.

    Je souhaiterai pouvoir partager ce travail, cependant j'ai encore un peu de mal avec git.
    Donc si le ebuild intéresse quelqu'un je serai ravi de le partager sur mon compte github avec un peu d'aide pour être certain que le travail puisse être exploitable.

    Concernant Nginx, j'ai trouvé quelques lignes de codes à jour plus un rewrite à opérer sur l'administration.

    Il y a le forum pluxml complet, il manque à mon avis un moyen de contact instantané. Le direct je trouve cela plus efficace lorsqu'il s'agit d'étudier le logiciel à plusieurs.

    Voilà, merci

  • # Un très rapide petit tour dans les sources

    Posté par  . Évalué à 6.

    et je me pose plusieurs questions:
    - pourquoi des commentaires en français ?
    - pourquoi un code qui mélange français et anglais ?
    - pourquoi des eval à tout va (mais je n'ai pas vérifié si leurs utilisations posaient réellement problème)

    et une pépite sur l'exemple de la page dite statique, dont voici le contenu:
    <p><?php echo 'Ma première page statique !'; ?></p>

    c'est fait exprès ?

    • [^] # Re: Un très rapide petit tour dans les sources

      Posté par  . Évalué à 0.

      Par curiosité, j'ai regardé la documentation et je m'en suis arrêté aux eval. Je me suis dit "mais pourquoi ?". Je ne sais pas si ils sont réinterprétés par un genre de moteur de template (manifestement non), mais je ne comprends pas la raison de faire un eval. Dans tous les cas c'est dommage de procéder ainsi. Si en plus le code est commenté et écrit dans la langue de Molière. Le projet a l'air intéressant, mais comment avec des commentaires en français l'on peut espérer avoir une communauté de développeurs internationaux ?

      Selon moi pour que le projet prenne de l'ampleur il faut :
      - Traduire le code en anglais
      - Tout écrire en anglais et traduire en français
      - Commiter en Anglais (et définir une norme de commit)
      - Avoir un système de templating (Twig ?)
      - Que les dossiers des templates et code soient au niveau inférieur (non accessible depuis la racine du serveur)

      Il y a certainement d'autres points, mais déjà avec ça je me serais un peu plus penché sur le projet.

      • [^] # Re: Un très rapide petit tour dans les sources

        Posté par  . Évalué à 4.

        Si en plus le code est commenté et écrit dans la langue de Molière

        Du moment que c'est en accord avec les objectifs du projet, ce n'est pas un problème en soi.

        comment avec des commentaires en français l'on peut espérer avoir une communauté de développeurs internationaux ?

        ce n'est peut être pas le but recherché pour l'instant

        Que les dossiers des templates et code soient au niveau inférieur (non accessible depuis la racine du serveur)

        dans ce cas, on perd la capacité d'installer un site chez n'importe quel hébergeur.

        Il y a certainement d'autres points, mais déjà avec ça je me serais un peu plus penché sur le projet.

        en fait le projet ne t'interesse pas… ou alors les raisons exposées pour ne pas t'y être "un peu plus penché" me semblent légères

        • [^] # Re: Un très rapide petit tour dans les sources

          Posté par  . Évalué à 1.

          En effet je ne m’intéresse pas plus que ça aux CMS, je n'en utilise pas. Seulement j'ai été curieux par le projet que je trouve assez "innovant".

          Par contre je ne suis pas d'accord sur le fait que de mettre les sources au niveau inférieur ne soit pas compatible avec tous les hébergeurs. Je pense qu'il est inenvisageable de proposer les deux solutions (au même niveau ou au niveau inférieur).

          Il faut penser à l'avenir, se priver que 99% de la population mondiale, c'est quand même un peu dommage. Quant à réécrire plus tard le code pour le traduire en anglais, c'est une monstrueuse perte de temps.

    • [^] # Re: Un très rapide petit tour dans les sources

      Posté par  . Évalué à -3.

      Les eval ne sont pas à tout va et sont là pour les plugins. Cela permet d'écrire du code et d'intervenir sur le core, sans vraiment le modifier.

      • [^] # Re: Un très rapide petit tour dans les sources

        Posté par  (site web personnel) . Évalué à 1.

        Les eval ne sont pas à tout va et sont là pour les plugins. Cela permet d'écrire du code et d'intervenir sur le core, sans vraiment le modifier.

        Exemple trouvé :
        php
        eval($plxAdmin->plxPlugins->callHook('AdminArticlePrepend'));

        La classe plxAdmin a une propriété qui contient tous les hooks sous forme de tableau. Plutôt que de faire cet eval sur du code par forcément maîtrisé, il suffit d'appeler une fonction de callback nommé. Regardez sur d'autres projets (drupal, dotclear, piwigo pour ceux que je connais) qui ont ces mécanisme de hook, ils ne font pas d'eval.

        la fonction eval n'est pas le mal absolu mais ce n'est pas la peine de l'utiliser quand on n'en a pas réellement besoin.

      • [^] # Re: Un très rapide petit tour dans les sources

        Posté par  (site web personnel, Mastodon) . Évalué à 2.

        Les eval, c'est le mal. d'une part parce que cela peut avoir un certain potentiel en terme de trou de sécurité :-p. Même la doc officielle le dit. Mais en plus, on ne profites pas du tout des optimisations faite par le moteur PHP : pas de cache d'opcode et j'en passe.

        Pour moi, l'utilisation de eval() est signe de problème d'architecture du code.. et de trous de sécu.

  • # XML ?

    Posté par  (site web personnel) . Évalué à 0.

    Le XML n'est pas un peu HasBeen de nos jours ?
    A l'heure des formats plus concis et rapide à parser (JSON, etc), le XML fait office d'éléphant à mon sens. Le XML était à la mode il y a 10 ans. Il me semble dommage d'avoir autant de contenu que de contenant et de stocker sur disque des fichiers au format humain alors qu'il n'est pas destiné à être édité à la main. Sans moteur de base de donnée (SQL ou non), j'imagine mal des recherches fulltext performantes.

    http://la-rache.com

    • [^] # Re: XML ?

      Posté par  (site web personnel) . Évalué à 5. Dernière modification le 12 août 2013 à 10:26.

      Je pense pour ma part que l'utilisation de XML n'est pas très appropriée pour les données d'un blog. En effet, qu'a-t-on ? Des articles, des mots-clefs, des catégories et des commentaires. Le plus efficace à mon avis :

      • un fichier par article, avec par exemple une structure à la RFC-822 dans le plus pur style de Debian pour stocker titre, chapo et corps ;
      • pour les catégories et mots-clefs : un répertoire à chaque fois, avec les articles liés dedans, et dans chaque article un champ indiquant ses catégories et mots-clefs ;
      • pour les commentaires : un fichier par article, éventuellement le même que celui de l'article lui-même, avec les commentaires ajoutés à la fin.

      Mais les auteurs de PluXml ont fait un choix un peu différent. Ça ne me dérange pas outre mesure, surtout compte tenu du fait qu'ils sont presque les seuls à avoir résisté à la basededonnite aiguë qui sévit dans le mont du ouaibe.

    • [^] # Re: XML ?

      Posté par  . Évalué à 3.

      Pourquoi stocker les articles en JSON sachant qu'il faudra de toute façon les reproduire en XHTML ?
      pour les fichiers de configuration à la rigueur, mais pour les données destinées à être affichées directement sur le site, comme les articles ou les commentaires, ça ne me semble pas être un choix déraisonnable.
      Après pour l'indexation, tout dépend du moteur choisi.

      • [^] # Re: XML ?

        Posté par  (site web personnel) . Évalué à 4. Dernière modification le 12 août 2013 à 10:30.

        Pour les articles, il faut tout de même un peu de structure externe, avant d'en faire des pages Web, puisqu'il faut pouvoir y identifier : le titre, la description et les mots-clefs — pour les mettre dans l'en-tête HTML —, le chapô — pour l'afficher sur les pages composites — et le corps.

        Donc du HTML, pourquoi pas, et c'est d'ailleurs ce qui est utilisé là où c'est pertinent, à savoir pour le chapô et le corps, mais dans une structure en JSON ou autre — système de fichier par exemple : un répertoire pour l'article et un fichier par composant ! —, c'est indispensable.

    • [^] # Re: XML ?

      Posté par  . Évalué à 5.

      Le XML n'est pas un peu HasBeen de nos jours ?

      Tout comme les trucs ressassés depuis 10 ans.

      A l'heure des formats plus concis et rapide à parser (JSON, etc), le XML fait office d'éléphant à mon sens.

      Sauf cas d'utilisation spécial la différence de vitesse est négligeable (et pas toujours en faveur de JSON) tout comme la taille finale. Dans tous les cas ce sont en général les API qui limitent la vitesse des parseurs, et un format custom et/ou binaire mets des ordres de grandeurs sur ces deux axes à JSON. Si ce sont des métriques pertinentes pour toi la question n'est pas XML vs JSON…

      Après chaque cas d'utilisation est spécifique et on choisira l'approche la plus adaptée en fonction des besoins précis, du contexte et de l’environnement. Mais si on peut éviter d'écrire les mêmes inepties depuis 10 ans c'est pas mal aussi.

      j'imagine mal des recherches fulltext performantes.

      J'ai aucune idée de l'implémentation de PluXml.

      Maintenant une DB c'est une très mauvaise solution pour de la recherche textuelle. Et en général vu le volume de données totalement négligeable que tu as dans un CMS tu as beaucoup de possibilité d'implémentations. Une bonne solution c'est une solution qui répond au cahier des charges, une excellente solution c'est une bonne solution qui en plus à une approche intelligente dans un contexte donné.

    • [^] # Re: XML ?

      Posté par  . Évalué à 1.

      En effet, tu imagines mal.
      Les recherches et tout le reste d'ailleurs fonctionnent du tonnerre. Il faudrait tester un peu avant de se faire une idée et dire n'importe quoi…

      La philosophie de PluXml n'est pas de développer des usines à gaz; simplement des sites avec une audience modérée.

  • # i18n?

    Posté par  (site web personnel) . Évalué à 1.

    Est-ce que pluxml est multilingue?

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

    • [^] # Re: i18n?

      Posté par  . Évalué à 3. Dernière modification le 12 août 2013 à 14:36.

      Dans la dépêche :

      Traduit en 10 langues (français, allemand, anglais, espagnol, italien, néerlandais, polonais, portugais, roumain, russe)

      et l'interface d'admin

      https://linuxfr.org/news/pluxml-5-2-le-cms-propulse-a-l-xml-est-de-sorti#comment-1476048

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: i18n?

        Posté par  (site web personnel) . Évalué à 4.

        La traduction du moteur de CMS est une chose, la possibilité d'avoir facilement du contenu multilingue c'est une autre histoire. L'utilisateur de Drupal que je suis en sait quelquechose!

        Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

  • # eXistDB

    Posté par  (site web personnel) . Évalué à -1.

    Est-ce que vous connaissez ou utilisez la base de données XML eXist (http://exist-db.org) ?

  • # publier un billet à une date de donnée

    Posté par  . Évalué à 0.

    Bonjour,
    Je me demandais s'il était possible de publier un article à une date ultérieure avec PluXml, je n'ai rien lu de tel dans les caractéristiques sur leur site internet.

    Merci,

    Axel

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.