Wie viele Filter / Aktionshaken sind gesund?

Das Plugin erweiterbar zu machen, ist der nächste Weg, um die Probleme der meisten Leute zu lösen. Und ich weiß, dass ich hier und da viele Filter- und Action-Hooks platzieren kann, um die Dinge dynamischer zu machen. Aber für mich ist es zu unordentlich.

Kürzlich wurde ein Benutzer meines Plugins gebeten, den Tooltip-Text an seinem Ende zu ändern, und in ihrem Fall ist es kein so schlechter Grund. Es gibt 6-8 Tooltips auf dieser Seite. Ich weiß, dass ich Filterhaken für jeden von ihnen platzieren kann. Aber sollte ich?

Gibt es irgendwelche Nachteile, Performance-Probleme beim Setzen von vielen Haken?

Solutions Collecting From Web of "Wie viele Filter / Aktionshaken sind gesund?"

Solange Hooks nichts angehängt haben, sind sie No-Ops, das heißt fast nichts und hat keinen wesentlichen Einfluss auf die Laufzeit. Es wird ganz anders, wenn Dinge süchtig sind und es viele Anrufe gibt.

Da Sie über das Anpassen von Strings sprechen, wäre das gute Beispiel gettext hook in core. Jede lokalisierte Zeichenfolge durchläuft sie.

In der Theorie ist dies ein sehr flexibler Haken, mit dem man Text fast überall filtern kann. In der Praxis kann es tausende Male feuern und wenn man es ohne Vorbehalte ansetzt, wird es die komplexe Seite schnell zum Stillstand bringen.

Sie behandeln Ihren Anwendungsfall nicht ausreichend detailliert, um eine spezifische Implementierung zu empfehlen. Im Allgemeinen haben Sie mehrere Möglichkeiten, dies zu organisieren:

  • apply_filters( 'prefix_tooltip', $text ) ist ein grundlegender Fall, der Filter müsste apply_filters( 'prefix_tooltip', $text ) der Text genau übereinstimmt, um den Kontext zu bestimmen, also zerbrechlich.
  • apply_filters( 'prefix_tooltip', $text, 'type/location' ) zusätzliches Argument ermöglicht es Ihnen, den Typ des Tooltips anzugeben, auf den der Filter zielen kann; Selbst wenn sich Text ändert, identifiziert der Typ ihn immer noch.
  • apply_filters( 'prefix_tooltip_' . $type, $text ) Name des dynamischen apply_filters( 'prefix_tooltip_' . $type, $text ) , der sich mit dem Variablenwert ändert; Dies ist sehr flexibel für Fälle von vielen / generierten Typen. Das Problem besteht hauptsächlich darin, dass dynamische Hooks im Code schwerer zu entdecken sind und bei der Selbstdokumentation viel schlechter sind.
  • apply_filters( 'prefix_tooltips', $texts_array ) einzelner Filter für den kompletten Satz verwendeter Tooltips.

Bei einer Anzahl von 6-8 Einträgen gibt es zwischen ihnen keinen wirklichen performancesunterschied.

Was Sie hier lernen müssen, ist, welche Ansätze es gibt und dass Sie sorgfältig den für jeden Fall am besten geeigneten aussuchen müssen, damit er für Sie und nachgeschaltete Entwickler sinnvoll und praktisch ist.

Hier sind wirklich zwei Fragen. 1. Was bewirkt ein Haken? und 2. Sollten Sie nur Haken überall verbreiten

  1. Der Einfluss ist nahe bei Null. Wenn nichts an der Aktion / dem Filter hängt, werden die Aufrufe von do_action/apply_filters fast sofort zurückkehren, so dass es keine merkbaren Auswirkungen auf Personen gibt, die den Hook nicht verwenden, und daher ist es technisch nicht schlecht, sie hinzuzufügen (Wenn Sie einen halbwegs vernünftigen Grund angeben, dem Core Hooks hinzuzufügen, wird es höchstwahrscheinlich vom Hauptthema hinzugefügt).

  2. Aber ist es klug als Software-Entwicklungspraxis? Nr. Hooks sind APIs und APIs bedeutet Ihrerseits Verpflichtung, sie auf lange Sicht zu erhalten. Wie bei jeder “offiziellen” API, die du erstellst, solltest du denken, dass es etwas ist, das für dein Plugin auf lange Sicht Sinn macht, und du tust es nicht, nur um einen Plugin-Nutzer glücklich zu machen.

Wenn Sie nach Ihrer Beschreibung einen Text benötigen, der angepasst werden muss, sollten Sie vielleicht einen Einstellungsbildschirm dafür verwenden. Dies ist offensichtlich auch eine Art von API, aber es ist besser sichtbar für die Endbenutzer zugänglich.

Anpassung ist immer ein Stein des Stolperns (schmerzhafter process). Auf der einen Seite haben wir echte Anfragen von Benutzern, die immer wichtig sind. Auf der anderen Seite können alle diese zusätzlichen Optionen Ihr schönes Thema, Plugin oder ein abstraktes Produkt zur Hölle machen. Was können wir als Entwickler tun?

Als erstes. Schreiben Sie erweiterbaren Code mit der Möglichkeit, einige Teile Ihres Codes zu ändern – wiederverwendbaren Code. classn, Interfaces, Traits und einfach nur lange falschen Code in kleine Methoden (functionen) aufteilen. Ein Teil der Benutzer kann sie problemlos ohne Änderungen an Ihrem Produkt verwenden. Zum Beispiel kann jemand ein Widget mit seinen eigenen Bedürfnissen erstellen und die interne Plugin-function please_echo_the_plugin_awesome_stuff() .

Das Hinzufügen der neuen Filter und Aktionen ist keine schlechte Idee . Viele populäre Plugins wie Jetpack oder bbPress haben Hunderte von Filtern in ihrem Code. Manchmal sogar übertrieben. Jeder neue Filter (oder jede neue Aktion) ohne Handler verursacht normalerweise keinen großen Overhead. Es ist eine Mikrosekunde.

10 ^ -3 s Millisekunde ms 10 ^ -6 s Mikrosekunde μs

Viel wichtiger ist, was Sie bei dieser Aktion tun, indem Sie neue Handler über add_action() oder add_filter() . Zum Beispiel, Anfragen an den databaseserver (manchmal nicht offensichtlich, wie get_option() von get_option() ). Und Sie können es messen. Das einfachste Beispiel:

 $start = microtime(true); // Do some stuff here $end = microtime(true); echo $start, PHP_EOL, $end, PHP_EOL, $end - $start, PHP_EOL, 

Es ist sehr einfach und manchmal am besten geeignete Technik, um Ihren Code zu profilieren. Übrigens haben WordPress interne “Stoppuhr”, checkout timer_start() und timer_stop() .

Oder Sie können XDebug verwenden. Es scheint sehr komplex zu sein zu konfigurieren. Sie können jedoch VVV oder einen anderen sofort einsatzbereiten Server verwenden. Alle haben Xdebug bereits richtig konfiguriert und du kannst es einfach benutzen – hört sich gut an, oder? Wenn Sie VVV verwenden, drücken Sie einfach einige Befehle:

 vagrant ssh xdebung_on 

Das ist alles! Wechseln Sie zu Ihrer IDE und profilieren Sie Ihren Code. Oder verwenden Sie interne VVV-Dienste wie WebGrind. Mehr über diese Techniken finden Sie im Code Debugging Wiki . Es sollte daran erinnert werden, dass die Verwendung von Xdebug Auswirkungen auf die performance hat, aber Sie können langsamen Code (Engpass) finden.

Und drittens. Das letzte Ding. WordPress Philosophie ist Entscheidungen, nicht Optionen .