web-dev-qa-db-fra.com

Comment puis-je importer une classe en privé dans un plugin?

J'ai écrit un plugin Wordpress qui utilise une simple bibliothèque de contrôleurs/modèles que j'ai créée pour séparer la logique métier de la présentation. J'ai une question (légèrement théorique) sur la manière d'importer cela de manière "privée" dans un plugin de manière à ne pas entrer en conflit avec les autres utilisations de plugins.

La bibliothèque, appelée TemplateSystem, est un sous-module de mon dépôt git pour le plug-in, et est définie en interne de la manière suivante:

<?php

// Don't define this if it's already been defined
if (!class_exists('TemplateSystem'))
{
    abstract class TemplateSystem
    {
        ...
    }
}

Ainsi, si un autre plugin utilise TemplateSystem, la copie chargée sera utilisée plutôt que de créer une erreur en la redéfinissant. C’est normal normalement, mais TemplateSystem a maintenant un changement incompatible avec les versions antérieures.

Donc, j'ai deux versions de la même bibliothèque qui doivent être chargées en même temps. Dans l'état actuel des choses, la bibliothèque la plus récente rompt l'ancien plug-in ou l'ancienne bibliothèque, le dernier, en fonction de l'ordre dans lequel les plug-ins sont chargés par WP.

Donc, voici un changement potentiel à TemplateSystem qui résout le problème:

<?php

// The 'Change2' part would change with backwards incompatible changes,
// rather than just version numbers (although that would be fine tbh)
namespace TemplateSystem\Change2;

// Don't define this if it's already been defined
if (!class_exists('TemplateSystem\Change2\TemplateSystem'))
{
    abstract class TemplateSystem
    {
        ...
    }
}

Pour éviter les conflits de noms dans mon cas d'utilisation, je peux le faire:

<?php
use TemplateSystem\Change2\TemplateSystem as VersionedCommentsTemplateSystem;

class VersionedCommentsController extends VersionedCommentsTemplateSystem
{
    ...
}

Cela fonctionne bien avec la version plus ancienne (non-namespaced). Maintenant, j'ai mentionné que cette question était théorique, puisque je suis l'auteur de la bibliothèque de modèles et (bien qu'elle soit accessible au public), je ne pense pas que quelqu'un d'autre l'utilise. Une solution consiste donc à ignorer ce problème. Cependant, il serait bon de savoir comment s'y prendre correctement!

Deuxième possibilité: la solution d’espace de nommage ci-dessus fonctionnera correctement, sauf que les espaces de nommage nécessitent PHP 5.3, et - comme le montrent diverses réponses sur ce site - WP ne passe pas bientôt d’une version obsolète . Devrais-je ignorer cela et exiger PHP 5.3, même si le cœur ne bouge pas? Bien entendu, cela empêcherait tout plugin basé sur mon travail de fonctionner sur un serveur plus ancien.

Ou, si vous pensez que les plugins (et leurs bibliothèques) ne nécessitent que 5.2.4, quel est le correctif alternatif? J'envisageais de créer un script "build" groupé PHP console, qui effectuait simplement des recherches triviales et le remplaçait, de sorte que le nom de la bibliothèque soit remplacé par un nom personnalisé pour chaque plugin; ainsi, le fichier TemplateSystem.php est copié et la définition de classe de la copie renommée en interne en VersionedCommentsTemplateSystem (c’est-à-dire selon le cas d’utilisation). C'est plutôt hacky, mais au moins fonctionnerait avec plus d'installations.

Dernière possibilité, ajoutez le numéro de modification ou de version dans le nom de la classe:

<?php

// Don't define this if it's already been defined
if (!class_exists('TemplateSystem2'))
{
    abstract class TemplateSystem2
    {
        ...
    }
}

Cela fonctionnerait avec 5.2.4+, mais est ma solution la moins préférée; mon puriste intérieur bafoue à la corruption du nom de classe!

Quelle approche les auteurs de plugins expérimentés pourraient-ils utiliser?

pluginsphpcustomization
5
halfer

Utilisez des espaces de noms , mais vérifiez la version PHP côté serveur et désactivez le plug-in avec un message d'erreur utile si les conditions requises ne sont pas remplies.

Si vous consultez les statistiques officielles , vous pouvez voir le nombre d'installations en cours d'exécution sur des versions obsolètes de WordPress. Mais presque tous les nouveaux plugins nécessitent la dernière version de WordPress, et personne ne s'en plaint. Je pense qu’il existe un grand nombre d’installations abandonnées ou mal gérées. Ils n'utiliseront probablement jamais votre plugin de toute façon.

Cela vous laisse avec un petit nombre d'installations à jour mais toujours sur PHP 5.2. Ils peuvent améliorer. De nos jours, tous les hébergeurs proposent cela, ils ne pourraient pas exécuter Symfony ni la plupart des scripts populaires autrement.

L'autre option consiste à déplacer la bibliothèque vers un plug-in séparé et à exiger que cette bibliothèque soit d'abord installée. Puis connectez-vous au library_loaded pour démarrer le code de votre plugin spécialisé.

2
fuxia