Aujourd’hui, j’accueille Florian Tiar de chez WP Stratégie, anciennement développeur dans l’agence WordPress parisienne BeAPI. Rien que ça !
Florian nous offre aujourd’hui un retour d’expérience inestimable en matière de développement avec WordPress ! J’ai moi-même beaucoup appris en lisant ses recommandations en avant-première.
N’oubliez pas d’encourager Florian pour son partage d’informations en vous abonnant à son site et en relayant massivement cet article. Régalez-vous bien 😉
- Versionner son code
- Déployer son code via SSH avec GIT de manière simple et sûre
- Un environnement de préproduction
- Contrôler les mises à jour WordPress
- Empêcher toute modification de code
- Travailler avec un IDE de qualité
Rêvez-vous de devenir un développeur WordPress de qualité ?
Pour cela, quoi de mieux que de suivre les méthodes utilisées par des agences web reconnues du milieu ?
En tant que freelance WordPress, vous souhaitez améliorer vos processus pour être plus efficace, optimiser votre temps et gérer plus facilement vos projets.
Vous vous êtes sûrement confrontés à plusieurs problèmes.
Les sites que vous avez développés sont de plus en plus difficiles à maintenir.
À chaque bug ou évolution, c’est un peu la panique pour mettre à jour le code et déployer sans effet de bord.
Pas de stresse, je vais vous révéler quelques bonnes pratiques et outils que j’ai découverts chez Be API (l’agence WordPress n°1 en France) afin d’améliorer sensiblement la maintenabilité de vos projets.
— Dans cet article ↓ —
- 1 1. Versionner son code
- 2 2. Déployer son code via SSH avec GIT de manière simple et sûre
- 3 3. Un environnement de préproduction
- 4 4. Contrôler les mises à jour WordPress
- 5 5. Empêcher toute modification de code
- 6 6. Travailler avec un IDE de qualité
- 7 Conclusion sur les bonnes pratiques de développement avec WordPress
- 8 Vous aussi, proposez votre article !
1. Versionner son code
Si vous avez raté cette étape, c’est surement la plus importante.
Vous vous rappelez sans doute ce moment gênant ou un client vous demande telle fonctionnalité.
Vous la développez presque totalement, mais le client change de vision et vous demande autre chose.
Alors vous supprimez ce bout de code.
Sauf que, jamais deux sans trois, le client change à nouveau d’avis et préférait votre code précédent, malheureusement c’est trop tard, vous l’avez déjà supprimé.
Pour contrer ce phénomène, il existe le versioning.
Le principe du versioning est simple.
Il permet de sauvegarder son code à un instant T.
Ainsi, durant toute la vie du projet, vous avez un historique complet des changements de code effectués.
Vous avez introduit un bug dans la version 2.0 ? No Stress, revenez simplement au code de la version antérieure.
Cela évite également des mauvaises pratiques de certains développeurs qui laissent traîner du code qui n’est plus utilisé, ou qui se contentent de commenter toute une partie de code pour la cacher.
Pour versionner son code, il existe plusieurs outils. GIT est le plus célèbre d’entre eux.
Vous pouvez sauvegarder votre code sur des espaces cloud tels que Github, Gitlab ou Bitbucket que je vous recommande pour ses dépôts privés gratuits.
Ensuite, lorsque vous travaillez sur votre projet, vous pouvez choisir de passer par la ligne de commande ou d’utiliser un client GIT tel que GitKraken.
Appliqué à WordPress, il convient de ne pas versionner le dossier upload, et de les sauvegarder régulièrement plutôt (avec une extension par exemple).
Bien sûr, si vous n’avez jamais travaillé avec GIT, je vous conseille vivement de suivre des tutoriels en ligne pour apprendre à l’utiliser progressivement.
2. Déployer son code via SSH avec GIT de manière simple et sûre
Je vous ai parlé des bénéfices d’utiliser GIT sur vos projets pour versionner votre code.
Mais si je vous disais que ça va vous faciliter grandement vos déploiements également, ce serait plutôt agréable non ?
Vous avez déjà tous eu ce problème en essayant d’effectuer un déploiement via FTP.
Vous vous trompez de fichier, vous écrasez un fichier important que vous n’avez plus en sauvegarde, pas moyen de revenir en arrière.
Avec GIT c’est beaucoup plus simple, car votre code est sauvegardé à chaque étape !
Lors de la première mise en production par exemple, connectez-vous en SSH sur le serveur (le SSH est disponible sur les offres Pro OVH pour info).
Effectuez un “git clone” de votre projet. Et voilà ! Il n’y a plus qu’à ajouter votre base de données et à remplacer les URL et votre site tournera sans problème.
Par la suite, quand vous allez déployer de nouvelles versions, il suffira juste de se connecter sur le serveur, dans le dossier racine de WordPress et d’effectuer la commande : « git pull » pour récupérer la dernière version de votre code.
Encore mieux, je vous conseille d’utiliser les tags GIT afin d’avoir des repères clés de votre code.
Par exemple, au moment de la première MEP (mise en production), créer un tag 1.0 sur la master.
Puis, lors d’une prochaine évolution quelques semaines plus tard, vous allez créer un tag 1.1.
Lors du déploiement, plutôt que de faire un “git pull” hasardeux, vous allez déployer le tag 1.1 : « git checkout tags/1.1 ».
Comme ça, s’il y a un problème sur le site lors du déploiement, pas de panique, vous revenez immédiatement sur le tag précédent : « git checkout tags/1.0 ».
En résumé, il n’y a plus d’erreur humaine à écraser un fichier qu’il ne fallait pas, vos déploiements sont sécurisés et beaucoup plus rapides, et en cas de hack vous savez immédiatement les fichiers qui ont été modifiés grâce à l’historique GIT.
C’est simple, depuis que j’ai adopté cette méthode, je ne peux plus m’en passer, je demande à chaque fois à tous mes clients un hébergement avec accès SSH.
Vous aussi, vous êtes en droit de travailler dans de bonnes conditions !
Pour aller plus loin sur le sujet, je vous conseille de lire cet article de Maxime Culea (développeur chez Be API) sur les déploiements GIT, qui a fait une conférence sur le sujet au Wordcamp Paris 2016.
3. Un environnement de préproduction
Un souci assez récurrent quand vous n’avez pas d’espace de préproduction, c’est de vouloir déployer en production un code qui fonctionne chez vous en local mais qui casse le site de prod.
En général votre environnement de dev (local ou non) n’a pas les mêmes spécificités que celui de production : version MySQL, PHP, manque de modules PHP, taille de stockage, mémoire vive, etc.
Toutes ces différences peuvent donc entraîner ces écarts de rendu entre votre site de dev et votre site de production.
C’est pourquoi il est souvent conseillé d’avoir un environnement de préproduction de disponible.
Le principe est simple, il s’agit d’une copie de la production sur le même serveur.
Par exemple, on crée un sous-domaine « preprod » sur le domaine principal.
On effectue la copie du site de prod sur le site de preprod (revenir au grand 2 de cet article afin de privilégier des déploiements git), et on pense à changer les URL.
Ainsi, à chaque nouveau déploiement de production, on passera d’abord par la préproduction afin de s’assurer que rien ne casse.
Vous évitez ainsi tout conflit potentiel avec le client qui pourrait perdre patience si son site est indisponible trop longtemps.
4. Contrôler les mises à jour WordPress
Un autre souci potentiel qu’on peut éviter avec quelques bonnes pratiques, ce sont les problèmes de mises à jour WordPress.
Que ce soit le coeur, les extensions ou les thèmes, c’est autant de risques potentiels de casser son site.
En effet, certes ces mises à jour sont très simples à effectuer, mais n’importe quelle mise à jour peut réellement faire planter votre site !
Voici les actions à mettre en place :
1-Empêcher les mises à jour WordPress en production
Ça vous évitera que le site soit planté par la faute du client qui voulait tout mettre à jour.
Comment faire ?
Ajouter cette constante au wp-config.php :
define( ‘WP_AUTO_UPDATE_CORE’, ‘minor’);
Ainsi, on autorise uniquement les mises à jour de sécurité mineures de WordPress, cela permet d’être sûr qu’il n’y aura pas d’effet de bord sur le site.
2-Empêcher les mises à jour ou installations d’extensions
Toujours dans le même fichier, ajouter cette constante pour empêcher l’installation et la mise à jour des extensions ou thèmes !
define( ‘DISALLOW_FILE_MODS’, true );
→ Plus d’infos sur le Codex WordPress.org.
5. Empêcher toute modification de code
Par défaut, le backoffice de WordPress permet de modifier directement le code PHP des extensions et des thèmes.
Cette fonctionnalité est très dangereuse, car la moindre erreur de syntaxe PHP plantera votre site et donc l’accès au backoffice.
Pour désactiver ça, il faut utiliser la constante suivante (uniquement si vous n’avez pas défini la constante DISALLOW_FILE_MODS à true) :
define( ‘DISALLOW_FILE_EDIT’, true );
6. Travailler avec un IDE de qualité
Un IDE de qualité (environnement de développement) est un “must have” pour du développement WordPress professionnel.
J’ai découvert à Be API le logiciel PHP Storm créé par JetBrains.
Très complet, ce dernier possède une intégration WordPress qui va vous faciliter le quotidien.
Lorsque vous verrez un hook dans le code de type : add_filter ou add_action, vous pourrez directement sauter vers le code initial du apply_filters ou do_action et ainsi comprendre comment fonctionne le hook, dans quelle fonction il est utilisé, combien de paramètres possède-t-il, etc.
Même chose pour les fonctions du coeur de WordPress.
Vous avez besoin de créer un article dans le code avec la fonction wp_insert_post ? Un simple CTRL+B en survolant la fonction vous permet de sauter à la déclaration de cette fonction.
Ainsi, vous allez être au plus proche du cœur. Vous comprendrez un peu mieux comment fonctionne WordPress et comment en tirer profit au mieux.
Vous commettrez également beaucoup moins d’erreurs de code, car vous connaîtrez les paramètres obligatoires de la fonction, ceux facultatifs, les valeurs de retours attendues par la fonction, etc.
Autres fonctionnalités intéressantes : l’upload automatique à chaque modification de code vers un serveur distant, la capacité de voir l’historique git, le code sniffer, le débogage pas à pas, etc.
Conclusion sur les bonnes pratiques de développement avec WordPress
Nous avons vu certains processus de qualité à mettre en place pour professionnaliser davantage notre travail de freelance.
Parmi ces processus, nous avons le versioning qui va vous permettre à la fois de sauvegarder votre code, garder un historique et pouvoir effectuer des déploiements rapides et sécurisés en SSH.
Nous avons aussi vu l’intérêt d’avoir un environnement de préproduction afin d’éviter des déploiements de bugs.
On a également sécurisé davantage le site de production en contrôlant les mises à jour WordPress et en empêchant toute modification de code côté backoffice.
Enfin, on a vu les différents bénéfices directs que pouvaient nous apporter un IDE de qualité tel que PHP Storm.
J’espère que cet article vous aura plu, n’hésitez pas à le compléter avec vos propres conseils tirés de votre expérience de freelance.
Si vous souhaitez aller plus loin, je vous propose un guide GRATUIT en 15 étapes pour avoir un site WordPress rapide, optimisé et sécurisé comme un pro.
Il contient de nombreux conseils pour apprendre à choisir un thème de qualité, mais également configurer et automatiser certaines tâches de son blog, etc.
Depuis 2009, je vis confortablement, grâce à mon entreprise sur Internet. Je me suis fait tout seul, sans filet de sécurité et sans[...]
Excellent article en effet que les bidouilleurs du web devraient analyser et prendre en compte, moi le premier ;). J’entends pas bidouilleur, ceux qui ne sont pas développeurs de formation et apprennent sur le tas, sans toujours connaitre les meilleurs process. Tout ca fonctionne sous Windows ou il faut être adepte de Linux ?
Après… beaucoup d’autodidactes sont de véritables rockstars 🙂
Pour la technique, puisque c’est l’article de Florian, je vais le laisser répondre… et puis de toute façon, Windoze, j’y connais rien moi, suis sous Mac.
On est bien d’accord que les autodidactes peuvent aussi être super forts… Et qu’on peut aussi faire de très belles choses sans les process les plus aboutis. Disons que c’est un panel de compétences supplémentaires qui peuvent s’avérer utiles…
Yes, un petit investissement en temps d’apprentissage pour un gros gain de temps par la suite ? 🙂
Merci pour ton message 🙂
C’est tout à fait possible sous Windows. Tu pourras utiliser Git, SSH (via des clients type xShell, Putty), PHP Storm, etc.
Perso j’aime bien utiliser Ubuntu que je trouve plus fluide et plus developer friendly.
Bonjour Florian, Merci pour tes conseils. De mon côté, je n’ai jamais sauté le pas de me lancer dans le versionning/git… (et oui, je bidouille -.-‘ )
J’ai une grosse question qui subsiste en fait ! Tu versionnes ton code, très bien. Mais comment tu versionnes ta base de données pour :
1 – conserver des données à jour, du genre, des factures WooCommerce à pas perdre absolument… quand tu mets en prod un développement qui touche aussi à la db
2 – comment tu fais pour mettre à jour la structure de ta base de données lorsque tu déploies tes versions tags 1.2, 1.3, etc. par exemple, si tu as des meta_options à ajouter quand tu codes un plugin WP, etc. etc.
Je sais pas si je suis clair. Mais souvent, lorsqu’on avance sur des projets preprod en WordPress, on fait évoluer le contenu en DB tu es d’accord ? Bon moi, rien que le CSS je le mets en DB via des plugins type JetPack… Des bouts de jQuery aussi… Après, c’est peut-être pas l’idéal. Tes recos concernes peut-être UNIQUEMENT le code source (templates php, functions…) ?
Bon après, je suppose que le mieux est de se lancer sur GIT, mais si tu pouvais donner quelques détails sur le versionning de db, ça serait super apprécié ! <3 Merci !
Très bon article.
Petite chose à ajouter pour le versionning, c’est intéressant d’utiliser la méthode de travail « Git Flow ».
Concernant PhpStorm je me tue à le dire à tout le monde, c’est de loin le meilleur outil de travail que j’utilise. Il vaut largement son prix et est vite rentabilisé grâce à une meilleure productivité.
Popopolo’ Premier commentaire de Spout sur mon blog 😀 Maintenant, je peux mourrir en paix 😀
ah oui ça vaut le coup de le souligner ! j’ai essayé phpStorm mais le skin est tellement moche, enfin s’l permet de faire de l’autocomplétion pourquoi pas, le seul truc que mon Sublimet Text n’arrive pas à bien faire en plus de gitter.
Heureux que l’article te plaise.
Effectivement, pour améliorer son workflow git, rien de tel qu’un bon git flow 🙂
Je ne peux que plussoyer que ton message à propos de PHP Storm.
Vous payez entre 119$ et 199$ par an ou j’ai raté le bon plan ? 😀
Bonjour Guillaume,
Effectivement je ne parle pas de la base de données. Ce n’est jamais évident de ce côté là malheureusement.
Pour la preprod, dès que je vois que les données sont un peu trop dépassés, je refais une copie de la BDD de la prod vers la preprod.
Mais sinon en général , je répercute les actions backoffice en prod une par une (même si c’est long). Ou pour les gros changements comme les meta options que tu cites, je vais avoir tendance à développer un script maison
Après, il y a VersionPress : https[:]//versionpress.net/ que je n’ai jamais testé pour l’instant (encore en beta), qui propose du merge de base de donnée.Tu a aussi Migrate DB Pro ou WP Sync DB.
Je vais peut être en profiter pour les tester 🙂
Merci pour tout ce partage ! 😮 Si tu veux, tu es le bienvenu pour un article sur VersionPress vs Migrate DB vs WP Sync DB, comme tu t’en doutes 😉 😀 😀
Après @Guillaume si tu utilises un sous-domaine tampon de préprod supplémentaire comme l’a expliqué Florian, tu peux, sur une tape de 1 à 3 ou 4 heures, checker tes données manuellement sans rien casser et faire quelque chose de quasi transparent pour ton client, par exemple, tard dans la soirée… 🙂 On est encore loin des galères qu’on peut rencontrer avec des CMS comme Prestachups ^_^ y a des boutiques qui doivent être passées en maintenance plusieurs jours pour update le truc ! 😮
Bonjour et merci pour cet article.
Comme tu le dis dans ton 6ème paragraphe, l’environnement de développement est très important. Mis à part l’IDE, l’environnement de travail comprend aussi la manière de faire tourner son site de dev/preprod… Quelle méthode utilises-tu (par ex. machine virtuelle en local, serveur de dev distant, autre…) ? Et as-tu des outils de prédilection ?
Merci pour tes conseils.
Benoît, trop fort le slogan de ton agence… même si j’ai du le lire 2 fois pour le comprendre 🙂
Florian va répondre, mais je crois qu’il préconisait un sous-domaine sur le même serveur que le serveur de production, si j’ai bien compris la question.
Merci Nicolas 🙂 !
Effectivement pour une preprod, un sous-domaine sur le serveur de production est recommandé. Mais je me demandais si durant la période de développement, un travail en local – possible sans connexion internet (lors d’un voyage en train par exemple) – n’est pas préférable. Et du coup quel sont les outils « références » à son avis (Vagrant et Virtualbox par exemple)… J’ai du mal à me fixer sur ce point et je cherche des conseils !
Salut, merci pour ton commentaire.
Personnellement, je n’ai pas encore la stack parfaite côté site de développement. J’alternais entre local (XAMPP basique) et serveur de dev distant. Les deux ont leurs avantages et leurs inconvénients malheureusement.
J’ai aussi testé Local by Flywheel dernièrement qui gère les VM (avec Virtual Box) lui même donc c’est plutôt appréciable.
Donc moi aussi j’ai du mal à me fixer sur ce point haha 🙂
Merci pour ta réponse ! Je ne connaissais pas Local by Flywheel, je vais aller jeter un oeil ! Peut-être le chaînon manquant dans mes différentes méthodes de travail ? 🙂
Merci Merci ! juste pour la ligne de code empêchant les mises à jour auto de WP
Bonjour,
Je découvre cet article avec du retard.
Je suis tombé dessus en effectuant des recherches pour une problématique bien précise que je n’ai pas réussi à résoudre à cette date.
Admettons que je travaille sur une refonte de site. Je crée un site de stagging et je travaille dessus. Ceci-dit, pendant la phase de développement, le site de prod continue à vivre.
Existe-t-il une solution pour rendre les 2 sites iso en contenu avant le passage en ligne? J’ai eu ce problème sur un petit site donc j’ai pu me permettre de produire les contenus en double mais j’aimerais pouvoir rationaliser ce genre de tâche.
Merci d’avance pour votre aide.
Nicolas
Bonjour Nicolas,
Tu as mis le doigt sur une problématique majeure en effet, sans doute l’une des parties les plus complexes.
Il n’y a pas de solution simple clairement, fusionner des contenus différents sur une même base est très complexe, car imagine que ton site en production tourne encore pendant que ton site de staging est alimenté également, il y aura sans doute des identifiants uniques similaires mais avec du contenu différent.
Sauf si ce n’est que des articles et là c’est très simple tu utilises l’outil d’export et d’import natif.
Sinon j’avais aussi écrit un article sur VersionPress, un outil qui censé faire des fusions douces entre deux sites, voici le lien : https[:]//wpchannel.com/wordpress/tutoriels-wordpress/synchroniser-base-donnees-wordpress-versionpress/
Il y a aussi WP Migrate Pro (payant) qui permet de faire ce genre de chose je crois, mais ca fonctionne jamais pour 100% des données il me semble. Ils expliquent d’aileurs assez bien concrètement pourquoi c’est un sujet touchy ici : https[:]//deliciousbrains.com/wp-migrate-db-pro/doc/how-it-works/