Taxonomy Abhängige Einstellungen – Teil 4

Im vierten und letzten Teil der Serie (hier zum ersten Teil) kümmern wir uns noch um das Frontend. Da die Logik und das Backend schon funktionieren müssen wir nur noch die richtige Nachricht auf der Homepage darstellen.

 Ziel des Tutorials

Im Laufe des Tutorials werden wir ein Plugin entwickeln, welches mit der Taxonomy „Kategorie“, die man von den Posts her kennt, arbeitet und pro Kategorie eine eigene Einstellungsseite erstellt. In dem Beispiel wird das lediglich eine Einstellung als Textfeld (Message) sein, die wir dann im Frontend bei den Posts ausgeben.

Den gesamten Code findest du auf GitHub: tax-settings.

v1: eine Einstellung für alle Kategorien

v2: pro Kategorie eine Einstellung


Als letzten Schritt wollen wir die entsprechende Nachricht natürlich auch auf der Homepage anzeigen. Dazu haben wir im letzten Teil im Backend die Settings Page bearbeitet, dass wir für jede Kategorie auch eine eigene Nachricht speichern können. Jetzt muss diese Nachricht ins Frontend.

Tax-Settings: Posts

Im ersten Teil haben wir dafür die Methode get_cat_text() eingeführt in class-ts-category-message.php, die die Nachricht aus der Datenbank holt. Nun haben wir ja aber nicht nur eine Option sondern mehrere daher müssen wir diese Methode anpassen.

Aber bevor wir richtig los legen, lass erst noch mal überlegen, was wir genau wollen. Wir haben gesagt, wir wollen nun die entsprechende Nachricht der Post Kategorie anzeigen. Also wenn der Post in der Linux News Kategorie ist soll auch diese Nachricht angezeigt werden (Ich beschränke mich in diesem Tutorial auf die erste Kategorie. Also sollte ein Post in mehreren Kategorien sein wird nur die erste Nachricht dargestellt um das ganze zu Vereinfachen.). Aber wenn ein Post gar keiner Kategorie zugeordnet ist? Dafür haben wir ja extra die „General“ Option eingeführt, dass genau in diesem Fall der Fallback genutzt werden soll.

Die überarbeitete Methode sieht dann wie folgt aus:

public function get_cat_text() {
    global $post;
    $settings_model = new TS_Settings();

    $cats = wp_get_post_categories( $post->ID, array( 'fields' => 'slugs' ) );

    /* Make use of get_option_by_key method to get the correct
    message for the category of this post.
    In this tutorial the first category of the post is used to make things
    simple. But if you want to show all messages just loop over the $cats
    array and display each message. */
    $value = $settings_model->get_option_by_key( $cats[0], 'ts_cat_message' );
    return $value['field_value'];
}

Im Grunde passiert hier nicht viel. Zuerst werden die Kategorien des Posts abgefragt und die erste Kategorie des Post wird an die Methode get_option_by_key( $cat, $value_name ) übergeben. Diese Methode macht gebraucht von der Methode get_field_value, die wir aus dem 3. Teil kennen.


public function get_option_by_key( $setting_name, $value_name ) {
    if ( !isset( $setting_name ) || !isset( $value_name ) ) {
        return '';
    }
    $value = $this->get_field_value( $setting_name, $value_name );
    if ( !isset( $value ) || empty( $value['field_value'] ) ) {
        $value = $this->get_field_value( 'general', $value_name );
    }
    return $value;
}

Die Methode versucht erst die Nachricht der Kategorie zu bekommen. Sollte noch keine Nachricht für diese Kategorie gespeichert sein, so versucht die Methode die Nachricht von „General“ zu bekommen (Fallback). Somit wird auf jeden Fall eine Nachricht zurück gegeben und kann im Frontend angezeigt werden.

Am Rest müssen wir nichts mehr ändern, da der zurückgegebene Text einfach in den Post Content eingebunden wird und entsprechend formatiert wird. D.h. wir sind fertig 🙂

Zusammenfassung

In dieser vierteiligen Serie haben wir eine Taxonomy durch ein weiteres Feld erweitert: Mit einer simplen Nachricht. Dazu haben wir folgende Dinge gemacht:

  1. Generische Optionen-, Sektionen- und Felder-Generierung um mehrere Einstellungen speichern zu können
  2. Settingspage im Backend angepasst und durch Tabs erweitert
  3. Zudem eine Fallback Option (General) eingebaut, falls keine Option für eine Kategorie gesetzt ist
  4. Darstellung der entsprechenden Nachricht bzw. des Fallbacks im Frontend

Mit dieser Lösung können wir nun für eine Taxonomy leicht neue Optionen hinzufügen und überall im Plugin oder Theme verwenden.

Ein paar Gedanken zu dieser Lösung …

Ich habe diese Lösung im Rahmen meiner Entwicklung für Dicentis entwickelt und habe lange überlegt, wie ich das gescheit implementiere. Mit dieser Lösung bin ich persönlich derzeit sehr zufrieden.

Ralf hat allerdings angemerkt, dass man das ganze auch mit dem action hook {$taxonomy}_add_form_fields (Code Reference). Dieser Hook fügt ein neues Feld zu der genannten Taxonomy hinzu und kann dann über die gewohnten WP Funktionen abgefragt werden.

Dies ist definitiv auch eine Möglichkeit. Und in diesem simplen Tutorial, wo wir nur ein Textfeld hinzugefügt haben, wäre das auch vielleicht die bessere Lösung gewesen.

Aber die Lösung dieses Tutorials finde ich aus zwei Gründen besser:

  1. Wenn eine Taxonomy viele Optionen bekommen soll
  2. Die User Experience wird dadurch verbessert

Punkt 1 sollte klar sein. Wenn man viele Optionen hat kann ich mit dieser Lösung ebenfalls leicht und schnell eine ausgefeilte Settings page erstellen, die weit über einfachen Textfeldern hinausgeht.

Punkt 2 ist für mich hingegen wichtiger. Denn ich finde, durch meine Lösung wird die User Experience erhöht. Lasst mich das erklären: Wenn ich ein Plugin mit mehreren Taxonomies habe und zudem auch noch viele Einträge für eine Taxonomy, dann kommen schnell viele Einstellungsmöglichkeiten hinzu und wenn ich für jede Taxonomy auf die jeweilige Unterseite muss um die Einträge zu editieren, dann wir das schnell zu einer aufwändigen und langwierigen Aufgabe.

Durch eine zentrale Settingspage habe ich die Möglichkeit, dies für den User an einen Ort zu sammeln. Man findet schnell auf einer Seite und mit wenigen Klicks alle Einstellungen die für dieses Plugin nötig / möglich sind und muss mich nicht durch 3 oder mehr Seiten wühlen bis ich die Einstellung gefunden habe. Genau aus diesem Grund habe ich mich gegen den WP Hook entschieden und etwas mehr Aufwand betrieben und die User Experience zu erhöhen.

Ich hoffe ihr fandet das Tutorial nützlich und habt das ein oder anderen mitgenommen 🙂

Veröffentlicht von Hans-Helge

Als studierter Informatiker arbeitet Hans-Helge gerne als freiberuflicher WordPress Entwickler und betreut neben eigenen Projekten viele andere Webseiten u.A. im ehrenamtlichen Bereich.

Schreib einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.