it-swarm.com.de

Wie kann ich eine Klasse privat in ein Plugin importieren?

Ich habe ein Wordpress-Plugin geschrieben, das eine einfache Controller-/Vorlagenbibliothek verwendet, die ich erstellt habe, um die Geschäftslogik von der Präsentation zu trennen. Ich habe eine (etwas theoretische) Frage, wie man dieses "privat" in ein Plugin importiert, ohne mit anderen Plugin-Verwendungen in Konflikt zu geraten.

Die Bibliothek namens TemplateSystem ist ein Submodul in meinem Git-Repo für das Plugin und wird intern folgendermaßen definiert:

<?php

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

Wenn also ein anderes Plugin TemplateSystem verwendet, wird die geladene Kopie verwendet, anstatt durch Neudefinition einen Fehler zu verursachen. Normalerweise ist das in Ordnung, aber jetzt wurde für TemplateSystem eine abwärtskompatible Änderung eingeführt.

Ich habe also zwei Versionen derselben Bibliothek, die gleichzeitig geladen werden müssen. So wie es aussieht, wird entweder die neuere Bibliothek das ältere Plugin oder die ältere Bibliothek das neuere Plugin beschädigen, je nachdem in welcher Reihenfolge die Plugins von WP geladen werden.

Hier ist eine mögliche Änderung an TemplateSystem, die das Problem löst:

<?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
    {
        ...
    }
}

Um Namenskonflikte in meinem Anwendungsfall zu vermeiden, kann ich Folgendes tun:

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

class VersionedCommentsController extends VersionedCommentsTemplateSystem
{
    ...
}

Das funktioniert gut zusammen mit der älteren Version (ohne Namensraum). Nun, ich erwähnte, dass diese Frage theoretisch ist, da ich der Autor der Vorlagenbibliothek bin und (obwohl sie öffentlich verfügbar ist) glaube ich nicht, dass jemand anderes sie benutzt. Eine Lösung besteht darin, dieses Problem zu ignorieren. es wäre jedoch gut zu wissen, wie man richtig damit umgeht!

Zweite Möglichkeit: Die obige Namespace-Lösung funktioniert einwandfrei, außer dass Namespaces PHP 5.3 erfordern und - wie verschiedene Antworten auf dieser Site zeigen - WP nicht bald von einer veralteten Version wechseln werden . Sollte ich das ignorieren und PHP 5.3 benötigen, auch wenn sich der Kern nicht bewegt? Das würde natürlich verhindern, dass ein auf meiner Arbeit basierendes Plugin auf einem älteren Server läuft.

Oder, wenn Sie denken, dass Plugins (und ihre Bibliotheken) am besten nur 5.2.4 erfordern, was ist die alternative Lösung? Ich habe ein gebündeltes PHP -Konsolen "Build" -Skript in Betracht gezogen, das nur ein paar triviale Suchen und Ersetzen durchführt, sodass der Bibliotheksname durch einen benutzerdefinierten Namen für jedes Plugin ersetzt wird. Somit wird die TemplateSystem.php-Datei kopiert und die Klassendefinition der Kopie intern in VersionedCommentsTemplateSystem umbenannt (d. h. entsprechend dem Anwendungsfall). Das ist ziemlich abgedreht, würde aber zumindest mit mehr Installationen funktionieren.

Letzte Möglichkeit, fügen Sie die Änderungs- oder Versionsnummer in den Klassennamen ein:

<?php

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

Das würde mit 5.2.4+ funktionieren, ist aber meine am wenigsten bevorzugte Lösung. Mein innerer Purist schimpft über die Korruption des Klassennamens!

Welchen Ansatz würden erfahrene Plugin-Autoren verfolgen?

5
halfer

Benutze Namespaces , aber überprüfe die PHP Version auf der Serverseite und deaktiviere das Plugin mit einer nützlichen Fehlermeldung, wenn die Anforderungen nicht erfüllt sind.

Wenn Sie sich die offizielle Statistik ansehen, können Sie sehen, wie viele Installationen noch auf veralteten WordPress-Versionen ausgeführt werden. Aber fast alle neuen Plugins erfordern die neueste WordPress-Version, und niemand beschwert sich darüber. Ich denke, es gibt eine große Anzahl von aufgegebenen oder schlecht verwalteten Installationen. Sie werden Ihr Plugin wahrscheinlich sowieso nie verwenden.

Das lässt Sie mit einer relativ kleinen Anzahl von Installationen zurück, die aktuell sind, aber noch auf PHP 5.2 sind. Sie können aktualisieren. Heutzutage bieten alle Web-Hosts dies an. Sie könnten Symfony ausführen oder die meisten anderen gängigen Skripte nicht anders ausführen.

Die andere Möglichkeit besteht darin, die Bibliothek in ein separates Plugin zu verschieben und diese Bibliothek zuerst zu installieren. Dann Hook in library_loaded , um den Code Ihres speziellen Plugins zu starten.

2
fuxia