Supprimer les options de tous les blogs sur le plugin désinstaller à partir d'un réseau/multisite
Le Codex dit à propos de la suppression d'options sur uninstal
// note dans la boucle multisite à travers les blogs pour supprimer des options sur chaque blog n'est pas mise à l'échelle. Vous devrez juste les quitter.
Je ne suis pas très optimiste, mais existe-t-il un moyen établi et évolutif de le faire? En théorie, vous pouvez avoir un plug-in d'utilitaire de désinstallation, mais je n'ai jamais entendu parler de quelqu'un qui le fasse. Est-ce simplement une mauvaise idée ou est-ce juste un cas où personne ne se soucie suffisamment des ordures laissées dans la base de données?
S'agissant d'un wiki, le codex est une source d'informations notoirement peu fiable (mais vous le saviez probablement déjà). Cependant, il est probablement vrai que la désinstallation sur des réseaux de grande taille ne sera pas à l’échelle.
Ce que je fais dans l'un de mes plugins consiste à exécuter la routine de désinstallation du plugin sur tous les sites, sauf si wp_is_large_network() est vrai. Sur un grand réseau, le plug-in suppose simplement qu'il ne pourra pas exécuter la désinstallation correctement et ne le tentera pas.
Une autre chose que je fais est de faire en sorte que le plug-in garde une trace des sites sur lesquels il est réellement installé (lorsqu'il n'est pas actif sur le réseau), afin qu'il soit désinstallé sur chacun de ces sites, quelle que soit la taille du réseau. Donc, s'il y a 20000 sites sur le réseau mais que le plug-in n'a été installé que sur 3, il se désinstallera de ces 3 sites.
Je pense qu'il est également important de garder à l'esprit que les personnes qui exploitent des réseaux énormes vont être confrontées à ce genre de problème tout le temps (à chaque fois qu'elles mettent à jour WordPress, par exemple). Ils comprennent que l'installation/la mise à jour/la désinstallation ne sera pas évolutive dans la plupart des cas, ils doivent donc écrire leurs propres scripts souvent.
Donc, dans mes plugins, je me concentre essentiellement sur la routine de désinstallation de base, en l'exécutant lorsqu'elle doit être mise à l'échelle et en montrant aux administrateurs un avis lorsqu'il a probablement gagné pas d’échelle et le plugin ne le tente pas seul.
Update (2015-03-16): Je viens de me rappeler qu'il existe un ticket de suivi lié à cette discussion: # 14170 , en particulier de ce commentaire sur est très instructif sur la raison pour laquelle il a été décidé que le noyau lui-même ne fournirait pas une API pour cela. Le ticket contient également de bons conseils pour optimiser le multisite :
La raison pour laquelle je suis contre cela en cœur est précisément démontrée par votre plugin. En le parcourant, vous créez un terrible lot de tables. Vous créez six tables par blog . Cela ne peut pas évoluer de manière raisonnable.
Aucun administrateur réseau ne laisserait cela sur leur site, étant donné les nombreux plugins beaucoup moins encombrants. Je suis las des plugins ayant une API officielle pour faire des choses comme ça. Si quelqu'un veut votre plugin sur son réseau, il va essayer de tout désactiver pour pouvoir générer lui-même ces tables. (Il a fallu environ deux semaines pour générer des tableaux de commentmeta pour chaque site sur WordPress.com.)
Note de bas de page - Beaucoup d'entre elles sont des tables de recherche et devraient probablement être des tables globales. Ceux qui ne le sont pas peuvent être des types de publication. Ensuite, vous n'aurez pas besoin de le faire du tout.