Être un développeur de thème ou de plugin est un travail difficile. Entre les mises à jour de WordPress, les corrections de bugs, les incompatibilités de versions PHP et le support client, vous avez beaucoup à faire. Et n’oubliez pas les nombreux utilisateurs potentiels qui vous demandent si ce site est compatible avec le Multisite C’est une question assez courante, et tous les développeurs n’y ont pas forcément pensé. J’ai donc voulu creuser un peu plus loin dans le développement de WordPress Multisite, et plus précisément, quand vous devez prendre en compte les installations Multisite dans votre processus de développement.

Pourquoi développer pour Multisite ?

Voici ce qu’il en est. Lorsque vous installez WordPress et que vous créez des sites web, si vous vous demandez si vous devez utiliser WordPress Multisite ? la réponse sera bien plus souvent négative que positive. La situation est cependant inversée si vous êtes dans le développement de plugins et de thèmes. Maura Teal en explique les raisons dans son exposé au WordCamp San Diego intitulé Why Good Developers Don’t Ignore Multisite. Essayez de deviner où elle veut en venir.

Vous pouvez consulter notre aperçu complet de ce qu’est Multisite, mais l’essentiel est le suivant : une installation WordPress alimente un réseau de sites. WordPress.com en est un exemple concret.

C’est une fonctionnalité vraiment cool, et Maura Teal a raison – vous ne devriez pas l’ignorer. Cependant, si vous voulez que votre plugin ou votre thème fonctionne avec, vous devez faire un effort particulier. En effet, les installations multisites partagent une base de données, et certaines tables de cette base de données sont partagées entre les sites (par exemple, usermeta), alors que d’autres ne le sont pas. Vous pouvez également rencontrer des problèmes majeurs avec l’activation à l’échelle du réseau, la création de tables, la désactivation de plugins et quelques autres difficultés.

Alors… pourquoi prendre le temps de résoudre ces problèmes ?

Eh bien, tout d’abord..

De nombreuses personnes demandent la compatibilité multisite

Vraiment. Ce n’est peut-être pas le paramètre par défaut, mais les gens l’utilisent. Beaucoup. Dans un épisode de WP Water Cooler, le panel discute de ce que vous devriez faire après avoir lancé un plugin WordPress. Dans le cadre de cette discussion, ils ont parlé des problèmes d’assistance courants et des demandes de fonctionnalités.

La traduction a été la première à être mentionnée. WordPress est méga-mondial, non ? Mais après cela… La compatibilité multisite a été le prochain problème à apparaître. Et elle n’apparaît pas seulement dans les épisodes de podcast avec les développeurs. La question est affichée partout sur les forums de support de WordPress.org.

  • https://www.facebook.com/lafactoryworld
  • https://twitter.com/lafactory
  • Gmail
  • https://www.linkedin.com/company/lafactory-inc

Oui, la plupart des installations de WordPress sont des installations mono-site. Mais il y a beaucoup d’utilisateurs de WordPress Multisite, et ces webmasters veulent des plugins et des thèmes qui fonctionnent bien avec leurs versions de WP.

  • https://www.facebook.com/lafactoryworld
  • https://twitter.com/lafactory
  • Gmail
  • https://www.linkedin.com/company/lafactory-inc

Ce n’est pas si difficile si..

Dans cette même conférence WP Water Cooler, Jon Brown de 9Seeds a parlé de la plus grande raison de développer pour Multisite : Ce n’est pas si difficile si vous codez pour lui dès le début.

En d’autres termes, si vous testez sur un environnement Multisite et que vous codez en tenant compte de la compatibilité Multisite, il n’y a pas vraiment de travail supplémentaire. La plupart du travail réel que vous avez à faire consiste simplement à suivre les meilleures pratiques. Cela peut ajouter un peu à votre calendrier général, mais cela ne va pas doubler votre temps de développement ou quoi que ce soit d’aussi radical.

Ajouter la compatibilité multisite plus tard, cependant..

C’est là que vous pouvez vous retrouver dans une situation délicate. L’ajout de la compatibilité multisite dès le début n’est pas si difficile, puisque vous pouvez le planifier. Revenir à votre base de code après coup et essayer d’ajouter la compatibilité multisite va impliquer de démêler beaucoup de code spaghetti.

Supposons que vous ignoriez la compatibilité multisite parce que vous voulez mettre en place un plugin aussi rapidement que possible. Que se passe-t-il si votre plugin connaît un succès fulgurant ? C’est génial ! Félicitations ! Les tickets d’assistance commencent à affluer, vous recevez de nombreux commentaires et questions concernant Multisite, et si vous dites non… c’est autant de clients, de revenus et de fidélité à la marque perdus. Parce que soit vous ignorez ces gens et vous continuez à avancer. Soit vous essayez de revenir en arrière et de tout réadapter.

Aucune de ces deux solutions n’est particulièrement attrayante.

Problèmes spécifiques à prendre en compte lors de la création d’un site WordPress multisite

Disons que vous êtes convaincu de commencer à développer pour Multisite. Mais qu’est-ce que cela implique concrètement ?

Bien que cette liste ne soit pas exhaustive, voici quelques-unes des questions les plus importantes à prendre en compte lors de la planification de votre développement.

À propos, il peut y avoir beaucoup de code impliqué dans le développement pour Multisite ou pour un seul site, et il y a des gens qui ont déjà des exemples fantastiques. Vous devriez absolument les consulter. Ce ne sont là que quelques-unes des excellentes ressources que je vous recommande de consulter.

  • L’article de ShibaShake Écrire un plugin pour WordPress Multi-Site
  • WPHub’s post on Making Plugins Compatible with WordPress Multisite (en anglais)
  • Onextrapixel’s Comment coder correctement votre plugin pour un WordPress Multisite

1. Mettez l’accent sur l’évolutivité

Évidemment, vous devez toujours vous efforcer de rendre votre code aussi efficace que possible. Mais lorsque vous travaillez avec des installations typiques de WordPress, vous avez un peu plus de marge de manœuvre. Et je ne dis pas que vous le faites, mais vous… pouvez être un peu paresseux quand il s’agit d’optimiser les performances. Mettre de l’ordre dans toutes les requêtes de la base de données ? Mmmm..

Ce genre de raccourcis s’accumule lorsque vos utilisateurs gèrent 300 sites sur leur réseau. Les performances et l’évolutivité de votre plugin ou de votre thème comptent beaucoup plus. Tellement plus que vous pouvez perdre des clients et des utilisateurs si le code n’est pas suffisamment optimisé.

2. Utilisez les noms de table de base de données appropriés

En raison de la façon dont Multisite fonctionne avec les tables de base de données, vous devez éviter de faire des appels à des noms de table codés en dur. Chaque site du réseau partage une seule base de données, mais chacun crée ses propres tables. Ainsi, si vous essayez d’exécuter quelque chose sur wp_posts, par exemple, vous allez avoir quelques problèmes avec Multisite.

La bonne méthode consiste à utiliser l’objet global $wpdb pour s’assurer que vous obtenez toujours les noms de table de base de données corrects pour le site unique et le multisite, quelle que soit la personne qui exécute votre code. Ce n’est pas un changement difficile à faire, mais c’est tout de même un changement.

3. Pensez à l’activation et à la désactivation

Si votre plugin crée une table au cours du processus d’activation, vous devrez répéter cette opération sur chaque blog d’une installation Multisite (en supposant que le plugin a été activé sur l’ensemble du réseau, ce qui est souvent le cas).

Qu’en est-il lorsqu’un nouveau blog est ajouté à ce réseau Multisite alors que votre plugin a déjà été activé ? Dans ce genre de situation, vous devrez vous assurer que votre code exécute la fonction d’activation pour créer la table de base de données requise chaque fois qu’un nouveau site est ajouté.

Et bien sûr, les mêmes règles s’appliquent à la désactivation et à la désinstallation. Assurez-vous de nettoyer votre désordre avant de partir.

4. Prenez en compte les options d’administration et les autorisations des utilisateurs

Au-delà des changements de code spécifiques, vous devez également réfléchir un peu plus aux options d’interface. Par exemple, y a-t-il une fonctionnalité spécifique de votre plugin que le super administrateur multisite pourrait avoir besoin de désactiver sur l’ensemble du réseau ?

L’exemple de Maura d’un appel wp-cron qui a parcouru l’ensemble de la table des messages est une bonne illustration. Sur un site, bien sûr ! C’est très bien… mais sur 300 ? Cela peut couler un réseau aussi rapidement que d’obtenir un lien sur la première page de Reddit.

En outre, j’ai entendu parler de certains problèmes avec les thèmes sur Multisite où seul le Super Admin peut gérer les paramètres du thème. C’est très bien dans certaines situations, mais si le Super Admin veut que les utilisateurs de chaque site puissent changer l’apparence de leur site… encore une fois, des problèmes. Une partie du codage pour Multisite est d’envisager les possibilités probables et les cas d’utilisation comme celui-ci.

Alors… devez-vous le faire ?

Dans l’ensemble, WordPress Multisite suscite de fortes opinions au sein de la communauté WP. Certaines personnes l’aiment vraiment. D’autres le détestent vraiment. Ils le détestent suffisamment pour donner des conférences au WordCamp intitulées Don’t Use WordPress Multisite. Encore une fois, devinez ce qu’ils essaient de dire. (Certes, il s’agit d’une conférence plus ancienne, avant qu’il y ait de nombreuses mises à jour de la fonctionnalité, mais mon point de vue est l’idéologie)

En fin de compte, la question de savoir si vous, les développeurs de plugins et de thèmes, devez développer pour Multisite est un gros peut-être. Si vous développez pour le grand public, que vous mettez vos thèmes et plugins sur le dépôt, ou que vous les vendez vous-même, vous devez absolument prendre le temps de coder votre projet pour qu’il fonctionne avec Multisite. Cela ouvre plus d’opportunités que le temps de développement n’en prend.

Mais si vous développez des sites Web pour des clients, Multisite n’est généralement pas la solution. Dans certaines situations, l’utilisation de Multisite peut avoir du sens, mais le plus souvent, ce n’est pas le cas. Pour de nombreux clients, les fonctionnalités supplémentaires offertes par les installations Multisite sont plus écrasantes qu’utiles.

Que pensez-vous du développement de WordPress Multisite ?

Image de la vignette de l’article par Jiw Ingka / shutterstock.com