5139 sujets

Le Bar du forum

Quel est votre CMS préféré ?










Pages :
(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.
Modérateur
Mouais, l'exemple dis juste que dans certains contextes echo ne peut pas être utilisé, pas l'inverse. La doc ne dis jamais, là utilisez plutôt echo ou plutôt print. C'est même plus clair d'utiliser (presque) toujours le même, comme on ne va pas dans un même code utiliser sizeof et count. Les deux sont restés pour des raisons historiques et de compatibilité. Personnelement j'utilise print parce que le terme me semble plus clair, que l'analogie aux effets acoustiques…

a écrit :
Oui elles ont les mêmes performances (ou presque)

Pas presque, les mêmes, actuellement c'est à 99% un alias, sauf que print retourne 1.

@jmlapam
j'aime bien les contradictions: je le trouve pas si mal propre <=> C'est jamais valide, il faut justement bidouiller

Bon tout ça c'est évidemment un débat sans fin. Pourquoi? Car le choix d'un CMS peut correspondre:
1) Aux besoin d'un site
2) Aux développement et éventuels besoins futur d'un site
3) Aux besoins d'un utilisateur delta (françois pignon se crée son site)
4) Aux besoins d'un utilisateur beta (Intégrateur crée un site en remplaçant le dev par le CMS)
5) Aux besoins d'un utilisateur alpha (le dev)
6) Aux différentes combinaisons des trois précédents.
7) Au workflow de travail de l'utilisateur/dev
8) À la philosophie de travail de l'utilisateur/dev
9) À des besoins de performances
10) À si on préfère utiliser echo ou print Smiley lol ( wordpress=echo vs drupal=print )
11) …

Et là dedans, rien n'est ni juste ni faux, et les différences sont très personnelles, dépendent de nos clients habituels etc.
Dans notre cas, wp ne correspond pas tout à fait toujours au point 1) rarement au 2) et pas du tout au 5-6-7-8-9.
Mais il est sûrement beaucoup plus adapté à d'autres situations…
Administrateur
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 Smiley decu ), 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 Smiley smile
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 Smiley cligne 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 !?
@Felipe. Pour avoir récupéré d'une autre agence un bon paquet de sites sous spip , les utilisateurs se débrouillent très bien avec la syntaxe de rédaction.

Sinon, je plussoie globalement ce que tu as dis. Même si on peut éviter php, c'est assez frustrant d'être bloqué face à la syntaxe de spip alors qu'on sait parfaitement l'écrire en php.

Le problème principal de Spip c'est sa communauté qui a disparu. C'est dommage car c'était vraiment un CMS révolutionnaire.
Modérateur
Effectivement, c'était le cas avec php<=3, print était moins performant. C'est pourquoi nombreux ont pris l'habitude de préférer echo. Moi aussi j'ai fait quelques tests pour être sûr et j'ai bien trouvé une égalité approximative. Faire des tests précis est très difficile et périlleux. Beaucoup de paramètres pouvant fausser les résultats. J'ai consulté plusieurs sites, donnant des résultats différents, beaucoup de méthodes douteuses, beaucoup de vieux articles, et beaucoup d'articles non datés et ne citant pas la version de php…
kustolovic a écrit :

@jmlapam
j'aime bien les contradictions: je le trouve pas si mal propre &lt;=&gt; C'est jamais valide, il faut justement bidouiller

Bon tout ça c'est évidemment un débat sans fin. Pourquoi? Car le choix d'un CMS peut correspondre:
1) Aux besoin d'un site
2) Aux développement et éventuels besoins futur d'un site
3) Aux besoins d'un utilisateur delta (françois pignon se crée son site)
4) Aux besoins d'un utilisateur beta (Intégrateur crée un site en remplaçant le dev par le CMS)
5) Aux besoins d'un utilisateur alpha (le dev)
6) Aux différentes combinaisons des trois précédents.
7) Au workflow de travail de l'utilisateur/dev
8) À la philosophie de travail de l'utilisateur/dev
9) À des besoins de performances
10) À si on préfère utiliser echo ou print Smiley lol ( wordpress=echo vs drupal=print )
11) …

Et là dedans, rien n'est ni juste ni faux, et les différences sont très personnelles, dépendent de nos clients habituels etc.
Dans notre cas, wp ne correspond pas tout à fait toujours au point 1) rarement au 2) et pas du tout au 5-6-7-8-9.
Mais il est sûrement beaucoup plus adapté à d'autres situations…



Tu as raison c'était plutôt contradictoire. Smiley confused .
Il est souvent dit qu'echo est préférable à print en PHP, je n'en ai jamais vraiment compris la raison à part "bonne pratique" qui est assez vague...

Seul le point 7 m’apparaît incontestable.

@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. En général je mets tout ce qui est bidouille (ou personnalisé c'est comme on veut) dans un fichier custom-functions.php que j'appelle dans le fichier principal. Pareil avec les scripts, widgets...etc
@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.
Felipe a écrit :
Ensuite si on est intégrateur, qu'on sait écrire du PHP (j'ai pas dit être développeur)


J'ai failli rire... mais...

Pourquoi si on est intégrateur on devrait voir et gérer des horreurs pareilles dans un template :


<title><?php
	/*
	 * Print the <title> tag based on what is being viewed.
	 */
	global $page, $paged;

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

	// Add the blog name.
	bloginfo( 'name' );

	// Add the blog description for the home/front page.
	$site_description = get_bloginfo( 'description', 'display' );
	if ( $site_description && ( is_home() || is_front_page() ) )
		echo " | $site_description";

	// Add a page number if necessary:
	if ( $paged >= 2 || $page >= 2 )
		echo ' | ' . sprintf( __( 'Page %s', 'twentyeleven' ), max( $paged, $page ) );

	?></title>


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


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


ou encore :


<title>{$title}</title>


Et tous les fichiers du template de Wordpress sont truffés de code PHP version années 90 dans le même style avec des traitements qui n'ont absolument rien à faire dans les fichiers de templates.
Modifié par jb_gfx (03 Jun 2012 - 23:51)
Modérateur
@jb_gfx +20000. Voilà bien le souci du templating wp. Un bon système de templating imprime des variables, à la limite gère quelques boucles simples et un ou deux if simples. Ainsi n'importe qui peut appréhender le template très facilement, ensuite on plonge progressivement dans du code pour personnaliser plus. Mais cela ne se fait pas dans un fichier de template.

@Olivier C
La prise en main hyper fastidieuse du templating. C'est tout sauf intuitif et bien pensé. Il est clair qu'une fois comprise, cette étape est moins gênante.
L'autre problème vient de la maîtrise. Si n veut pouvoir contrôler la sortie de manière précise, il faut très vite écrire des choses très moches. Pour le test je voulais changer le code html produit par un menu. Comment faire? réécrire un plugin qui gère des menus comme je le veux… En gros on n'a accès qu'à une petite partie du templating, et les lignes générales.
Administrateur
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 Smiley smile
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 Smiley confused )

jb_gfx a écrit :

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


&lt;title&gt;&lt;?=$title?&gt;&lt;/title&gt;


ou encore :


&lt;title&gt;{$title}&lt;/title&gt;


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-* Smiley smile
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.
Modérateur
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 ( Smiley eek Smiley eek )
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. Smiley biggol


$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. Smiley lol

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)
Modérateur
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 Smiley cligne ) 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 Smiley lol
# 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. Smiley smile
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 Smiley langue Smiley biggrin .
Modifié par jojaba (06 Jan 2013 - 16:20)
Modérateur
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 Smiley cligne
Pages :