8768 sujets

Développement web côté serveur, CMS

Bonjour bonjour!

Je cherche à créer un petit site sans prétention (page de présentation, contact et peut-être news), avant de me lancer je cherche toutes les solutions disponibles.

J'ai trouvé deux cms, http://zwiicms.com et http://www.giausserand.fr, les deux m'ont l'air top, par contre j'ai peur que le second ne soit plus maintenu Smiley ohwell .

Connaissez vous d'autres cms susceptibles de m'intéresser ?

Merci à vous Smiley biggrin .
Modifié par Darkborder (11 Feb 2016 - 10:20)
Super merci dew, je vais tester ça.
Si vous en avez d'autres n’hésitez pas, je trouve le concept du flatfile juste génial!
Il y a longtemps j'avais vu passer un truc qui s'appelle "Plume". Il me semble qu'il était très léger et sans BDD. A voir...
@hchtot ah oui je viens de le trouver par contre la dernière maj remonte à 8 ans mais je vais quand même me plonger un peu dedans, merci!
Modérateur
Salut,

J'ai pas mal utilisé CMS Made Simple à une époque. Il est pas mal et assez flexible.
Par contre maintenant j'utilise plutôt du WordPress, c'est un gros tank souvent pour un petit site mais je le trouve plutôt bien fait pour que les novices gèrent leur site et niveau ressources / support on est servi.

Bonne journée
Salut _laurent,

Merci pour CMS Made Simple, par contre je n'ai jamais réussi à accrocher à WordPress peut être par manque de motivation ou peut être l'aspect usine à gaz qui me repousse...
Modifié par Darkborder (11 Feb 2016 - 11:23)
Modérateur
Darkborder a écrit :
je n'ai jamais réussi à accrocher à WordPress peut être par manque de motivation ou peut être l'aspect usine à gaz qui me repousse...

Pour tout avouer au début je crachais méchamment dessus. Carrément a cause de l'aspect usine a gaz et lent etc... C'est pour ca que je suis parti sur une solution plus légère comme CMSMS (j'avais réfléchi a PlumeXML aussi).
Au final un projet m'a poussé à développer un thème WP sur mesure et ça m'a fait changé d'avis. C'était vraiment plus confortable de développer, sans parler des ressources (ya des plugins déjà fait pour à peut près tout pour gagner pas mal de temps) et du support (j'ai ramé quelques soirées pour déboguer des trucs con sous CMSMS...). Et coté admin CMSMS était pas génial génial de souvenir... pas très beau / simple et du coup les gens avait du mal à s'y mettre.

Après je ne connais pas tout les autre CMS cité plus haut, mais c'est pas pour rien que WP est un des plus connu...

Pour mon blog perso ou un truc qui me tiens à cœur et que je gère, c'est une autre histoire, j'y réfléchi un peu plus (quoi que..) mais pour un client noob qui veux une administration totale, je cherche plus. Smiley smile
Effectivement de cet angle je comprend l'avantage de WordPress, en final j'ai l'impression que l'abondance de ressources et sa flexibilité en font presque une Framework, je dit bien presque Smiley rolleyes .
Enfin, tu m'as convaincu je prendrais du temps pour me plonger dans la conception d'un site de test, Wordpress pourrait m'être utile pour du dev rapide, à l'heure actuelle j'utilise un framework maison pour mes devs mais avec du temps et de la patience WP pourrait-être un bon gain de temps.
Pour compléter ce qui vient d'être dit précédemment à propos de WordPress, il se trouve que viens de le télécharger et installer en local chez moi pas plus tard qu'hier soir, histoire de me faire une idée plus précise de l'engin.
Première impression sur l'installation : Plutôt rapide et simple, du moins pour qui sait ce qu'est une base de donnée et l'a créée / configurée avant.
Interface utilisateur pour l'administration du site : assez intuitive.
Code HTML généré : peut mieux faire (en gros, ne m'a pas convaincu du tout, même si les "pros" et/ou "addicts" du CMS trouveront ce jugement infondé et le résultat d'une méconnaissance évidente du produit...).
De fait, ma première impression est celle que connaît tout développeur face à une environnement à base de plugins et extensions : certes, il y a pléthore d'outils disponibles mais séparer les bons des moins bons, voire des "foireux" relève de l'art divinatoire, sauf à les tester un par un pour un besoin donné.
La même problématique existe en Java avec l'EDI Eclipse pour lequel les extensions de comptent en centaines (de mémoire, il me semble avoir vu mentionné plus de 2300 plugins lors de l'installation de WordPress... une vraie Tour de Babel).
Le second point qui me paraît devoir être pris en compte est le recours systématique de ce type de CMS à un SGBD. La plupart du temps ceci induit des coûts / risques inutiles (installation, configuration, évolution), sauf à vouloir gonfler un devis pour le rendre crédible.
Ne rigolez pas sur ce dernier point car on croise ce genre de raisonnement dans le milieu professionnel (le syndrome "Pas assez cher mon fils" pour ceux qui ont connu les pubs des années 70).
Bref, je ne dis pas que WorPress et consorts doivent de facto disparaître du paysage, mais ils sont (très) loin d'être une solution efficace dans la majorité des cas.
Je suis en train de refondre les classes Java de mon générateur, notamment pour pouvoir opérer des comparaisons entre accès SGBD et accès fichiers plats.
Par expérience, les seconds peuvent largement dominer les premiers lorsque la volumétrie n'est pas trop importante et que les besoins en matière de recherches sont limités.
RDV dans quelques temps pour en reparler...
Avec WordPress je génére EXACTEMENT le html que je souhaite. Tout dépend de la manière dont on configure ses thèmes et plugins.
Olivier C a écrit :
Avec WordPress je génére EXACTEMENT le html que je souhaite. Tout dépend de la manière dont on configure ses thèmes et plugins.

Effectivement...
Ceci dit, j'ai sous les yeux le Codex WordPress traitant de l'ajout de balises Meta personnalisées (je note au passage, dixit ledit Codex, que certaines de ces balises ne sont pas générées en standard... requérant une intervention manuelle ou un plugin spécialisé dans ce type de manipulation).
En lisant les explications fournies par le Codex WirdPress sur le sujet (ajout de la Meta sous la balise Title dans le Header.php) je me dis que tout ceci relève de la contorsion pour une partie Head de la page HTML qui n'en demandait pas tant.
Alors, certes, on peut tout faire, comme dans la plupart des langages et environnements.
La seule question reste : est-ce que c'est facile et est-ce que c'est fiable?
Passer par des plugins pour ce genre d'opération, comme le mentionne le Codex, me semble une surcouche inutile et un ajout de code pouvant être source d'erreur et de blocage.
Ceci dit, la même problématique existe ailleurs que sous WirdPress et je ne fais pas une fixation sur le produit qui, je l'indiquais, correspond à un certain type de besoins.
@sepecat : Avec WordPress il faut partir du principe que deux fichiers seulement sont obligatoires pour créer un thème WordPress : le fichier style.css et... un fichier index.php. Un point c'est tout.

Le fichier style.css, avec son entête spécifique de commentaires, sert à faire reconnaitre le dossier comme un thème WordPress :
/*!
Theme Name: Scriptura
Theme URI:  https://github.com/Scriptura/ScripturaTheme
 
Author: Olivier C
Author URI:  https://scriptura.github.io/
 
Description: Interface for web apps
Version: 0.0.0
License: ISC
License URI:  http://www.gnu.org/licenses/license-list.html#ISC
 
Tags: flexbox
Text Domain: Scriptura
*/


Tout le reste c'est de l'optionnel : on peut par la suite complexifier à loisir son thème en fonction de ses besoins...

Donc, si l'on a envie de coder un truc directement dans une page (des metas par exemple) rien ne l'empêche. De même rien ne nous oblige à utiliser telle ou telle fonction de WordPress.

C'est comme pour la plupart des CMS ou des frameworks php : il s'agit avant tout de conventions de code, on n'est pas obligé de les respecter.
Modifié par Olivier C (11 Feb 2016 - 18:10)
Olivier C a écrit :
@sepecat : Avec WordPress il faut partir du principe que deux fichiers seulement sont obligatoires pour créer un thème WordPress : le fichier style.css et... un fichier index.php. Un point c'est tout.

Certes... mais quelles contraintes !!!
Si j'en crois le (Codex WordPress), voici les spécifications en matière de "File header", reportées ici in extenso :

- Header are written in a block in the beginning of a PHP or CSS file.
- A block might be placed in a files comment, like a PHP or CSS comment.
- The whole header block must be placed inside the first 8 192 bytes of the file.
- Headers follow up to each other, one on it's own line.
- A header consists of a name and a value.
- Name and value are separated by the ':' character.
- The name has a minimum of one, and a maximum of three words.
- The minimum length of a word is three, the maximum length is 12 characters.
- A word consists of the characters a-z and A-Z.
- Words are separated by a single space (d32/x20)
- A name starts after the beginning of a line or after a whitespace character.
- A name ends before the ':' character.
- A value starts after the ':' character.
- Sometimes the ':' character is suffixed by a space. This space is considered to not be part of the value.
- A header-value can contain any characters but not a newline.
- Header values might become filtered before they are used.
- Header values can but must not contain HTML code in form of certain XHTML Elements or HTML Tags.

Autant de sources d'erreurs potentielles, et nous n'en sommes qu'à deux fichiers...
En toute honêteté, ceci n'est pas propre à WordPress et d'autres langages / environnements ont ce type de contraintes.
Juste par expérience, j'ai suffisamment vu de logiciels développés en Java "planter" au seul motif que l'une des lignes d'un fichier ".properties" se terminait par un caractère " " après le "\" censé initier un retour à la ligne suivante, pour considérer aujourd'hui que ces contraintes sont rédhibitoires.
Dans le meilleur des cas, celui qui doit déboguer a déjà rencontré le problème et sait le régler, dans le pire des cas, vu le "turn over" des équipes, on aura un petit nouveau qui passera une journée entière à chercher, avant de s'apercevoir qu'un simple " ", bin ça ne se voit pas à l'écran mais ça pose problème car les spécifications ne prévoient pas son existence.
Une autre page du Codex précise par ailleurs (en gras, pour bien attirer l'attention) que :
No two Themes are allowed to have the same details listed in their comment headers
Ceci me paraît une autre source d'erreur potentielle, nécessitant une attention permanente de la part du concepteur du site pour éviter que deux ressources n'empiètent l'une sur l'autre.
Sur un portail d'une dizaine de pages, ce n'est pas insurmontable. Pour un site institutionnel d'une centaine de pages, cela devient un peu plus compliqué. Un copier / coller intempestif est si vite arrivé... et oublié.
Après avoir installé WordPress hier soir, j'ai dans le même temps aussi visionné un tutoriel en ligne, fort intéressant, sur la création de thème avec ce CMS (durée 2 H 49 mn, pour les plus courageux...).
En général, j'aime bien approfondir les choses.
Pour ce soir, ce sera probablement installation du Drupal, histoire de varier les réjouissances et comparer in situ.
Les observations ci-dessus se bornent à être objectives et tirées de la documentation officielle. Je n'ai aucun grief particulier contre WordPress et ceux qui en vivent / s'en amusent. Par contre, je considère que l'environnement correspondant offre (comme Drupal et autres...) une fausse idée de simplicité, occultant l'envers du décors.
C'est tout aussi vrai d'autres langages...
Faire son premier programme "Hello world" en Java ne prend que 5 mn. Ecrire une application SWT / Web dans son intégralité requiert un autre niveau et une bonne connaissance des petits "pièges" cachés au détour des fichiers de configuration, par exemple.
sepecat a écrit :
Certes... mais quelles contraintes !!!
Si j'en crois le (Codex WordPress), voici les spécifications en matière de "File header", reportées ici in extenso

Oui, mais dans la pratique il suffit de faire le copier coller de l'entête d'un thème de référence et on l'a notre entête, il suffit de la personnaliser, avec nos propre metas.

Et à ce propos je m'autorise beaucoup de choses. Par exemple tous mes fichiers sont écrits en CamelCase (à l'exeption de style.css qui pose problème dans ce cas), ce qui n'est pas une norme sur WordPress. De même, pour faire correspondre mes annotations perso avec celle que l'on trouve sur WordPress j'ajoute en réalité des arobases (je vous en avais fait grâce dans un post précédent), et cela ne pose aucun problème :
/*!
@Theme Name: Scriptura
@Theme URI:  https://github.com/Scriptura/ScripturaTheme
 
@Author: Olivier C
@Author URI:  https://scriptura.github.io/
 
@Description: Interface for web apps
@Version: 0.0.0
@License: ISC
@License URI:  http://www.gnu.org/licenses/license-list.html#ISC
 
@Tags: flexbox
@Text Domain: Scriptura
*/


Pour dire : je code mes thèmes WordPress en annotation Jade, ce qui selon certains était tenu pour impossible. En fait tout est possible du moment que l'on maitrise son sujet.

Voici par exemple la tête de mon template Jade pour les articles (Single.php.jade) :
extends PatternLayouts

append variables
  _require_wp Functions/SingleVariables

append functions
  _require_wp Functions/Breadcrumb

block breadcrumb
  _php $breadcrumb

block content
  article.article(itemscope itemtype='https://schema.org/Article')
    | {% $image %}
    #index-article
      .wrap
        .grid.print-area
          .m12
            h1.h3 {% $name %}
          .grid6.sizeS-grid12
            .adddropcap.links(itemprop='articleBody') {% $content %}
            include Includes/Buttons
          aside.m6.sizeS-m12
            include Includes/Sidebar

block comments
  .ajax-window-comments

block aside
  include Includes/Relationship

Ce code est ensuite généré en php via Gulp dans le fichier Single.php.

Donc rien à voir avec WordPress a priori, et pourtant... c'est du WordPress...
Modifié par Olivier C (12 Feb 2016 - 08:20)
Bonjour,

Je me permets de m’insérer dans le sujet.

Les beaux-parents d'une copine ont un site pour une petite activité, avec un hébergeur peu réceptif, et ils ne sont pas non plus très technologique (c'est un euphémisme Smiley langue ). Donc je leur avais fait une bonne vieille page en HTML5 responsive et tout, design moderne scroll, mais modifiable avec un minimum de connaissance technique comme se connecter en FTP, éditer en HTML ;D

Pour qu'ils soient plus autonomes, je voudrais quand même leur mettre un CMS. Mon problème : pas de bases de données, mais surtout du PHP 4.4.9 ! Tous les CMS valables actuels nécessitent au moins du PHP 5.

Auriez-vous une idée ou un souvenir d'un vieux CMS qui marchait bien sous un vieux PHP, que je puis coupler avec un design moderne ?

Merci !