[Bien discuté] Cms simple, ça existe encore ?

(reprise du message précédent)

kustolovic a écrit :
Oups, heureusement que je n'utilise pas php3 mais php5, cette assertion n'est plus valable depuis dix ans… echo et print ayant les même performances aux benchmarks, car lançant le même code derrière.

Oui elles ont les mêmes performances (ou presque), mais elles ne se comportent pas tout à fait de la même façon, regarde les dernières lignes de l'exemple #1 : http://www.php.net/manual/en/function.echo.php
Je ne cherche pas à prouver qu'il y en a une bonne et une mauvaise, juste que si on veut être précis dans l'utilisation de php, elles ne s'utilisent pas dans le même contexte.

WordPress est autant de la bidouille que PHP mais il n'est pas interdit de s'astreindre à un peu de rigueur personnelle et de se renseigner sur ce qu'il vaut mieux faire (ouais y a un fichier functions.php pour éviter de pourrir les autres fichiers d'un thème).
Un des points forts, c'est la facilité de prise en main par un client.
Ensuite si on est intégrateur, qu'on sait écrire du PHP (j'ai pas dit être développeur) et qu'on sait chercher sur le Net (et avoir 2 sous de jugeotte ou d'exigence qualité quand il s'agit de choisir des plugins), on arrive à faire beaucoup avec ce CMS.

Pour avoir testé SPIP, autant c'est idéal tant que l'on reste EXACTEMENT dans les clous prévus par défaut (et c'est en français, il parait qu'il y a des professionnels du web qui ont du mal avec la langue de l'informatique ), les boucles c'est puissant, le multilingue plutôt inégalé mais alors la syntaxe quand il s'agit d'enchaîner les [(IF)#|{'',' '}] (nan c'est pas exact mais ce n'est pas non plus une insulte du capitaine Haddock, ça existe vraiment ... en plus long, imbriqué et enchaîné), d'utiliser des variables, bref de pousser un peu, c'est un cauchemar. Les plugins sont ou pas mis à jour pour SPIP 2.0, 2.1 et 3.0. Et on finit par faire des fonctions PHP (ni mieux ni pire que functions.php pour WordPress) mais les plugins, faute de documentation ou d'exemple clair j'ai jamais vraiment compris par où commencer. Idem pour les formulaires CVT, mais c'est peut-être parce que ça venait juste de sortir avec SPIP 2.0, la doc n'était peut-être pas encore là ?
Et imposer la syntaxe de rédaction de SPIP à des clients ... ils ont autre chose à fiche de leurs journées, c'est notre boulot de leur proposer des RTE qui créent pas des paragraphes vides. Je veux bien que des pointilleux de la typographie française utilisent ce CMS, c'est une bonne chose mais l'imposer à tous par contre non. Du coup c'est plugin FCKEditor (j'espère qu'il y a un TinyMCE ou CKEditor maintenant).
EDIT: j'avais oublié "mettre une rubrique hors-ligne". Haha #oupas

Je préfère largement la souplesse de WordPress donc.
Les projets de nos clients ne justifient pas Drupal mais en tout cas j'ai pu observer de réels efforts de progression de l'accessibilité disséminés dans tout le projet, c'est 'achement bon signe de mon point de vue
Modifié par Felipe (30 May 2012 - 10:10)

@kustolovic : c'est vrai que c'est du pareil au même, j'aurais du m'abstenir pour la remarque Tous les CMS/Frameworks/Open-source que j'utilise préfèrent echo, donc c'est surtout une histoire de conventions. Au passage, puisqu'on en parlait, j'ai fait quelques tests de performances et j'arrive aux même résultats plus ou moins pour les deux méthodes (PHP 5.3.5). Par contre, j'ai trouvé plusieurs articles ici et là où des développeurs se sont prêtés au même exercice, et certains arrivent avec 20% de temps de traitement en moins avec le echo. J'ai pas le courage de tester avec plusieurs versions de PHP mais doit y avoir quelque chose avec ça !?

@kustolovic : J'ai bien lu tous les commentaires, mais je ne vois toujours pas où se posent les problèmes avec WP. Personnellement je développe les thèmes WP en les accompagnant d'un nombre très limité de plugins (genre WP super cache et smush.it). Après, il suffit de taper du PHP tout à fait standard et de le placer dans un fichier du thème (le seul PHP spécifique au CMS est à mettre dans functions.php, deux trois ancres pour appeler les header et footer, et les loops bien sûr). Je n'utilise pas toutes les fonctions d'appel du CMS, loin de là, je leur préfère du code plus classique. Je fais toujours comme cela et je me répète : je ne vois pas de problèmes particulier à cette pratique.

jmlapam a écrit :
C'est jamais valide, il faut justement bidouiller pour rendre un thème le plus valide possible, enfin ce qui est nécessaire.

Personnellement j'avais remarqué un soucis avec la fonction recherche (Pour obtenir la hierachie de titre voulue sur la balise <label>). Mais on se refait la fonction soi-même, on la place dans un fichier include et le tour est joué une bonne fois pour tous les thèmes que l'on produira par la suite.

jmlapam a écrit :
@felipe : je sais pas si c'est une bonne pratique en tout cas en terme d'organisation, je n'aime pas trop utiliser le functions.php à moins de partir vraiment de 0.

J'utilise le CMS mais pas le thème par défaut, j'aurais pu le préciser
L'intégration et la création du thème je les fais moi-même (rarement seul, entre l'auteur d'un livre sur WP3 chez Dunod, Mr Creativejuiz qui publie des tutos et dew, et jusqu'à récemment 0kk0 je suis bien entouré. Ouais en fait même quand l'info est pas facilement trouvable sur Google, j'ai quand même la bonne info grâce à eux, du coup mon utilisation de WP est peut-être pas si représentative que ça )

jb_gfx a écrit :

Plutôt que ce qu'on devrait logiquement avoir :

<title><?=$title?></title>

ou encore :

<title>{$title}</title>

Comme dit (maintenant), je jette le thème par défaut. C'est jamais assez accessible pour moi et j'ai pas besoin d'adapter un thème aux milliers de cas que peut avoir Automattic. J'ai un client ou un projet, pas besoin de l'usine à gaz Twenty-*
Donc oui, j'utilise autant que possible the_title() avec si nécessaire un test is_home() et rarement plus. Une fois il a fallu que je réunisse titre, image à la une et contenu d'une certaine façon en passant par une regexp mais c'était tout.

Le problème est que pour se passer de ces horreurs, il faut avoir un cas simple. Bien sûr c'est souvent le cas lors d'un travail sur un thème dédié, mais si on sort de ces cas, c'est vite le b… à intégrer des regexp dans un template ( )

Je donnais un exemple parmi d'autres, mais de toute façon les fonctions the_machin() c'est pas mieux :

the_ID() c'est quoi ? Un wrapper qui affiche le contenu de la fonction get_the_ID() qui elle même est un accès à une variable globale $ID (un paliatif au fait que le moteur est une usine à gaz)... je sais pas ce que le mec qui a codé ça avait fumé mais c'est sans aucun doute très puissant. Deux fonctions pour wrapper une simple variable. Et à ce moment pourquoi l'API est pas un peu plus claire ? get_machin() => renvoi des données, print_machin() affiche des données, etc.

Exporter une variable $id vers le template pour faire un simple echo $id c'était probablement trop compliqué...

Je reviens quand même sur mon exemple précédent, si on fait abstraction du fait que ce bout de code n'a rien à faire dans le template, ce qui choc c'est le manque de cohérence :

global $page, $paged;

D'abord il faut déclarer des variables globales (j'en ai utilisé une fois, c'était en 1998, un jeudi... il pleuvait). pour y avoir accès dans le thème. Pourquoi les variables utilisables dans un template ne sont pas exportées vers la vue après l’exécution du code métier et avant l'affichage ?

wp_title( '|', true, 'right' );

Là c'est presque de la cryptographie pour comprendre ce que fait cette fonction sans se reporter à la doc (et c'est impossible à mémoriser). A noter que cette fonction affiche aussi le séparateur : WTF ?!?

bloginfo( 'name' );

Récupère une info sur le blog, ok pourquoi pas... et l'AFFICHE... hein ??! Là aussi un print_bloginfo() aurait été beaucoup plus clair ou un echo bloginfo() mais certainement pas un mélange des deux. Mais en fait c'est encore un wrapper avec echo d'une autre fonction qui arrive juste après... Au passage on a de manière de nommé les fonctions, plus de underscore pour séparer les mots.

$site_description = get_bloginfo( 'description', 'display' );

Bon ben là on affiche plus directement comme précédemment mais on les récupère et on applique un filtre dessus. Tiens justement le filtre pour l'affichage aurait du être dans la fonction d'affichage (bloginfo()), mais non il est dans la fonction parente (le développeur revenait juste de son voyage en Jamaïque). Au passage le underscore dans le nom de la fonction est de retour mais seulement pour le premier mot...

Et puis ça continue :

if ( $site_description && ( is_home() || is_front_page() ) )
  echo " | $site_description";

Alors là c'est presque explicite mais tiens, pourquoi maintenant le séparateur est affiché par un echo plutôt que par une fonction comme précédemment ?

Et le meilleur pour la fin :

if ( $paged >= 2 || $page >= 2 )
  echo ' | ' . sprintf( __( 'Page %s', 'twentyeleven' ), max( $paged, $page ) );

Bon ben là rien à dire, l'intégrateur se flingue direct.

Bon par contre j'avoue que la partie interface d'administration est relativement user friendly par rapport à pas mal de CMS (du moment qu'on le surcharge pas de plugins) et c'est sans aucun doute ce qui fait la popularité et la force de Wordpress. Mais côté développement c'est juste une ignominie.
Modifié par jb_gfx (04 Jun 2012 - 18:54)

Bonjour à tous,

Quel discussion ! Bon, bien entendu, comme dans toute discussion, on a eu pas mal de hors-sujets, mais ceci est le lot de toute discussion, ne pensez-vous pas ?
Comme les discussions se sont interrompues, je vais tenter de faire, comme promis, une petite synthèse de ce topic vraiment très instructif.

Le vote
Le grand gagnant est... Wordpress ! Autres enseignements de ce vote, en seconde position on trouve "autres cms", certains d'entre vous utilisent un CMS "made myself" pour pouvoir parfaitement contrôler l'outil. Enfin, SPIP semble également sortir son épingle du jeu (3e) ; d'après les messages sur ce CMS, c'est un cms qui est accessible à tous (même aux amateurs) mais qui demande l'apprentissage d'une syntaxe "spéciale" pour la confection des squelettes (template) et est limité dès que l'on veut modifier les templates de manière plus avancée.

Résumé de la discussion
Dans un premier temps, il a été question de la définition du mot "simple". En effet, qu'est-ce qui était entendu par CMS "simple" ? Simple à utiliser (par le développeur ? par l'utilisateur ?), simple à modifier (par le développpeur ? par l'utilisateur ?), simple à comprendre,...
Une remarque intéressante : il faut prendre le temps de bien maîtriser l'outil afin de gagner du temps en développement plus tard (philosophie à long terme). Autre remarque : un CMS "complexe" (c'est à dire proposant beaucoup de fonctionnalités annexes) peut très bien être utilisé pour un site simple.
S'en est suivi une discussion sur Wordpress qui est considéré par beaucoup d'entre vous (mais pas par tous ) comme une bonne solution de création de sites simples et même professionnels. Les avantages : beaucoup de modules "prêts à l'emploi", une communauté active, une interface d'administration facile à prendre en main,.... Les points négatifs : un langage de templating (pour modifier les gabarits) assez lourd (les fonctions à utiliser peuvent paraître complexes), l'aide en ligne limitée lorsqu'on se lance dans des fonctionnalités plus évoluées, la gestion des utilisateurs trop simpliste, ...

Les CMS dont il était question

Des CMS "simples" (d'après les intervenants) :
# Dotclear
# blogotext
# cmsmadesimple
# cmsimple-xh
# artiphp
# PluXml
# ZitePLUS
# GuppY
# concrete5
# 99Ko

Des CMS en Ruby
# radiant cms
# refinery
# locomotive

Des CMS plus connus dont il était question dans la discussion
# WordPress Francophone
# Drupal France et francophonie
# SPIP - français

Ceci est et reste une synthèse, beaucoup d'autres choses ont été dites...
Merci à tous ceux qui ont participé aux débats.
Il ne me reste plus qu'à vous encourager à faire la promotion de votre CMS favori sur Alsacreations (en proposant un article par exemple), je pense que c'est un bon moyen d'étayer vos propos .
Modifié par jojaba (06 Jan 2013 - 16:20)

Un petit nouveau (en tout cas, je ne connaissais pas) : 99Ko
Je l'ai découvert grâce à "La ferme du Web" qui a twitté à ce sujet.
PHP 5.2 requis. Données stockées dans des fichiers .json. Rudimentaire mais peut être utile pour de "petits" projets.
Modifié par jojaba (04 Oct 2012 - 14:07)

jojaba a écrit :
Un petit nouveau (en tout cas, je ne connaissais pas) : 99Ko
Je l'ai découvert grâce à &quot;La ferme du Web&quot; qui a twitté à ce sujet.
PHP 5.2 requis. Données stockées dans des fichiers .json. Rudimentaire mais peut être utile pour de &quot;petits&quot; projets.

Et le développeur de 99ko à fait une partie de son apprentissage dans les articles d'alsacréations