Rebuild vs Upgrade - besoin de pointeurs, de conseils
Je sais que je ne sais pas ce que je ne sais pas à propos de Wordpress. :-)
Je déploie de grands sites Web Joomla depuis plus de 10 ans. Mon équipe a fait des sites Wordpress simples mais rien de super personnalisé.
J'ai besoin de quelques indications générales sur la reconstruction d'un site Web Wordpress.
Détails: Notre bon client du tourisme possède deux sites Wordpress de grande taille, populaires et personnalisés, qui doivent être mis à niveau ou reconstruits. C'était sa première itération avec WP en 2011. Le développeur l'a construite à l'aide de la solution WPEngine. Puis, en 2015, une société de développement différente a procédé à une reskin, qui a conservé le code d'origine. Nous avons pris en charge l'hébergement, le support et la maintenance en 2016, ce qui incluait le découplage de WPEngine.
Dans l’ensemble, le site Web actuel fonctionne bien. 80% du contenu livré est mis en cache via Cloudflare, ce qui est très important, car il s’agit du site le plus occupé de mon serveur en été. Cependant, les sites actuels ne supportent pas PHP7 même si la base de code WP et les plugins sont à jour.
Au cours de l’année écoulée, j’ai convaincu le client que nous devions reconstruire ses WP sites Web afin d’inclure du code frais, une apparence et une stratégie promotionnelle. Les autres nouvelles fonctionnalités importantes que je propose sont l'utilisation de la conception multisites et responsive. Les éléments de contenu, tels que les images, devront être refaits pour accueillir un nouveau design "grande image".
Le modèle existant concerne: 1. Non réactif. 2. Les restes du moteur WPE peuvent être trouvés dans le système de fichiers. 3. Les éléments de présentation clés sont codés en dur, tels que les droits d'auteur et les informations de contact dans le pied de page lorsque le client ne peut pas changer. 4. Je ne connais pas et ne comprends pas bien la stratégie utilisée par le développeur pour la première version qui régit encore ces sites Web. 5. Je ne sais pas quels plug-ins installés sont réellement utilisés ni quels plug-ins sont hérités et doivent être désinstallés.
Le modèle existant a 11 cpts. Il y a 16 groupes de champs personnalisés ACF avec un total de 36 champs personnalisés.
Des questions:
D'après ma description ... Pensez-vous qu'une reconstruction "à partir de la base" est nécessaire? J'entends par là tout nouveau et migrer sur le contenu. OR pensez-vous qu'il serait préférable de cloner le site et de développer un nouveau modèle?
Comment les multisites joueraient-ils dans cette reconstruction ou mise à niveau?
Merci pour tout conseil ou perspicacité.
après avoir fait quelques reconstructions moi-même, j'ai vu ma part de situations d'horreur parce que certains développeurs en font un gâchis :) Il est difficile de vous conseiller quel est le meilleur moyen de procéder sans examiner le code/la configuration/les problèmes et sans connaître le budget disponible.
- Peut être corrigé dans le modèle si vous avez quelqu'un qui sait ce qu'il fait.
- Quels restes? Juste des fichiers ou aussi des bases de données?
- Ce genre de choses peut être dynamisé à l'intérieur d'un modèle existant.
- Alors mieux vaut le savoir ou le refaire 'correctement' et la façon dont vous le comprenez.
- Tout développeur avisé devrait pouvoir évaluer cela dans un environnement local avec un peu de débogage.
Je suis un partisan des reconstructions, car vous pouvez faire tout ce que vous voulez et ne pas avoir à vous soucier du code hérité, mais je pense que vous auriez besoin de quelqu'un pour évaluer le code pour vous donner un puits. réponse fondée.
Mon expérience passée avec WP sites: lorsqu'il s'agit d'une installation volumineuse (plus de 10 plugins, plus de 500 posts/pages/CPT), si vous vérifiez le thème et les plugins et constatez qu'ils sont étroitement couplés (comme vous le dites avec le code WPE) il est généralement utile de reconstruire à partir de la base. Comme vous l'avez dit, il est difficile de savoir quels plugins sont réellement utilisés.
Vous pouvez soit tout copier sur un site intermédiaire, désactiver les plug-ins et exécuter divers tests sur le site jusqu'à ce que vous puissiez déterminer ce qui est réellement utilisé, puis "nettoyer" ce qui existe déjà ... ou véritablement reconstruire. Normalement, je recommanderais de reconstruire haut la main, car la technologie a beaucoup changé en 7 ans et les meilleures pratiques de codage. Mais votre timing est intéressant, dans la mesure où WordPress 5.0 devrait sortir cette année, avec l’arrivée d’un éditeur complètement nouveau appelé Gutenberg. Parce que ce sera un changement majeur, je pense que vous seriez mieux avec une autre approche que j'ai adoptée dans ce genre de chose: reconstruire, mais reconstruisez-la comme elle est déjà, avec un plan pour reconstruire à nouveau dans l'année qui suit. vous en avez appris davantage sur les rouages de la fonctionnalité du site.
Tout d’abord, testez le site, découvrez ses capacités et cartographiez les cas d’utilisation. Planifiez soigneusement et minutieusement toutes les adresses URL, car vous souhaitez éviter de les modifier si possible à ce stade. Commencez ensuite par une nouvelle installation à partir de zéro WP et poursuivez lentement votre chemin jusqu'aux cas d'utilisation. Commencez par le thème - vous pouvez trouver sur .org un thème gratuit qui ressemble un peu à ce qu’ils ont déjà, et choisir la route des thèmes pour enfants; ou personnaliser le code d'un nouveau thème. Étant donné que vos WP compétences en matière de thème paraissent minimes, je vous suggérerais l'itinéraire thématique pour enfants, car il vous en apprendra beaucoup sur le fonctionnement des thèmes. Vous pouvez ensuite créer les CPT (ou non, s’il n’ya pas de raison valable pour qu’ils soient des CPT). Les autorisations granulaires sont souvent la raison pour laquelle des éléments liés sont intégrés aux CPT, mais si les autorisations ne sont pas une raison, vous pourrez peut-être simplement utiliser Pages pour un grand nombre de CPT.
Une fois que vous avez reconstruit le site pour qu'il ressemble visuellement à l'ancienne version, il est temps de travailler sur les plugins. Vous pourrez peut-être laisser tomber ACF en fonction des besoins en termes de thèmes et de fonctionnalités, ce qui est très au cas par cas. Restez fidèle aux fonctionnalités du noyau autant que possible et essayez quelques plugins pour voir quel mélange fonctionne le mieux ensemble tout en offrant toutes les fonctionnalités qui existaient auparavant.
Cela vous prendra probablement quelques mois pour passer au travers et cartographier tout cela, puis le reconstruire. Au moment où tout est prêt, vous pouvez demander au client/aux parties prenantes de tester et de vous assurer de ne rien manquer, et de mettre en ligne cette version. À partir de là, faites un suivi pour voir comment Gutenberg progresse et utilisez votre connaissance des thèmes et des plugins que vous avez acquis pour reconstruire le site une fois de plus.
En ce qui concerne MultiSite, il est vraiment destiné à des groupes de sites Web très liés. À moins d'une raison majeure, il est généralement préférable de séparer les sites. Ainsi, si, par exemple, un site est piraté, vous n'avez pas besoin de restaurer l'intégralité du MultiSite et de faire en sorte que les deux sites soient arrêtés en même temps pendant que vous colmatez les failles de sécurité. De plus, à moins que vous n'ayez une configuration d'hébergement très sophistiquée, MultiSite stockera la date des deux sites dans une seule base de données, ce qui peut entraîner des goulots d'étranglement en termes de performances. Il est généralement plus rapide d'exécuter deux bases de données distinctes, même si elles se trouvent sur le même serveur, que de tout fusionner dans un site multisite.