Discussion :

[Tsilefy]

@Tsilefy : "Tant que Wordpress tournera sur PHP 5.2, ça restera une plaie."... PHP 5.2.x est à oublier, si un administrateur de serveur utilise encore PHP 5.2.x ce n'est pas la faute de WordPress mais la faute de l'administrateur serveur. Il tout à fait possible (et recommandé) de faire fonctionner WordPress sur PHP 5.3 et plus... il fonctionne sous PHP 7 (BETA).

Le but n'est pas de trouver le fautif, on sait qu'il y a plein d'hébergeurs à bas coûts qui refusent de mettre à jour leur PHP, pour une raison très simple: le jour où ils changent, 90% des sites qu'ils hébergent afficheront des erreurs ou cesseront de fonctionner, et la fuite de ces clients (qui s'en foutent de savoir que cette mise à jour est nécessaire, tout ce qu'ils savent c'est qu'avant leur site marchait et après ça ne marche plus) suffirait à les mettre sur la paille. C'est une attitude compréhensible, mais qui pose des problèmes en matière de sécurité.

Bien évidemment, les gens comme nous qui peuvent contrôler la version de leurs clients font tourner Wordpress sur PHP 5.5 et +. Je dirais aussi que ces mêmes gens disposent des compétences pour parfaitement sécuriser Wordpress, et savent que Wordpress n'est pas fait pour du e-commerce, par exemple.

Le problème, c'est les utilisateurs lambda qui vont installer Woocommerce (ou équivalents) et prendre les numéros de carte de crédit de leurs acheteurs sur leur site, sans se douter du risque que ça représente pour eux et leurs clients.

[Paleo]

par contre les dev détestent bosser dessus :p

C'est le contraire. Quand on aime développer, on préfère développer plutôt que de cliquer. On préfère WordPress plutôt que Drupal ou Joomla!.

Je ne connaissais pas cette méthode mais tu ne fais là que soulever un problème :
Dans un CMS, quand on veut étendre ses fonctionnalités, soit on code un module bien rangé, soit on utilise l'interface d'administration pour le faire (après tout, l'objectif principal d'un CMS est de pouvoir gérer son contenu sans toucher au code).
On ne rajoute surtout pas une fonction placée à l'arrache n'importe où. Il en va de même pour l'ajout de format d'images, de fonctions de tri ...
Le fait de ne pas donner accès à trop de fonctions à l'utilisateur final est un faux problème, normalement l'administrateur contrôle ce à quoi les rédacteurs ont accès (ce qui se fait aussi à l'arrache dans des fonctions sous Wordpress, il me semble).

L'originalité de WordPress en tant que plateforme généraliste, par rapport aux autres CMS, c'est précisément l'approche par le code.

WordPress est seul sur son créneau : une solution pratique quelque part entre une approche framework et CMS. Sa popularité vient de l'absence de concurrence, parce que les autres projets sont tous des puristes : d'un côté les CMS et leur clickodrôme tentaculaire, de l'autre les frameworks qui demandent trop de code pour des projets modestes. Cela fait penser à MS Access qui tient dans la durée sur son créneau à la fois bâtard et pratique.

[Paleo]

J'irai même plus loin en soutenant que l'approche bâtarde de WordPress est un réel meilleur choix professionnel que les CMS et les frameworks.

Pourquoi pas les CMS ? Les CMS et leurs labyrinthes cliquables sont faits pour ceux qui ne sont pas développeurs. Un débutant peut faire son site avec Joomla ou Drupal, tant mieux pour lui. Mais pour un développeur, une série de clics n'est pas optimisable contrairement à un morceau de code qu'on peut copier d'un projet à l'autre. Après déploiement, les modifications par clics doivent nécessairement être faites en live pour éviter les soucis de fusion de base de données, alors qu'une modification sur un thème WordPress se code en local et se déploie en écrasant les fichiers PHP. Cliquer, pour un professionnel, c'est du temps perdu.

Pourquoi pas les frameworks ? Parce que si on code avec un framework, c'est qu'on fait du sur mesure déployé sur un seul serveur dont on maîtrise l'administration. Si on a la main sur l'administration du serveur, alors on a le choix du langage et PHP n'est probablement pas la meilleure option. Je ne souhaite pas lancer un troll, c'est juste mon avis.

[Sodium]

J'irai même plus loin en soutenant que l'approche bâtarde de WordPress est un réel meilleur choix professionnel que les CMS et les frameworks.

Pourquoi pas les CMS ? Les CMS et leurs labyrinthes cliquables sont faits pour ceux qui ne sont pas développeurs. Un débutant peut faire son site avec Joomla ou Drupal, tant mieux pour lui. Mais pour un développeur, une série de clics n'est pas optimisable contrairement à un morceau de code qu'on peut copier d'un projet à l'autre. Après déploiement, les modifications par clics doivent nécessairement être faites en live pour éviter les soucis de fusion de base de données, alors qu'une modification sur un thème WordPress se code en local et se déploie en écrasant les fichiers PHP. Cliquer, pour un professionnel, c'est du temps perdu.

Pourquoi pas les frameworks ? Parce que si on code avec un framework, c'est qu'on fait du sur mesure déployé sur un seul serveur dont on maîtrise l'administration. Si on a la main sur l'administration du serveur, alors on a le choix du langage et PHP n'est probablement pas la meilleure option. Je ne souhaite pas lancer un troll, c'est juste mon avis.

C'est exactement pourquoi je préfère faire mon propre développement avec ma propre bibliothèque de classes avec une gestion de contenu standardisée. Quitte à faire pratiquement tout à la main, autant ne pas reposer sur un CMS dont le développement chaotique tournera forcément à la catastrophe.

[Paleo]

C'est exactement pourquoi je préfère faire mon propre développement avec ma propre bibliothèque de classes avec une gestion de contenu standardisée. Quitte à faire pratiquement tout à la main, autant ne pas reposer sur un CMS dont le développement chaotique tournera forcément à la catastrophe.

Idem. Mais je n'ai pas encore une solution opérationnelle. En attendant, j'utilise WordPress, et ça a le mérite de fonctionner sans me faire perdre du temps.

[chrtophe]

Intéressant ce POST. Je ne fais pas de site mais j'ai du reprendre un site existant et m'en suis tiré sans trop transpirer. J'ai appris que le code de Wordpress est un peu pourri. Et il m'apporte plusieurs questions.

Comment marche en quelques mots le codage d'un plugin ?

Pourquoi utiliser php 5.2 avec Wordpress est un problème(lié à non fiabilité php ou mauvais code) ? Et ce problème est t'il résolu avec php 5.3 et comment?
N'est t'il pas possible de faire du e-commerce de façon fiable avec Wordpress ? Je sais bien qu'à la base il n'est pas conçu pour ça mais y a t'il des plugin le permettant (j'entends par là des choses sérieuses)

[Tsilefy]

@Tarh_: non pas que je suis en désaccord avec tout ce que tu dis, mais je veux juste corriger une chose: tu peux parfaitement tout faire en code sur Drupal. C'est même recommandé car tout ce qui est en code (et versionné sous git) ne disparaîtra pas et est facile à déployer. L'interface utilisateur c'est pour le contenu, le code c'est pour le reste (même si Drupal te permet de faire énormément de choses en cliquant). Et ce sera encore plus facile de développer sur Drupal 8 que sur le 7. La 8 est la version la plus developer-friendly qui existe.

[blbird]

Il y a aussi quelque chose que j'ai découvert en l'utilisant dernièrement, et ayant reçu beaucoup d'appels à ce sujet, WordPress est une PLAIE en terme de sécurité : c'est un pot de miel pour les Hackers.

Et même en y passant du temps, il est difficile de le sécuriser correctement. Pour moi c'est son plus gros défaut, et de loin.

[Tsilefy]

Comment marche en quelques mots le codage d'un plugin ?

En quelques mots, Wordpress propose des "hooks", c'est-à-dire des points d'entrées pour un code externe. Un plugin profite de ces hooks pour modifier le comportement de base de Wordpress ou ajouter des nouvelles fonctionnalités. Ex: avant d'afficher un titre d'un post. Un plugin peut donc s'en servir pour modifier ou remplacer complètement le titre qui sera affiché. Ça veut dire aussi qu'un plugin mal codé peut complètement bugguer ton site, et le pire c'est quand ces bugs ne sont pas systématiques et que tu as du mal à les reproduire.

Pourquoi utiliser php 5.2 avec Wordpress est un problème(lié à non fiabilité php ou mauvais code) ? Et ce problème est t'il résolu avec php 5.3 et comment?

- PHP 5.2 et 5.3 ne sont plus supportées. Ça veut dire que si on découvre une faille de sécurité sur ces versions, ces failles ne seront plus corrigées, tu seras seul à pleurer avec ton vieux code. (On peut éventuellement backporter les corrections sur ces versions si on a les compétences techniques pour le faire ou si on est prêt à payer, autrement dit ce n'est pas à la porter du premier venu).

- PHP 5.5 est beaucoup plus rapide que PHP 5.3, qui est plus rapide que PHP 5.2. Le simple fait de changer de version te donne accès à beaucoup plus de performance, gratuitement. 5.5 te donne en plus l'opcache, toujours gratuitement (i.e. sans effort suplémentaire, sans changement de ton code ou de configuration)

- À partir de PHP 5.3, PHP propose les namespaces, qui permet une organisation de code plus propre et plus flexible. Pour un développeur, c'est comme jouer avec une guitare de concert et une guitare de répétition. La musique est la même mais le son est différent.

- La plupart des librairies tiers couramment utilisés dans les projets PHP tournent sur PHP 5.3 et +. Si tu prends la liste des librairies les plus utilisées tu as Monolog (5.3), Guzzle (5.5), Swiftmailer (5.3), PHPUnit (5.6).

N'est t'il pas possible de faire du e-commerce de façon fiable avec Wordpress ? Je sais bien qu'à la base il n'est pas conçu pour ça mais y a t'il des plugin le permettant (j'entends par là des choses sérieuses)

C'est possible mais utiliserais-tu un marteau-piqueur pour enfoncer un clou? La somme d'efforts nécessaire pour créer un environnement vraiment sécurisé sur Wordpress sera mieux valorisée avec d'autres outils. Après si faire du e-commerce c'est avoir des boutons Paypal ou renvoyer le client vers un site tiers pour le paiment, c'est plus facile. Mais si tu récupéres les cartes de crédit sur le site et les envoie toi-même au Payment gateway, tu as intérêt à mettre en place une sécurité stricte, très stricte. Et en général, une fois que tu as fais ça, tu découvres trois mois après que le client a installé trois-quatre plugins qu'il a trouvé sur Internet, et que ces plugins sont des brèches géantes dans ton système de sécurité. Après, si tu as un développeur compétent qui s'en occupe à plein temps, ça ira...

[Paleo]

@Tarh_: non pas que je suis en désaccord avec tout ce que tu dis, mais je veux juste corriger une chose: tu peux parfaitement tout faire en code sur Drupal. C'est même recommandé car tout ce qui est en code (et versionné sous git) ne disparaîtra pas et est facile à déployer. L'interface utilisateur c'est pour le contenu, le code c'est pour le reste (même si Drupal te permet de faire énormément de choses en cliquant). Et ce sera encore plus facile de développer sur Drupal 8 que sur le 7. La 8 est la version la plus developer-friendly qui existe.

Il est en effet possible que je ne sois pas à jour avec Drupal, ma dernière expérience était sur Drupal 7. Cela dit, sous Drupal et Joomla, j'avais bien compris que pour chaque bouton à cliquer il existe une API côté développement. Par exemple sous Joomla, le thème peut ordonner une liste d'articles indépendamment de ce que l'utilisateur aura configuré. Au passage, pour que ça ait du sens, il faudrait au moins que la partie concernée du clickodrôme soit désactivable. Maintenant, dans le cadre d'un clickodrôme qui fonctionne (approche CMS), quelle est la bonne pratique ? Utiliser le clickodrôme ou bien faire l'impasse dessus ?

Drupal : il m'avait paru la pire des solutions à cause d'un choix de design particulier : le principe de l'édition dans le contenu publié. C'est techniquement impressionnant, mais en pratique un mauvais mélange des genres. Un espace à part pour travailler sur les textes, c'est mieux.

Comment marche en quelques mots le codage d'un plugin ?

https://codex.wordpress.org/Plugins

Pourquoi utiliser php 5.2

PHP 5.2 n'est plus maintenu. Il ne faut plus l'utiliser et cela n'a rien à voir avec WordPress.
Aujourd'hui il faut passer en 5.5 ou 5.6 : https://en.wikipedia.org/wiki/PHP#Release_history .

N'est t'il pas possible de faire du e-commerce de façon fiable avec Wordpress ?

Si. Les histoires de numéros de CB c'est du pipeau. Elles sont manipulées en HTTPS par les banques ou Paypal, ne sont pas stockées sur le site, ou alors il faut donner les noms des plugins coupables.

Il y a aussi quelque chose que j'ai découvert en l'utilisant dernièrement, et ayant reçu beaucoup d'appels à ce sujet, WordPress est une PLAIE en terme de sécurité : c'est un pot de miel pour les Hackers.

Certains plugins, effectivement. Pas de souci en revanche pour des sites faits avec le noyau WP, quatre ou cinq petits plugins dont on regarde le code, plus un thème fait sur mesure.

[Tsilefy]

Il y a aussi quelque chose que j'ai découvert en l'utilisant dernièrement, et ayant reçu beaucoup d'appels à ce sujet, WordPress est une PLAIE en terme de sécurité : c'est un pot de miel pour les Hackers.

Et même en y passant du temps, il est difficile de le sécuriser correctement. Pour moi c'est son plus gros défaut, et de loin.

Une application qui a une liste longue comme le bras sur la meilleure manière de la sécuriser amène à se poser des questions. Pourquoi est-ce qu'ils n'implémentent pas la plupart de ces mesures directement? Pourquoi autoriser des plugins comme Exec-PHP ou PHP Everywhere, qui sont extrêmement dangereux? Pourquoi ne pas déplacer tous les fichiers dans un répertoire inaccessible depuis le web? La réponse: parce que ça rendrait la vie difficile à l'utilisateur lambda, qui veut juste avoir un blog sans se prendre la tête. Tant pis pour ceux qui cherchent plus qu'un blog, ils doivent se débrouiller eux-mêmes.

[Tsilefy]

Si. Les histoires de numéros de CB c'est du pipeau. Elles sont manipulées en HTTPS par les banques ou Paypal, ne sont pas stockées sur le site, ou alors il faut donner les noms des plugins coupables.

À partir du moment où le client saisit son n° de CB sur le site, même si le CB n'est pas stocké, même si le formulaire envoie directement le numéro vers la banque sans autre traitement supplémentaire par PHP, il y a un risque certain (ce qui vaut pour toutes les plateformes). Par contre, si le paiement se fait par redirection hors-site, oui, il n'y a pas de risque.

Le souci avec Wordpress c'est qu'on peut profiter des vulnérabilités de certains plugins très répandus pour en prendre le contrôle et injecter du code pouvant surveiller ces saisies.

[Paleo]

C'est possible mais utiliserais-tu un marteau-piqueur pour enfoncer un clou? La somme d'efforts nécessaire pour créer un environnement vraiment sécurisé sur Wordpress sera mieux valorisée avec d'autres outils. Après si faire du e-commerce c'est avoir des boutons Paypal ou renvoyer le client vers un site tiers pour le paiment, c'est plus facile. Mais si tu récupéres les cartes de crédit sur le site et les envoie toi-même au Payment gateway, tu as intérêt à mettre en place une sécurité stricte, très stricte. Et en général, une fois que tu as fais ça, tu découvres trois mois après que le client a installé trois-quatre plugins qu'il a trouvé sur Internet, et que ces plugins sont des brèches géantes dans ton système de sécurité. Après, si tu as un développeur compétent qui s'en occupe à plein temps, ça ira...

Si le client est irresponsable, effectivement. :-s
La solution s'appelle éventuellement : "DISALLOW_FILE_MODS".
https://codex.wordpress.org/Editing_wp-config.php

Stocker des cartes de crédit : il faut une très bonne raison de le faire. Par exemple je trouve la gestion de Skype réellement dangereuse. Si on se fait faucher son mot de passe, ça peut faire très mal.

Le choix de WP+plugin pour le commerce a un avantage : la simplicité. Plusieurs inconvénients : la pérennité n'est pas assurée, chaque upgrade est risqué. Et les solutions WP sont moins complètes que les CMS spécialisés. Mais pour qui a goûté à PrestaShop ou Magento, la simplicité à l'usage de WP est un avantage qui peut l'emporter s'il s'agit juste de vendre une vingtaine d'articles dans une rubrique "Boutique" d'un site vitrine classique.

[Tsilefy]

Mais pour qui a goûté à PrestaShop ou Magento

Qu'on ne me parle pas de Magentoooooooooo :-)

[Tsilefy]

Pour en revenir à la discussion initiale, Wordpress est finalement à l'image de PHP: on peut faire du spaghetti rempli de variables globales avec, mais on peut aussi faire un code découplé et propre.

[tse_jc]

Bonjour,

Les CMS open source ont tous un défaut majeur : ils supportent tous mal voire très mal la montée en charge dû essentiellement à leur architecture. C'est un défaut que de plus en plus de gens vivent mal, et de ce point de vue, wordpress, avec son faible niveau d'abstraction, offre des performances ressenties accrues par rapport aux autres CMS, ce qui plaît et le rends attractif, à très attractif. Ainsi on peut voir aujourd'hui des petites entreprises, qui font leur gestion client et leur gestion des ventes avec wordpress, et j'en passe des meilleures, ce qui est un gros n'importe quoi, wordpress n'est ni fait ni taillé pour ce genre de choses.
C'est le marché qui exprime ses besoins, à nous de sortir notre épingle du jeu^^.

[Sodium]

Cela me paraît assez loin de la vérité car la plupart des CMS intègrent de base un système de cache.
Au dela de ça, si je compare sur mon serveur un site simple fait sur mesure à un site wordpress encore plus simple, Wordpress met 4 à 5 fois plus de temps pour afficher une page. Il est peut-être plus léger que d'autres CMS, mais il reste suffisament lourd pour induire un temps de calcul conséquent tout de même.

[YannX]

Débat aussi agé que les dix ans du produit....

Effectivement, WP est -à ma connaissance- le plus simple générateur de site Web-vitrine (avec éventuellement blog et commentaires) que je connaisse, surtout au premier abord ; l'installer est presque immédiat (il manquait un spip_loader et la creation intégrée de la BdD...). De plus, l'interface privée (le back-end) présente une ergonomie et une apparence très agréables et faciles à utiliser (pas comme l'ancien Joomla chéri de nombreux débutants) !

Et son énorme point fort est certainement l'apparence graphique, l'habillage, la forme affichée, la disponibilité de thèmes graphiques immensément nombreux, et très bien finis -du moins en apparence- !
Car c'est là que commencent les ennuis : car la complexité du front-end (mélange unique de php, de css et de html, directement livrés en pature à l'administrateur) est totalement hermétique au débutant, ce qui a justement provoqué le métier de développeur de thèmes... D'ailleurs le mot de thème WP est trompeur, car il s'agit plutot d'un remplacement du générateur des pages publiques... Et quant à parler de sécurité (le succès fait la fragilité), tant les failles -ces derniers temps- que, comme certains le relevent plus haut, la programmation criticable, contriagnent encore plus à vouloir sécuriser son site avec un suivi permanent des mises - jour du produit. Du coup, modifier un thème devrait se faire en utilisant les thèmes enfants, sinon toute mise à jour oblige à tout recommencer" : mais combien d'utilisateurs, et même combien de développeurs l'utilisent ? Plus simple de 'vendre' (avec un coefficient multiplicateur de 100 !) un template acheté 50 $ sur le Web !
Car justement, il n'y a pas de moteur de template dans le produit (ni de cache), ce qui dénote son 'amateurisme', versus Drupal, Symfony, Spip, Prestashop, Smarty...

Coté plugins, indispensables pour étendre les fonctionnalités liées à une base de données squelettique (7 tables pour les blogs, à comparer aux 30 tables des 'vrais' CMS), c'est la foire : très grand nombre, certes, mais sans normes de développement, volontiers payants, ou/et sans suivi souvent, donc sans cohérence (sans intégration possible en cache), et c'est la zone pour trouver le bon : encore un métier induit ;-) !
Oui, il existe une API d'accès : mais il s'agit en fait plutot d'un simple système de 'fonctions d'accès, donc d'une version spécifiquement dérivant vers un template ; et nous ne parlerons pas des boucles (puisqu'elles ne peuvent conserner que les posts : normal, il n'y a que cela dans la BD ;-( ).... Et puis, avec tous les plugins installés, avez-vous esssayé de déplacer le site, sur un changement d'arborescence ou de préfixe de tables ? Tout est en dur dans des champs de tables... Bon courage avec phpmyadmin !

En clair, investir un site (à pérenniser, à faire evoluer -tant en contenu qu'en présentation et surtout en organisation de nouvelles données-) c'est-à-dire monter un CMS, (ce qui est un véritable investissement -en temps de remplissage/illustration et communication/référencement, n'est pas un choix industriel pérenne sur WP : WordPress n'est qu'un CMS jettable : ne dépensez pas plus là-dessus !
Si on part du postulat de garder PHP (qui présente tout de meme de vrais avantages de performance et POO, de diffusion et de simplicité...), préférez de vrais outils structurés, avec un moteur séparant la présentation des données (moteur de boucles) et l'habillage cosmétique ; vous gagnerez le temps passéà reprendre dans votre moteur de template HTML l'apparence d'un thème WP(car il y a des artistes), avec une courbe d'apprentissage sans seuil (le 'mur' d'un WP pour qui veut dépasser le seul téléchargement de thèmes), et une pérennité qui est la marque du produit industriel...

[YannX]

J'avais répondusur mon avis pratique de WP (je viens d'en reprendre une dizaine de sites ! ) ; puis la lecture de vos commentaires et interrogations me font tirer un second bilan d'une pratique avec la plupart des CMS;

D.. : il m'avait paru la pire des solutions à cause d'un choix de design particulier : le principe de l'édition dans le contenu publié. C'est techniquement impressionnant, mais en pratique un mauvais mélange des genres. Un espace à part pour travailler sur les textes, c'est mieux.

• - Techniquement impressionnant ??? Les wikis font cela depuis longtemps, et c'est fort pratique
  - Ce sont deux méthodes différentes et -d'usage : quelques miliers de pages écrites- très complémentaires :
  le tout est d'avoir la capacité de les faire cohabiter pour pouvoir choisir selon l'instant => voir les "Crayons" ..

Cela me paraît assez loin de la vérité car la plupart des CMS intègrent de base un système de cache.

Mais ce système de cache est-il natif/intégré/utilisable par les plugins... (je renvoie au 'bon souvenir' de france.fr l'été passé ! )

Pas de souci en revanche pour des sites faits avec le noyau WP, quatre ou cinq petits plugins dont on regarde le code, plus un thème fait sur mesure.

J'espere que tu as fait d'urgence tes montées en 4.2.2 sans soucis avant d'etre hacké !

C'est exactement pourquoi je préfère faire mon propre développement avec ma propre bibliothèque de classes avec une gestion de contenu standardisée. Quitte à faire pratiquement tout à la main, autant ne pas reposer sur un CMS dont le développement chaotique tournera forcément à la catastrophe.

Idem. Mais je n'ai pas encore une solution opérationnelle. En attendant, j'utilise WordPress, et ça a le mérite de fonctionner sans me faire perdre du temps.

Bon... après lecture de vos avis, je vais faire un peu de pub : je reprocherai à SPIP de ne pas avoir beaucoup de thèmes graphiques aussi jolis que ceux de WP ; sinon, bien que n'etant pas programmé en objet (mais avec une conception objet), ni en vrai MVC, c'est une solution opérationnelle (répondant à avec un moteur de templates bien plus simple que Smarty.

Mais on lui reprochera de ne pas avoir de moteur de routage comme Symfony, uniquement des URL.....
Coté fiabilité et performances (régler la durée de cache), c'est sans égal.
Coté codage (et surtout des plugins !)... découvrez-le !

[Paleo]

Si on part du postulat de garder PHP (qui présente tout de meme de vrais avantages de performance et POO, de diffusion et de simplicité...), préférez de vrais outils structurés, avec un moteur séparant la présentation des données (moteur de boucles) et l'habillage cosmétique ;

À quelle(s) solution(s) pensez-vous concrètement ?