Contenu principal

Pourquoi WordPress n’est pas un CMS

07 Mai 2014

Le 6 mai 2014 se tenait à Toulouse un 3ème meetup sur différents sujet, dont « Pourquoi WordPress n’est pas un CMS » par Thomas Gasc.

C’est de ça que je souhaite parler, moi qui n’ai pas pu être présent, je n’ai eu que des tweets lus sur #wptls et les slides de cette présentation.

J’aimerai alors revenir sur différents points car, j’ai besoin, vraiment besoin d’en savoir plus, de connaitre l’argumentaire complet. Les 140 caractères de twitter et le slides façon Charlie ça ne me parle pas assez…

J’invite donc toutes les personnes présentes à ce meetup à venir commenter et argumenter cette présentation et aussi surtout @methylbro lui même car personne de mieux que lui ne saura m’expliquer sa façon de penser.

Mon premier choc épileptique

J’ai vu passer une liste de tweets qui n’avaient, pour moi, que pour but de casser WordPress. J’avoue qu’en 140 caractères il est difficile d’être constructif, mais lâchés comme ça sans contexte… c’est super brutal et je ne suis pas le seul à le penser.

Voici la liste de ce que j’ai lu et qui m’a provoqué mon premier mal comitial :

#1

C’est vrai, il y a 10 ans WordPress servait à faire des blogs. C’est comme dire que les téléphones d’il y a 10 ans ne servaient pas encore à faire des achats sur le net, c’est vrai et voilà, merci.

#2

C’est vrai, WordPress a plein de variables globales partout. Les 2 hashtags vont devoir m’être expliqués. En quoi n’est-ce « pas beau, berk » ? Merci.

#3

Pas de vraies relation entre les types de contenus. On parle ici des Custom Post Types je pense. C’est aussi vrai, il n’y a pas, de base dans WordPress de relation entre ces types de contenus.

Ma question est : doit-il y avoir une ou plusieurs relations entre ces types dans WordPress de base ? Pourquoi ? Pour qui ? Et quelles utilisations ?  Merci.

Il existe un plugin qui permet de le faire, c’est Posts 2 Posts. Si WordPress ne le fait pas, les plugins sont là pour ça !

#4

Sachant que je suis consultant en sécurité web et connaissant plutôt bien le développement WordPress, j’aimerais savoir comment on peut éviter de laisser la possibilité de créer volontairement des vulnérabilités grâce à des plugins qui ne sont donc bel et bien que des scripts maison provenant de monsieur Toutlemonde qui seront inclus à la volée dans le core même de WordPress.

Et, comment font les autres CMS et Frameworks ? Je vois que l’orateur est un développeur Symfony, comment ça marche là ? Pas de hooks, non ? C’est un Framework et non un CMS, le public n’est pas le même.

Puis, ne serait-ce pas contre productif de chercher à bloquer ça ?

Néanmoins, même si des failles existent dans les plugins, elles sont là la plupart du temps de façon involontaire. Les plugins volontairement malicieux existent et sont le plus souvent des plugins payants que vous trouverez sur votre moteur de recherche préféré (évitez les…).

Un plugin qui serait volontairement malicieux sur le repository officiel se fait supprimer trèèèès rapidement car la communauté veille au grain :

De rien ;)

#5

C’est aussi vrai, il y a beaucoup de « SELECT count(*) » par exemple, et de requêtes qui datent. C’est aussi pour cela que WordPress est en évolution constante et qu’une communauté mondiale fait modifier le code du core pour proposer des améliorations. Parfois, comme ici, Greg crée lui même du code pour gagner en performances.

Ce ne sont pas que des nouvelles fonctionnalités (parfois discutables) qui sont proposées et ajoutées, mais aussi et souvent des améliorations inconnues du grand public. A moins de suivre le trac ticket par ticket comme moi, vous ne savez pas ce qui se passe sous le capot.

Vous trouvez que les requêtes sont mal faites ? Proposez alors une amélioration ! Merci d’avance.

#6

Il est impossible et inutile de reprendre à zéro tout CMS, Framework etc. Ce n’est pas et ne sera jamais une solution.

Les outils ont de l’âge, et on les améliore au fur à mesure. Il est tout aussi impossible d’être autant « à jour » avec PHP pour ces outils. Il ne faut pas oublier que WordPress, Joomla!, Drupal (7) gèrent une grosse rétro-compatibilité jusqu’à PHP 5.2.x.

Et puis, si on reprenait tout à zéro, on partirait vers quoi, et combien de temps mettrait-on à revenir au même résultat ? Serait-on déjà à jour ? Rétro-compatible ?

#7

Ça, c’est juste pour troller. Pour imager sans relation aucune, je vais dire « La Merco est une meilleure voiture qu’un Piaggio » (désolé pour les marques citées au hasard, désolé pour ma rime plate pourrie).

Comment comparer un Framework à un CMS et dire que l’un est mieux que l’autre, qu’on explique, je tellement sur vous… Je clair Luc, ne pas ?

#8

Les metadatas datent vraiment et n’ont effectivement pas suivi les logiques de réflexions qu’a subit WordPress. Mais si tout va bien, WordPress 4.0 ou 4.1 devrait inclure une toute nouvelle gestion de ces metadonnées, wait and see.

#9

Suivre les versions de PHP serait difficile et encore une fois contre productif. Il faut écouter ses utilisateurs et c’est ce que font les CMS.

Entre nous PHP c’est bien mais c’est pas non plus LE langage parfait… rien que la nomenclature des noms de fonctions et l’ordre des paramètres sont déjà une prise de tête…

Alors, comment expliquer qu’un produit has been continue d’évoluer, de rassembler de plus en plus de monde, qu’il représente plus de 21% des sites web mondiaux, je ne me l’explique pas.

Cette obsolescence ne ressemblerait-elle pas à celle des voitures, qui n’ont pas évoluées comme les gens l’avaient prévus avec des volantes et sous-marines ? Pourtant, les voitures sont meilleures qu’avant tout de même…

Et ça glisse…

Parlons maintenant des slides auxquelles il me manques les mots.

#1 Do not use it on your websites

donotuseit

Ça commence direct avec du brutal, c’est même déjà la réponse, la conclusion et on est sur la slide 1.

#4 WordPress is shit!

shit

Et une attaque gratuite, une. Brutale, sans le son c’est horrible. Entendre ça dans une conf, lâchée comme ça ne me donne pas d’autre envie que de me sauver par la fenêtre du 10ème étage. Quel était le son associé à cette slide ?

#6 wp-content/themes/

loop

Je lis un « as it should be » euh should should… pourquoi il faudrait un foreach plutôt qu’un while ?

N’oublions pas qu’un thème n’est que du front-end, et la façon de faire une boucle est là encore relative !

Démo avec TwentyTen et sa boucle while transformée pour l’occasion en foreach pour te faire plaisir :

Avant, avec while

<?php
while ( have_posts() ) {
	the_post();
	the_title();
}

Après, avec foreach

<?php
$posts = $GLOBALS['wp_query']->posts;
filter_posts( $posts );
foreach ( $posts as $post ) {
	the_post();
	echo $post->title
}

Pour que tu puisses afficher le « title », il te faut l’avoir traité avec les filtres WordPress. Y avais-tu pensé ? Il te manque un morceau de fonction pour expliquer comment tu te passes de celle de WordPress.

<?php
function filter_posts( &$posts ) {
	if ( $posts ) {
		foreach ( $posts as $k => $_post ) {
			$posts[ $k ]->title = apply_filters( 'the_title', $_post->post_title );
		}
	}
	return $posts;
}

Donc c’est tout à fait faisable, libre à toi de coder ton thème de cette façon si ça te plait.

#8 wp-includes/meta.php

metadata

C’est cette slide qui est relative au point #3 des tweets. Tu détournes l’utilisation des métadonnées des articles pour créer une relation incomplète afin de pouvoir prouver que c’est mal codé. Honteux monsieur !

Une métadonnée d’article est une donnée relative à cet article, point. Si tu décides de lier manuellement un article à un autre avec ton code, alors à toi aussi de le délier manuellement, quoi de plus logique ! Comment veux-tu que WordPress devine que tu souhaites aussi supprimer la liaison entre ces 2 données ?

Allez, je suis cool, je te donne le code :

Ici pour le cas des articles mis en corbeille

add_action( 'transition_post_status', 'break_transition_trash', 10, 3 );
function break_transition_trash( $new_status, $old_status, $post ) {
	if ( 'trash' == $new_status ) {
		delete_post_meta( $post->ID, 'next_post' );
	}
}

Ici pour la suppression définitive

add_action( 'deleted_post', 'break_relation_delete' );
function break_relation_delete( $postid ) {
	delete_post_meta( $postid, 'next_post' );
}

Ceci ressemble fortement à la suppression en cascade de SQL non ?

Là maintenant le développement est déjà plus complet.

#10 wp-includes/plugin.php

plugins

Je lis « how plugins should works » (-s). Encore une fois, should should… Pourquoi devoir créer une classe étendue d’une classe Footer pour qu’un plugin puisse faire son travail ? A quoi sert cette instance de mon FooterPlugin une fois hooké ?

Ne trouvez-vous pas que le code de droite est plus pompeux et long à appréhender pour un débutant ? J’avoue que moi aussi, je préfère le code actuel…

#12 wp-includes/class-wp.php

Sans le son, j’ai besoin de savoir de quoi ça parlait ici, merci.

#14 wp-includes/class-wp.php

wtfparam

Le commentaire « not even passed as parameter ?? WTF ?! » montre ici que la façon dont WordPress utilise les filtres et les globales n’est pas comprise. Je ne dis pas qu’il n’y a pas mieux, je ne dis pas que c’est LA bonne façon.

Ce qui est sûr c’est que si on passe ça en paramètre, alors je ne pourrais plus y toucher, la lire etc. C’est peut-être le but recherché quand je lis les tweets, à confirmer, merci.

#17 All these things are in Drupal 8

drupal

Oui et ? C’est un argument contre WordPress car WordPress ne l’a pas ? Tu préfères alors Drupal ? Ok, mais c’est étrange de reprocher ce genre de chose, dis nous plutôt (et peut-être l’as tu dit en live) pourquoi c’est mieux et pourquoi WordPress devrait aussi utiliser ça. Merci

#18 Use cool tools

git

On passe un peu hors sujet ou je me trompe ? Avec WordPress aussi on peut utiliser un terminal grâce à WP-CLI, on peut installer des plugins et versionner via Git. Quel intérêt sur le sujet cette slide ? Merci.

#19 More powerful than WordPress template

templates

Pareil, explique un peu pourquoi, quels avantages et quelles différences car WordPress a un éditeur d’images, utilise du CSS (SASS ou LESS en court d’étude) et a son propre moteur de template. Merci.

#20 More powerful then WordPress plugins

composer

Encore, pourquoi c’est plus puissant ? C’est pas un peu bourrin d’utiliser Composer pour faire un plugin ??

#21 Conclusion

D’accord ! Il faut coder, en ce que vous voulez d’ailleurs, mais codez ! WordPress , Joomla!, Drupal, Zend, Composer, Symfony, et autres joyeusetés.

Outro

Je trouve ça un peu étrange, même si ça parait ouvert, d’inviter un développeur Symfony venir lâcher tout ça sur un CMS qu’il ne semble pas maîtriser et finalement ça fait un peu lynchage.

Je dis que je n’aurais pas aimé être là, mais en fait si, pour ne rien rater et pouvoir éviter cet article (ou pas).

J’utilise WordPress depuis près de 5 ans et je contribue tant que je peux à l’élaboration de la doc FR et EN, au core de WordPress, à signaler des failles dans les plugins, ce genre de chose. Tout le monde dans une communauté peut faire avancer les choses selon son domaine de compétence et faire améliorer son CMS/Framework favori.