Ce qui manque à WordPress : pas tant que ça…
Comment définir ce qui manque à WordPress ?
Le beurre, l’argent du beurre, le sourire de la crémière, les omegas3 et l’absence de cholestérol
Il y a deux façons de voir ce qui manque à WordPress : raisonner par rapport aux fonctionnalités qu’on souhaiterait avoir, et qui ne sont pas implantées, ou raisonner par rapport à ce que la structure de données ou le core de WordPress empêchent de faire facilement, ou complètement.
En effet, WordPress n’a jamais prétendu être un système complet. Il y a un compromis nécessaire entre la facilité d’utilisation et l’étendue des fonctionnalités standard. Et plus vous en mettez en standard, plus l’installation de base est complexe, et plus elle est difficile pour un débutant. Il suffit pour s’en convaincre de comparer l’installation d’un Drupal ou d’un Typo3 avec celle d’un WordPress. Il faut nettement plus de cinq minutes pour avoir un Drupal fonctionnel, même quand on maîtrise ce CMS. Et je reste là dans le domaine des CMS, je ne m’aventure pas vers des monstres comme SAP…
Une des raisons pour lesquelles je suis fan de WordPress et n’ai jamais réussi à le quitter pour autre chose, c’est justement cette balance entre simplicité et extensibilité, et la robustesse de son modèle de données (je reconnais que l’organisation des fichiers et du code pourrait être améliorée, mais le modèle de données est très bien). Par ailleurs, quand on regarde ce qui “manque à WordPress”, il ne faut pas non plus oublier la compatibilité ascendante, très rare, où en clair un site développé avec WP xx continue à marcher avec WP yy (à quelques exceptions près, comme le changement majeur dans la gestion des termes). C’est assez remarquable de voir qu’un système né pour le blogging à une époque où on ne connaissait même pas les tags n’a pas eu besoin de totalement modifier l’organisation de sa base.
Core ou plugin
Personnellement, j’ai tendance à considérer que ce qui est dans un bon plugin solide n’est pas un manque de WordPress. “Tout” n’a pas besoin d’être dans le core. Même des fonctions très standard, comme le breadcrumb, que demande Rémy ne sont pas une “obligation”, je ne les utilise pas partout. Donc faut il charger le core, avec une option à activer ou désactiver ? Et quand on voit à quel point on a du mal à faire comprendre à certains néophytes les concepts de base (page, catégorie, article, menu), rajouter les explications pour les possibilités du breadcrumb ?
Dans mes top plugins, il y a la classe WPAlchemy, pour toutes les metaboxes, WPML pour la traduction (bien qu’il soit payant, le support est derrière, et je n’ai rien trouvé d’aussi bien en gratuit), WordPress SEO de Yoast (quelle originalité) et une batterie de plugins pour la gestion des images. Pour l’admin, je rajoute CodePress Admin Columns, des extensions de Tiny Mce, et pour le SEO, en plus de Yoast, quelques plugins qui jouent sur les urls, pour les sites complexes, post to post, et j’ai généralement 98% de mes besoins couverts.
Vous noterez que je n’utilise pas de plugins pour la définition des custom post types et des custom taxonomies : je n’en vois pas l’utilité, mais beaucoup de contraintes, et un peu de code ne fait pas de mal !
Débutant ou expert
Les manques ne vont pas être les mêmes selon qu’on est débutant ou expert. Or en lisant certains articles de la chaine, j’ai eu l’impression que certains confondaient un peu les deux niveaux : quand Daniel demande que WordPress explique les implications SEO de certains champs, je crois qu’on va trop loin pour des débutants, et que pour ceux qui connaissent, c’est parfaitement inutile. Nous utilisons WordPress comme des professionnels. Mais n’oublions quand même pas qu’une large partie des blogs WordPress sont fait par des gens qui cherchent simplement à communiquer avec leurs proches, sans être des addicts au référencement. Par ailleurs, quand je vois le mal que j’ai pour faire comprendre à mes clients l’importance de la réécriture du titre et du permalien, ou des h2 et des liens internes, je crains qu’une brève explication sur “alors la le slogan ça va être la meta description de votre home et c’est important pour les moteurs” soit pire que son absence. (Passez un peu plus souvent sur wordpress-fr.net, vous verrez qu’on est très loin de tout ça…)
Bref à chaque outil son rôle, et même si ça nous ferait plaisir, celui de WordPress n’est pas de former au référencement (ou même au HTML, alors que, là encore 80% des demandes de support “wordpress” soient en fait des problèmes de codage HTML ou CSS).
Bon, tout ça c’est bien joli, mais qu’est-ce qui manque à WordPress alors ? Rien ?
Oh que si…
En vrac, je suis assez d’accord avec les points principaux : la gestion des images est “pauvre”, la sécurité pourrait être un peu améliorée, et WordPress n’est pas vraiment une solution E-commerce. Maintenant dans mon utilisation, deux choses me manquent vraiment, c’est à dire qu’elles sont dans l’état actuel des choses, quasi-impossible à faire sans toucher les fichiers core de wordpress.
WordPress totalement multilingue
Il existe des plugins pour traduire le front-end. Après de multiples tests, j’ai choisi WPML, il y en a aussi un nouveau, que je n’ai pas testé (et dont je ne retrouve même plus le nom…). On peut aussi quand on fait un plugin, traduire ses pages d’admin. Mais il y a une chose qui est impossible à faire aujourd’hui, c’est un login complètement multilingue.
Imaginions que vous ayez un site bilingue, avec la langue par défaut en français, urldusite.fr . Votre wp-config.php définit donc la langue du blog en fr_FR. Vous avez une version anglaise, que vous avez installée sur un sous-domaine, en.urldusite.fr ou mieux sur urldusite.com. Quoi que vous fassiez, l’url de l’admin sera toujours sur urldusite.fr, ce qui veut dire que, à moins de modifier le processus d’inscription, en rajoutant la langue en paramètre, et en modifiant la valeur de la langue par défaut de l’utilisateur (chose que permet WPML), votre utilisateur anglophone, qui se sera enregistré via urldusite.com se retrouvera sur urldusite.fr/wp-admin, et en français (il y a un plugin pour choisir sa langue sur la page de login, quand même).
Pour l’utilisateur lambda, monolingue, ça peut être très gênant. Encore plus si une des deux langues du site est l’arabe ou le russe…
Or cela vient d’un certain nombre d’url hard-codées dans les fichiers core de WordPress. “Insurmontable” a priori.
Sinon, il manquerait bien effectivement une obligation d’internationaliser ses plugins et ses thèmes, en tout cas pour les voir accepter dans wordpress.org. Mais <mode joke on> ce sont des américains, ne rêvons pas <mode très bête off>
Enfin certains plugins peuvent générer des contenus assez difficiles à identifier pour les modules de traductions. Ceux ci se basent en effet sur les structures standard de WordPress pour aller identifier les chaînes et les contenus à traduire. On traduira ainsi les posts, mais pas les auteurs (sauf la biographie…) etc.
Quand des plugins rajoutent des tables, où vont loger leurs données à des endroits bizarres, la traduction devient difficile. J’ai ainsi abandonné l’utilisation de GD Custom Posts and Taxonomies parce qu’il était “de fait” monolingue. Son interface ne permettait pas la traduction des étiquettes (l’argument ‘labels’), et allait les stocker dans un enregistrement sérialisé sur plusieurs niveaux dans la table options. Un cauchemar pour faire le lien avec WPML, et une impossibilité pour les autres plugins de traduction. Or les “labels” sont aussi utilisés dans le front-end, notamment dans certains widgets…
La gestion transversale des taxonomies
Gné ?
“Au commencement était le blog, et l’article qui avait des catégories, et le lien dans la blogroll, qui avait des catégories de liens (les potes, les blogs que je lis), et l’image, qui n’avait rien du tout”.
Puis sont venus les tags, toujours pour les articles, et pour le reste ça ne bougeait pas.
Puis est venue la gestion des termes, avec des plugins qui permettaient d’appliquer des catégories et des tags aux pages, et d’autres plugins qui créaient des tags pour les medias.
Puis sont venus les CPTCT (Custom Post Types et Custom Taxonomies) avec la possibilité de taguer / catégoriser comme on veut.
Mais toujours avec cette idée de base que chaque type de contenu avait “sa propre classification”. D’ailleurs cela se voit bien dans l’admin, où les taxonomies sont des sous-menus d’un type de contenu.
Quand nous en avons discuté sur la chaine WordPress, pour certains c’était normal : à chaque type de contenu sa classification. Pour moi j’ai plutôt tendance à voir le contenu d’un site comme un énorme cube, que je peux “analyser” selon des dimensions de type de contenu, de catégories, de schmilblick et de gloubi boulga. Autrement dit, j’aurais tendance à ne pas comprendre que sur un site qui me parle de cuisine, on me mette une blogroll qui me parle de mécanique des fluides, ou des images qui représentent la migration des lemmings. Si certaines taxonomies peuvent être spécifiques à certains types de contenu, il me semble logique que les taxonomies de base s’appliquent à l’ensemble des contenus d’un site.
C’est réalisable, via un plugin (ou le fichier functions.php du thème, mais il faut mieux éviter cette solution). Mais cela restera toujours bancal. En effet, si on peut même modifier dans le thème les pages de “taxonomie”, ou les templates category.php ou tag.php pour qu’ils incluent tous les types de contenu, dans l’admin, on n’aura pas cette vision globale.
Imaginons une catégorie “mon titi à plume”, avec trois articles, deux “pedigrees” et un “concours” (deux types de contenus spécifiques). Le compteur de WordPress vous indiquera 6 éléments classés dans “mon titi à plumes”, mais vous n’en verrez que trois, deux ou un selon le type de contenu à partir duquel vous les appelez.
En effet l’url de la page listant les valeurs d’une taxonomie est :
/wp-admin/edit-tags.php?taxonomy=xx&post_type=yy
et l’url pour voir tous les éléments classés dans le “titi à plume” sera
/wp-admin/edit.php?xx=titi-a-plume&post_type=yy et si vous avez l’idée d’enlever le paramètre &post_type=yy WordPress considère que vous voulez voir les articles. Si vous essayez de lui dire &post_type=all, il vous répond gentiment qu’il ne connait pas ce type d’article.
Il est donc impossible d’avoir une vision globale sur tous les contenus d’une taxonomie donnée, sans refaire entièrement les pages d’admin du core.
Les articles de la chaine WordPress :
- 27 février – SeoMix, Que manque-t-il à WordPress ?
- 28 février – Boiteaweb, Que manque t-il à WordPress en sécurité ?
- 29 février – Wabeo, Que manque t-il à WordPress en WebDesign ?
- 01 Mars – WP Themes Pro, Que manque t-il aux thèmes WordPress ?
- 02 Mars – Insidedaweb, Que manque t-il à WordPress en ecommerce ?
- 05 Mars – WPChannel, Que manque-t-il à WordPress ?
- 06 Mars – The Loop, Les lacunes de l’expérience utilisateur WordPress
- 07 Mars – Screenfeedfr, Que manque-t-il à WordPress ? Idées d’interfaces
- 08 Mars – Lumière de lune, c’est ici !
- la semaine prochaine, GeekPress
Et pour conclure, un grand merci à Daniel, qui a eu cette idée folle d’organiser la chaine, et de la porter à bout de bras !
Je crois que c’est l’article le plus réussi de la chaine WordPress.
Non pas parce que c’est celui qui cite le plus les lacunes et les différents manques de WordPress, mais surtout car c’est l’article qui répond le plus aux articles précédent et à tous les participants. Bravo !
Enfin quelqu’un qui parle des sites multilingues ! Même si elle abordée de façon très rapide ! :).
La problématique est assez énorme, dans le sens où chacun aura ses besoins. D’un côté il faut juste le site miroir avec les mêmes contenus et les mêmes taxo, de l’autre un site complètement différent mais avec une structure un peu différente etc.. Par exemple pour traduire une taxo, je garde le même nom ? le slug change ? dans l’url c’est pareil ? les termes sont fusionnés pour certains et pas d’autres ? etc… Très compliqué et franchement aucune solution universelle n’existe encore en répondant a toutes les demandes.
Petite précision, WP_ALchemy n’est pas un plugin en soit c’est juste une librairie qui utilise les hooks de WordPress pour nous aider à faire des metaboxes :)
Excellentissime analyse et je partage l’avis de Daniel !
Rien à ajouter :)
@ Daniel et krysttof, merci, merci :)
@ Raherian, le multilingue est mon dada, j’ai fait plein d’autres posts sur le sujet ^^ Assez d’accord avec vous pour la complexité et la diversité des besoins. Il existe grosso modo trois types de besoins / solutions :
– traduction ponctuelle d’un contenu, herewithme a fait un excellent plugin là dessus Simple Punctual Translation
– traduction complète avec une relative synchronisation des contenus : pour moi WPML is king (il permet notamment de choisir, taxo par taxo, type de post par type de post, si on va traduire, copier, ou “ignorer” [désynchroniser totalement])
– désynchronisation importante des contenus : là il vaut sans doute mieux faire deux blogs via le multisite, mais c’est un cas de figure que j’ai rarement rencontré.
Pour WPAlchemy, on est aussi d’accord, disons que c’est une “extension” de WordPress. Personnellement je l’utilise dans un plugin, et pas dans le fichier functions.php du thème.
Il manque des options de customisation et également de SEO de base.
Par exemple, il serait sympa pour les prochaines versions de pouvoir facilement changer le logo WordPress présent sur /wp-admin & /wp-login
Un breadcrumb serait un plus en effet !
Intéressant l’article sur la sécurité via Boiteaweb, je connaissais l’astuce du compte “admin” qui n’est pad Administrateur mais simple abonné mais je ne connaissais pas l’intéret de changer “l’ID 1” du compte Administrateur..
Gael
@marie-aude:
Pour WPML, je l’avais utilisé avant qu’il passe en payant, il marchait bien mais par contre le code était bien moche et assez crade… J’espère qu’après la refonte ça c’est amélioré :).
Au final, pour moi, la solution “ultime” est quand même le multisite, un site par langue et après on peut créer un système qui s’appuie sur le XML-RPC pour faire de la synchro ( ou pas ), ça permet d’avoir des admins différentes dans la langue du rédacteur et tout et tout :) ( pensons au rédacteur surtout ^^ ).
Pour WP_Alchemy je fais pareil, plugin qui va créer toutes les métabox avec les controleurs etc. :)
P.S: Petit problème dans les emails envoyé lorsqu’on s’abonne aux commentaires le lien n’est pas correctement créé :
Pour lire tous les commentaires sur cet article :
/encrelune/manque-wordpress,2012,03#comments
^^
@ Raherian, pour le subscribe2comments… euh je sais pas ^^ j’irai voir mais pas tout de suite :)
Pour WPML, je n’ai pas regardé la qualité du code en soi, mais les résultats, qui sont là :)
Il permet notamment le choix de la langue d’admin pour l’utilisateur ^^
Ce que j’apprécie aussi énormément, c’est l’interface de suivi de la traduction, qui permet aussi de travailler assez facilement avec des traducteurs externes.
Quand WPML est devenu payant, je me suis réellement posée la question de passer sur des solutions de type multisite. J’en ai conclus que j’allais avoir à re développer “tout” WPML, et j’ai donc décider de payer la licence.
J’ai beaucoup apprécié quand j’ai passé plus de trois heures sur Skype avec Daniel Dvorkin pour résoudre un problème de traduction de termes sur un de mes sites, je me suis dit qu’au prix du consultant informatique, elle était plus que rentabilisée.
Mais encore une fois, à chaque site “multilingue”, je me repose la question de la meilleure solution.
Pour le multilingue j’ai choisi xili-language qui est gratuit et qui fonctionne bien mieux que WPML …
Page de l’extension : http://dev.xiligroup.com/?cat=393&lang=fr_fr
Exemple d’utilisation : http://www.archigroupe.com/
Cette extension est plus simple à installer et à utiliser que WPML, et permet de créer facilement une version multilingue de tout ou partie d’un site.
En complément, l’utilisation de l’extension CodeStyling Localization est très utile pour traduire un thème ou une extension … et ce, très facilement, également ;)
Pour un site e-commerce + un CMS, je privilégie le couplage entre Prestashop et WordPress. Ce n’est pas compliqué à mettre en oeuvre, et ça fonctionne très bien. Pour le visiteur c’est totalement transparent, et pour le client, cela permet de bien séparer deux fonctions métiers bien différentes
@acs04 : Qu’en est-il de sa scurité ? Ha c’est sur, c’est gratuit, … ;)
WPML a été audité pour sa sécurité, ce n’est pas forcément le cas pour un plugin gratuit.
WPML apporte une SAV excellent et rapide.
Pour 59€ la plus grosse license, franchement, je suis payé pour parler d’eux mais OnTheGoSystem fait du très bon taf et 60€ c’est pas cher payé ;)
Bref, faites auditer vos plugins avant d’installer n’importe quoi ;)
Article très intéressant ! Rien à redire ! Vraiment d’accord avec le multilingue et ça risque pas de changer…
Il est impensable et impossible de comparer WP avec SAP. ,:O)*
Merci pour cette article, touffu et bien détaillé. En effet je vais devoir le relire plusieurs fois pour bien cerner tout son contenu.
@ SEOFrog, si justement :) en discutant avec WPML j’ai apris que c’est prévu comme modif, pas pour la prochaine release, sans doute la suivante ^^
@ Ouistity , on est bien d’accord, d’ailleurs SAP c’est plus du backend. Cela sit, si WordPress est très simple, des outils comme Typo3 commencent à retrouver un certain niveau de complexité germanique !
@Julio Potier
La sécurité ? Ce n’est pas faux concernant le gratuit… mais cela vaut alors aussi pour WP et d’autres extensions payantes ;)
Pour autant, le plugin xili semble être fiable, bien supporté et à ma connaissance, ne semble pas poser de problème de sécurité (notamment du fait de son architecture, et aussi, au vu du retour des utilisateurs).
A noter que xili-language n’ajoute pas de table. (alors que WPML en ajoute 13 – à comparer avec les 11 tables d’origine de WordPress)
J’ajoute que xili est conforme à la philosophie Open Source de WP …
Il est également possible de souscrire à un support payant.
L’extension est disponible dans le repository de WP : https://wordpress.org/plugins/xili-language/download/ et a été téléchargée près de 50000 fois.
Cela ne signifie, évidemment pas, que l’extension est un must-have, et ce n’est pas un gage de sa qualité.
Commme je l’ai dit WPML a été audité pour sa sécurité, qu’en est-il de wili ? j’en doute fortement #teaser.
Le retour des utilisateur n’est en aucun cas, et jamais en relation avec la sécurité d’un plugin.
Oui WP aussi est victime de faille mais les dev corrigent vite et les failles ne sont divulguées que quand une correction est dispo.
Pour les plugins, tout bon hacker va s’amuser à exploiter les failles sans prévenir qui que ce soit.
Personnellement, je n’utiliserais jamais xili dans cet état si vous voyez ce que je veux dire. #double#teaser
Je viens de tester rapidement xili, et sans rentrer dans les détails, par rapport à WPML, y’a pas photo…
– à l’installation, il ne propose pas d’affecter les articles déjà existant à une langue…. pas super agréable quand on décide de traduire un gros site, de devoir repasser à travers tous les articles existant pour déterminer la langue
– deuxième horreur à mes yeux, on peut relier les articles de différentes langues via l’ID. WPML propose une liste déroulante avec les titres, et n’oblige pas à aller chercher dans l’admin l’id de l’article.
– je dois être aveugle, mais je ne vois pas comment traduire les widgets texte ? Donc si je mets un widget text, il faut que je fasse comment pour qu’il s’affiche uniquement dans sa langue ?
– en ce qui concerne la traduction des catégories, via xili-language, je suis surprise de voir que la catégorie créé “normalement” n’a pas de langue, et qu’il faut la “traduire” dans sa langue d’origine.
– je ne vois absolument pas où je peux traduire les valeurs des options autres que wordpress, y compris les options sérialisées ? Et l’import des termes et des options me prend des constantes, qui ne devraient pas être traduites.
@Marie-Aude / @Julio Potier
C’est vrai que, lors de l’installation, xili ne permet pas d’affecter le contenu à une langue (mais je crois, de mémoire, qu’il est possible de définir une langue par défaut, et que toutes les pages ou articles seront affectées par défaut à cette langue… pas certain à 100% toutefois). Donc acte, c’est une suggestion à faire aux développeurs ;)
Ensuite, et je vous rejoins sur certains points, xili n’est pas forcément la panacée (pour la traduction des widgets, catégories, mots-clés, liens, etc. c’est un peu galère). Donc acte, là aussi ;)
Enfin, pour ce qui est de la sécurité, hum, comment dire ? Vaste sujet… Certes les développeurs de WP sont réactifs… et sans doute aussi ceux de WPML… on ne peut réagir qu’APRES avoir détecté le problème de sécurité… et cela n’est que très rarement instantané. Et, entre temps, les hackers de tous poils auront largement le temps de s’amuser avec les failles qu’ils auront pu détectées.
Pour rappel (des milliers de sites WP contaminés par un trojan) :
La question que je me pose, concernant la sécurité, est la suivante :
Quelle est, selon vous, la principale source de problème pour un site :
– Les utilisateurs du back-office ? (par ex. mots de passe style abcd, communication de son identifiant et de son mot de passe à un “ami”, etc.)
– Les failles de WP, des extensions ou du thème utilisé ?
– Le manque de protection de l’installation ?
– L’absence d’une procédure de sauvegarde / restauration, vérifiée ?
En conclusion, je vais tester WPML à nouveau. Et, j’espère que la dernière version me donnera satisfaction pour que je puisse changer d’avis et, ainsi, faire taire mes critiques…
@ ACS04 pour moi la première faille de sécurité est entre la chaise et le clavier ^^ ce qui inclut
– les mots de passe trop simples
– l’absence de mise à jour du site et des plugins
– l’absence de test des sauvegardes et leur réalisation aléatoire
à laquelle on rajoute toutes les cochonneries qu’on peut aller choper sur d’autres sites pendant qu’on navigue.
WordPress est aujourd’hui reconnu comme un des CMS les plus sûrs. C’est aussi un des plus répandus, donc un des plus attaqués.
Grosso modo mon petit vademecum de sécurité est :
– jamais, jamais, jamais une extension qui exige le chmod 777 (timthumb, par exemple)
– toujours essayer de comprendre pourquoi une extension n’est plus dans le repository wordpress, et si le développeur vous répond “ils ont dit qu’il y avait une faille mais c’est pas vrai”, faire confiance à l’équipe wordpress
– toujours faire les upgrades
– pas de user avec “admin” comme identifiant
– et si on est parano, un user admin et un user auteur, l’auteur étant celui qui utilise le site au quotidien, et on ne se connecte comme admin qu’en cas de besoin.
@acs04: “on ne peut réagir qu’APRES avoir détecté le problème de sécurité” oulaaa je ne peux pas laisser dire ça.
WPML ne contient pas de faille de sécurité, pourquoi ? Car le code a été audité et les failles corrigées AVANT sa sortie, idem pour les autres plugins de chez OnTheGoSystem (comme WP-Types et WP-Views).
Faire auditer son code par une personne qui ne fait pas partie de l’équipe de dev et dont le métier est la sécurité web est LA solution pour éviter de balancer des plugins vulnérables.
Bien sûr la plupart des plugins sont fait par des particuliers et ces personnes n’ont pas de budget pour faire ça …
Pour répondre à tes questions, le facteurs n°1 d’un hack WordPress est (roulement de tambour) “les plugins” !
Vient en seconde position “les thèmes”, et en bon 3eme “le mot de passe trop simple lié au compte administrateur nommé ‘admin'”
Je reprends la réponse de Marie Aude “et si on est parano, un user admin et un user auteur, l’auteur étant celui qui utilise le site au quotidien, et on ne se connecte comme admin qu’en cas de besoin.”
Ce n’est pas de la parano, c’est comme ça que ça doit être fait pour éviter des hacks. La faille CSRF étant la plus répandu (aussi bien dans les plugins que sur n’importe quel site web), le fait de rester connecté avec un compte admin, compromets vos formulaires.
Bonne soirée !
@Julio C’est vrai qu’il est préférable de faire auditer le plugin avant sa diffusion… mais, malheureusement, il semble que ce ne soit pas si fréquent…
Ce que je voulais dire, et c’est surtout valable pour WP, c’est que bien souvent les failles ne sont corrigées qu’après avoir été détectée (et donc, après la diffusion d’une version). Certes les développeurs sont très réactifs, mais cela n’empêche pas que malgré leurs efforts, il perdure parfois, et heureusement, rarement, des problèmes avec WP.
Par ailleurs, comme le fait remarquer Julio, l’audit a un coût …. et ce coût ne peut pas forcément être intégré dans tous les projets de développement. Je ne parle pas ici de l’audit des extensions, mais plus généralement de l’audit du projet dans sa globalité.
Et, j’ajoute, que la sécurité a un coût, et que les clients ne sont pas toujours conscients (ou ne veulent pas entendre parler) de ce coût jusqu’au jour où…
A mon humble avis, on doit considérer la sécurité selon deux axes principaux : d’un côté l’axe technique et de l’autre l’axe utilisateur. Car, quelque soit l’axe considéré, une faille reste une faille et représente un danger certain.
Un site super sécurisé, du point de vue technique, sera exposé si l’utilisateur choisi admin/admin comme identifiant et mot de passe.
A l’inverse, à quoi bon avoir un identifiant et un mot de passe super complexe à déterminer si comme le rappelle Julio, le site a des failles CSRF ou autres joyeusetés du même genre ?
Petite question subsidiaire : est-il possible de changer facilement les dossiers de WP (wp-content, wp-admin, wp-includes) ?
Merci en tous cas pour toutes ces précisions. C’est dans le débat des idées que l’on avance ;)
@ acs04, oui c’est facile, regardez mon article sur les secrets du wp-config.php
Facile mais si c’est dans un but de sécurité, c’est inutile.
@Marie-Aude : merci ;)
@Julio : pour ma culture personnelle essentiellement.
Merci pour cet article, j’utilise wordpress quotidiennement et ce n’est pas prêt de changer, malgré ce qu’on peut reprocher à ce CMS.
Bonjour et merci pour l’article comme pour tous les commentaires qui ajoutent le plus.
Ce qui manque à mon sens à WP c’est une explication à partir d’exemples de sites créés pour que ce soit plus parlant et savoir s’y retrouver pour quelqu’un comme moi, de pas néophyte mais pas non plus développeur, pour savoir quelle est la meilleure solution et la moins longue à mettre en place pour un site multilingue.
J’ai acheté WMPL mais je ne parviens pas à savoir comment m’en servir, j’ai installé xili mais je ne parviens pas à piger comment il fonctionne pour créer le site trilingue qu’on me demande, je ne sais pas s’il ne vaudrait pas mieux créer trois WP avec FR EN PT par exemple et ensuite carrément faire la traduction manuelle de tout.
Vos explications que ce soit sur WMPL et Xili m’ont donné quelques pistes pour mieux comprendre le but recherché mais pas pour les utiliser.
Plus ça vient, plus on me demande de site multilingues et je rêve de savoir comment m’y prendre et progresser moi même et pour les projets à venir.
J’achète les modèles pro qui sont indiqués comme multilingues, en me disant qu’ils sont déjà un peu plus complets et prêts à l’emploi, mais apparemment j’ai loupé une marche dans l’apprentissage pour aller au bout de la mise en oeuvre.
Si vous avez la route des lumières à me présenter, merci d’avance !
Je peux vous faire une démonstration sur un site :)
Ce serait vraiment super, oui avec un grand merci d’avance ! :)
Je sais que je réponds a un article de 2012, mais concernant le multilingue, j’étais également un adepte de WPML, puis j’ai découvert en ce début d’année le plugin “Polylang” qui a pour principaux atouts :
> Gratuit
> Admin : un seul plugin à installer (au moins 2 pour WPML)
> Admin : au moins aussi simple d’utilisation que WPML
> Admin : interface en français
> Admin : un seul menu admin pour gérer les traductions et les paramètres du plugin
> Fichiers : la traduction du thème passe par des fichiers po/mo, ce qui permet de conserver/réutiliser les traductions de wordpress en wordpress (pas enregistré en base, mais fichiers dans le thème lui-même)
> Moins lourd et moins gourmand en ressources que WPML
Quelqu’un d’autre l’a testé ?