WP Rocket sur EasyEngine

WP Rocket est un plugin de cache très efficace. Développé à la base pour fonctionner parfaitement sur les serveurs Apache, il est également possible de l’utiliser sur Nginx grâce à un script disponible sur Github créée par Maxime Jobin.

EasyEngine est un moyen de se faciliter la vie pour gérer un serveur web tournant sur Nginx à l’aide de commandes vous permettant de créer des sites pré-paramétrés très rapidement.

Je vous conseille d’ailleurs l’excellent article sur EasyEngine de Geoffrey Crofte sur le sujet.

Utiliser WP Rocket avec EasyEngine

Rendez-vous sur le page Github du script.
Suivez simplement les étapes énoncées dans le ReadMe jusqu’à l’installation.

Une fois le script cloné dans votre répertoire nginx, générez votre configuration avec les instructions de Maxime,

Un fichier default.conf sera crée dans ce répertoire. Il ne vous reste qu’a copier ce fichier (en le renommant par exemple wp-rocket.conf) dans les répertoire « conf » de vos sites crées avec EasyEngine.

Donc dans vos répertoires : 

Vérifiez que votre configuration fonctionne avec 

Puis, si la commande ne vous retourne pas d’erreurs, reloadez le service Nginx pour appliquer la configuration.

Voilà, c’est tout, enjoy !

Aller plus loin.

Rien de bien compliqué, je pense pour améliorer ce fonctionnement, qu’on pourrait envisager de créer un template pour EasyEngine pour installer directement ce script à la mode EasyEngine, en utilisant par exemple : « ee site create domaine.com –wprocket » ;)

Pourquoi la communauté WordPress a besoin de plus de designers

« Des idées, tout le monde en a. Souvent les mêmes. Ce qu’il faut, c’est savoir s’en servir » – Coluche.

Et à ce niveau là, la communauté WordPress est plutôt prolifique, au vu du nombre de plugins qui sortent régulièrement pour la plateforme.

La facilité de créer des plugins pour WordPress y est aussi pour quelque chose. Beaucoup de développeurs se lancent alors dans l’aventure et créent leur petit plugin pour améliorer / modifier / ajouter des choses à WordPress. Continuer la lecture de « Pourquoi la communauté WordPress a besoin de plus de designers »

CMS, pour ou contre, l’éternelle question

Je tombe régulièrement sur des posts sur des forums, de personnes souvent nostalgiques du bon vieux temps des sites web réalisés « à la main » en bon vieux php et le tout intégré en tableaux, parce que le web, « c’était mieux avant ».

Le tout regroupé sous la bannière : « Les CMS, c’est pour ceux qui ne savent pas coder ! »

On dirait en lisant ces posts, que développer sur une base CMS (type WordPress) serait équivalent à être un singe savant sachant bouger des cubes, pour que le CMS comme par magie, te vomisse un site.

Stop the Hate

Soyons réalistes 2 minutes, la plupart du temps ce sont des réactions de personnes frustrées, qui ont installé WordPress (par exemple) et qui ont dû passer 20 minutes avec l’outil en main pour essayer de faire un petit truc, sans prendre 5 minutes, ni pour lire la doc, ni pour s’intéresser à la façon de faire et de coder sur ledit CMS.

Quand ce ne sont pas des personnes frustrées de la direction actuelle du web (estimant que ce n’est pas le bon sens) ce sont des personnes qui ne souhaitent pas vraiment se remettre en question et qui ont l’égo suffisamment grand pour se positionner au dessus de tout ça, estimant qu’elles ont raison.

Ils campent donc sur leur façon de faire en brandissant le « c’est fait en php, je connais le php, ça doit marcher avec mon code », en partant de toute façon du postulat de départ que c’est n’est pas bien et que le « fait à la main sera 100 000 fois mieux »

Pas uniquement une histoire de code

Alors oui pour certaines choses, du bon vieux php (ou autre, je ne suis pas sectaire) sera bien plus efficace qu’un CMS. Je ne prône pas l’utilisation de ce type d’outils pour faire tout et n’importe quoi non plus, tirez trop sur un élastique et il cassera à la tête.

C’est avant tout une histoire de réponse au besoin. Pourquoi s’embêter à recréer un moteur de blog complet quand on peut utiliser WordPress, qui est fait expressément pour répondre à ce besoin ?

Faire du custom c’est bien et des fois nécessaire car plus simple et plus rapide qu’en utilisant un CMS. Mais pas toujours…

Comment pouvez-vous dire que vous, tout seul en 1 mois, pouvez faire mieux que 400 personnes qui travaillent exclusivement là dessus depuis 10 ans ?

Ça va votre égo ?

Un refus de standards ?

Pourquoi serait-il néfaste d’utiliser une base de code, une façon de coder, une architecture commune à d’autres développeurs, qui plus est très bien documentée ? Encore plus lorsque les projets web ont tendance à passer de main en main en développeurs au fil de leur évolution ?

Parce que soyons réalistes un peu, personne n’a envie d’aller chercher dans les méandres de votre architecture « full custom trop bien qui rox » et non documentée parce que « Y’a des commentaires dans le code ça suffit à un VRAI développeur pour comprendre » — Comprendre : « JE suis un dév génial, les autres c’est tous des nuls »

Ça va votre égo ?

© Fait « à la main »

Pour commencer il faudrait arrêter de se masturber sur des lignes de code. C’est mignon et le travail bien fait c’est super important, mais quand la beauté du précieux code source devient plus important que le message ou l’info que tu veux partager via le site / service que tu crée, il y a un sérieux problème.

Si le seul argument que tu as pour défendre ta réalisation c’est : « Je l’ai fait à la main », c’est triste.

Car oui, cher développeur qui est peut-être en train de lire ce post, ton précieux et substantifique code ne servira absolument à rien si personne n’est capable d’utiliser le produit/service dont il est la source.

N’oublions pas qu’un site web, on le fait rarement juste pour soit et pour la beauté du code devant la gloire éternelle de l’autel du code qui rox.

Qui va l’utiliser ?

Souvent, tu as un client en face, pas techos pour un sou, qui doit s’avoir l’utiliser, le mettre à jour, le faire évoluer légèrement. Va lui montrer des fichiers HTML et CSS sur un serveur FTP.
Il a pas obligatoirement envie de « subir » une formation complète sur PHP/ HTML / CSS / JS pour modifier les prix sur la carte de son restaurant. Et plus important : il ne devrait pas avoir à le faire quand d’autres solutions existent.

« Oui, ben quand il veut changer quelque chose, il m’appelle et je facture ». Belle mentalité de connard (désolé il n’y a pas d’autre mot) qui « tient » son client par la faiblesse technique de ce dernier et qui en profite pour facturer 100 balles un changement qui à dû lui prendre littéralement 10s.
Spoiler : ce client décampera très vite quand il comprendra que sur d’autres plateformes, il peut le faire tout seul sans se prendre la tête.

Quand c’est un site perso, fait comme bon te semble ! Peut-être que tu en aura marre au bout d’un moment de passer plus de temps sur le code de ton blog que sur les articles que tu écris dessus qui eux, sont la vraie raison d’existence du site.

Réinventer la roue

Tu me diras qu’il est tout à fait faisable de créer un back-office sur mesure simple d’utilisation. Oui, et tu as parfaitement raison. Sauf qu’en fait, tu récrées en faisant cela ton propre CMS (n’oublions pas que CMS veut dire : Content Management System).

Réinventer la roue c’est sympa et certains projets ont vu le jour grâce à ce genre d’initiatives, mais réinventer la roue à chaque projet est une perte de temps, d’énergie et donc d’argent non négociable. Parce que, entre nous, on copie/colle toujours des bouts de code….non ? Et puis créer un CMS complet pour un client qui soit plutôt agréable à utiliser et à regarder, c’est pas la mince affaire.

La question n’est pas de savoir si utiliser un CMS est une bonne chose ou non, la question est de savoir à quel prix, pour quelle utilisation et pour quel client réaliser du full-custom est encore intéressant ?

Un projet full-custom avec un back-office plaisant, (où un UX/UI Designer à travaillé dessus un peu donc..), le tout utilisable sans être sorti de polytechnique n’est pas une chose aisée à réaliser, et coûte un sacré paquet d’argent à être réalisé.

Alors oui, je t’entends déjà dire « on peut utiliser bootstrap et ça fait un truc joli », certes, mais l’architecture du back-office et l’ergonomie, bootstrap ne peut pas s’en occuper.

Tu veux vivre ou écrire du code ?

C’est bête, mais c’est à ça que ça se résume. Nous vivons dans une époque où peu de gens peuvent investir des sommes à 5 chiffres pour un « petit site vitrine, joli, où je peux modifier les contenus assez facilement de temps en temps ».

Je dis 5 chiffres parce qu’à mon sens réaliser le CMS + le site + le design (je parle même pas du suivi de projet et le reste qui se facture également) du site qui tient un tant soit peu la route en dessous me parait hautement improbable. Encore une fois, il s’agit d’une généralité, pas la peine de donner des exemples dans les commentaires de comment vous avez réalisé un éditeur de carte de restaurant super simple avec 3 inputs et 2 boutons.

Donc tu as le choix, cher développeur « PHPFULLCUSTOM4life » soit, ne pas compter tes heures (comprendre : ne pas les facturer) à créer ton propre CMS trop cool pour tout tes projets. (CMS qui potentiellement se fera démonter par ton successeur qui le trouvera tout pourri, et donc installera WordPress à la place) Soit, utiliser un ensemble de briques existantes et éprouvées, et développer sur ces pierres angulaires, de plus bien documentées pour gagner correctement ta vie. Comprendre : ne pas gagner un smic pour 80h / semaine.

Parce qu’un CMS Full Custom, si il n’évolue pas, devient vite obsolète, et face aux nombres de cas et possibilités que tes clients te demanderont, il deviendra une usine à gaz horrible et inutilisable. Et l’évolution… c’est des heures de travail.

Il s’agit d’un équilibre à trouver, entre la flexibilité, la rapidité de réalisation et la marge dégagée, une histoire de ROI en somme.

Je m’adresse beaucoup à des développeurs freelance à travers cet article, mais c’est la même chose pour des petites agences. Payer tout un pôle « CMS maison » n’est pas toujours envisageable quand la majorité des clients sont des PME locales ou régionales (ce qui représente souvent la grande majorité des clients). Je ne parle par contre pas des agences qui ont développé une base de code avec un template et le refourguent à tout leurs clients en changeant les couleurs hein…

L’argument de merde

J’en vois venir dans le fond, brandissant le drapeau de la qualité du code front-end, symbole visible de travail bien fait.

Si tu me dis que des CMS comme WordPress, Drupal etc.. te sortent du code dégueu, je te renverrais simplement à une question : qui produit le code affiché en front ?
Le développeur qui a crée le template, qui utilise les fonctions du CMS, rien de plus.

Le code front est horrible ? Les développeurs ont mal fait leur travail, tout simplement. Le CMS n’aura rien à voir là dedans, il n’ajoute pas de code pourri juste pour le fun, il y a toujours une raison.

C’est de la faute du marteau !

Ce n’est pas l’outil qui décide si il est bien utilisé ou pas. C’est la personne se servant de l’outil qui peut faire des choses bien ou « mal » avec. Personne n’a jamais insulté son marteau en disant « Pourquoi tu plantes mal des clous dans le mur?! »

Alors ? Pour ou contre ?

Ça dépends©.

Tout dépends au final du projet et du client. C’est là que réside la réponse à cette question : dans l’étude du besoin et dans la réponse à y apporter.

Là ou il y a 15 ans, une page faite en tableaux et en php suffisait largement, à l’heure actuelle il est demandé bien plus (de base) à un site web.

Le code full-custom n’est pas mort loin de là, beaucoup de projets, en évoluant arrivent sur du full-custom, car les fonctions de base du CMS utilisé ne suffisent plus ou deviennent trop compliquées.
Certains sites au départ modestes commencent sur un CMS, puis au fur et mesure évoluent dans de grosses solutions, bien plus complexes et répondants au besoin qui à évolué.

Le web et la façon de faire des sites changent, en bien ou en mal, mais s’adaptent aux contextes réels actuels, comme celui de l’économie.
Ne pas s’adapter, c’est être laissé sur le côté et mourrir.