Mit einem Front-Controller in einem WordPress-Plugin, irgendwelche Vorschläge?

Meine Idee war, einen Frontcontroller in unserem Plugin zu verwenden. Hat das schon jemand gemacht? Die Zuständigkeiten des für die Verarbeitung Verantwortlichen sollten

  • Router-class initiieren;
  • Bereitstellung von Zugriff auf die Registrierung von Objekten, die für das Auffinden und Initialisieren anderer classn verantwortlich ist (möglicherweise durch Fabriken);
  • class initiieren, die für das Binden von WordPress-Aktionen zuständig ist.

Ich dachte daran, dem Standard- Martin-Fowler-Beispiel zu folgen, aber wenn jemand es bereits versucht hat, möchte ich vielleicht von ihm lernen.

Solutions Collecting From Web of "Mit einem Front-Controller in einem WordPress-Plugin, irgendwelche Vorschläge?"

Die meisten komplexen Plugins machen das in der einen oder anderen Form. Leider beginnen viele Plugins mit einer Gottklasse und verwenden keinen sauberen OOP-Ansatz. WooCommerce ist ein beliebtes Beispiel.

Plugins können keinen echten Frontcontroller bieten, da sie geladen werden, nachdem WordPress den Großteil seiner Umgebung eingerichtet hat. Und alle Plugins sind fast gleich: Wenn zwei Plugins versuchen, dieselbe Anfrage zu bearbeiten, gewinnt wahrscheinlich der erste. Sie wissen nie, welche Plugins mit Ihren konkurrieren können.

Für ein sehr einfaches Beispiel siehe mein Plugin T5 Public Preview (von dieser Antwort ).

  • Der Frontcontroller ist die class T5_Public_Preview, er lädt die benötigten classn und erstellt die Objekte abhängig von der Anfrage (Admin oder Front-End).
  • Es gibt drei Modelle: T5_Post_Meta , T5_Public_Preview_Language und T5_Endpoint .
  • Und zwei Ansichten behandeln die Ausgabe: T5_Publish_Box_View und T5_Render_Endpoint . Letzteres zeigt nicht wirklich etwas, aber es ändert WordPress, um in einigen Fällen eine andere Ausgabe anzuzeigen.

Bei OOP geht es um die Kommunikation zwischen Objekten und Komponenten . Das eigentliche Problem ist also nicht das Muster, es ist die Kommunikation . WordPress-core ist nicht OOP, alles wird zusammengelegt; Der Code war und ist organisch gewachsen. Ohne eine klare innere Struktur triggerse WP das Kommunikationsproblem mit Aktionen und Filtern (Hooks) : vordefinierte Ereignisse, die es jedem Plugin erlauben, Output- und Anwendungslogik zu ändern oder zu ersetzen.

Ihr Plugin muss innerhalb dieser Struktur funktionieren. Es gibt einige interessante Kommunikationsprobleme zu lösen:

  • Machen Sie es möglich, Ihr Plugin temporär zu ändern oder zu deaktivieren. Vermeiden Sie anonyme Objekte oder bieten Sie ein Konfigurationsobjekt an .
  • Aber stellen Sie nicht zu viele benutzerdefinierte Hooks zu früh bereit.
  • Versuchen Sie, die Reihenfolge der Ausführung zu steuern , wenn mehrere Plugins auf denselben Hooks agieren.
  • Stellen Sie sicher, dass callbacke, die von einer bestimmten Bestellung abhängig sind, verkettet sind .

Dies sind die wichtigsten Verantwortlichkeiten für einen Plugin Front Controller. Sie können einige an nachfolgende Controller delegieren, aber der Frontcontroller muss wissen, wie sie funktionieren. Meiner Meinung nach muss ein Frontcontroller in einem WP-Plugin zu oft zu viel wissen. Aber ich lerne immer noch. 🙂

Oh, und trennen Sie die Haupt-Plugin-Datei von den classndeklarationen .