-
C’est cool de nous rappeler qu’il y a autre chose que WordPress en CMS PHP. En plus, il s’agit là d’un projet qui a su se maintenir dans le temps. Pas du nouveau venu qui aura disparu dans 6 mois.
-
Salut, oui c’est top. Il a y a pleins de CMS sur le Web, je cherchais des projets Francophone et franchement PluXml a su me séduire aussi bien que PHPboost qui est un poile plus poussé mais je recommande les deux les yeux fermés surtout qu’aussi bien l’un que l’autre la communauté sur leur forum respectifs sont super actifs.
-
Je ne connaissais pas PHPboost en revanche. C’est toujours la même chose, quand on est confortable avec un outil on l’utilise à tout va. Pour l’un comme pour l’autre, y’a moyen de modifier la logique du code sans justement modifier le cœur du CMS et donc que tout soit écrasé à la moindre update ?
-
Sur PHPboost c’est plus compliqué de modifier la logique des codes. Tant qu’il n’y a pas de màj majeur du coeur du CMS. Par exemple actuellement j’étais entrain de voir pour modifier l’obligation aux visiteurs de laisser leur mail pour commenter mais sur le forum phpboost on ma vivement conseiller d’attendre la sortie de la version 6 qui est imminente pour pas avoir de soucis sur mes modifs.
Ce que j’ai trouver sympa c’est que l’un des développeurs à récupérer ma requête de modification pour l’inclure nativement dans la version 6 donc pas besoin pour moi de modifier quoi que ce soit et je trouve ça cool. Une équipe réactive et accessible.
PluXml par contre tu peux modifier tout ce que tu veux ça ne changera quasiment rien entre chaque màj.
-
Plus de simplicité en s’épargnant un système d’héritage parfois complexe (les hooks à la WordPress ça part parfois dans tous les sens), mais ça limite un peu. Ou alors faut figer le code dans une version, car devoir refaire à chaque upgrade, c’est assez contraignant.
Pour l’équipe de dev à l’écoute, ça c’est vraiment cool. Et ok pour PluXml. En revanche, les fichiers en XML, je préfère ne pas avoir à y toucher, c’est relou à lire et encore plus à parser je trouve. Faudrait le renommer en PluJSON :)
-
-
-
-
-
Les sites en lien de l’exemple en bas de la page ça craint carrément :
-
Bonjour kikinovak,
Mes opinions politique n’engage que moi, à aucuns moment je ne viens agresser personne, si ? C’est mon blog personnel traitant de divers sujets autour des jeux vidéo, des logiciels libre, de l’informatique, de la politique et de tout ce qui me passe par la tête.
Si ça ne vous plait pas alors ne venez tout simplement plus, je n’ai rien fais de mal.
A bon entendeur ^^
-
-
Je ne vois pas le rapport avec le contenu de l’article.
-
-
Merci pour la soumission Cascador :-)
-
Merci pour le partage. Je reste par contre sur ma faim, l’article indique juste que plus d’applications sont installées par défaut sur /e/os que sur grapheneOS. Je ne vois pas le lien avec la confidentialité. GrepheneOS est plus connu pour sa sécurité (d’où le peu d’applications fournies par défaut), et réalise des compromis en terme de confidentialité avec Google (notamment les sandbox via leur Google play). e/os est probablement plus accessible et s’éloigne de Google, alors que grapheneOS recherche la sécurité avant tout. Tout une histoire de compromis :)
Salut tifriis désolé je n’avais pas vu ton commentaire. Je reconnais que j’aurais dû approfondir cet article. En effet GrapheneOS est trop axé sécurité pour moi, étant un utilisateur lambda je me sentais pas concerné de rester sur un OS aussi épuré et sécurisé.
Je n’ai pas tester CalyxOS et je n’avais plus trop le temps de faire l’essai, à chaque fois c’est mon téléphone perso qui prend un claque et c’est un bordel sans nom de retrouver des messages ou numéro perdu de mes clients lol.