Note: Content might be outdated!
Warum haben WordPress Hooks in Themes nichts verloren, in Plugins hingegen wohl? Tom McFarlin gibt eine ausführliche Antwort in englisch. Wer’s in deutsch mag, liest diesen Artikel hier.
Was sind Hooks in WordPress?
WordPress Hooks verstehen sich als „Platzhalter-Funktionen“, die ein Entwickler benutzen kann, um sich an einer bestimmten, definierten Stelle in die Software „einzuhaken“ und eine eigene Funktion auszuführen.
Bekannte Beispiele sind etwa die Hooks wp_head() und wp_footer(), mit deren Hilfe Javascript-Aufrufe im Kopf oder Fuß des HTML-Dokuments realisiert werden können, ohne dabei in die Template-Dateien header.php und footer.php eingreifen zu müssen.
Themes mit eigenen Hooks: wieso nicht?
Viele Theme-Entwickler setzen selbst definierte Hooks in ihren Themes ein. Ein prominentes Beispiel ist etwa das Genesis-Framework mit aktuell über 50 theme-eigenen Hooks.
Während Frameworks wie Genesis meist auf eine Historie zurück blicken, zu deren Beginn die mitgelieferten Hooks durchaus Sinn ergaben (und die Fortsetzung des Konzepts mag dann u.a. eine Frage der Konsistenz sein), sollten heute begonnene Theme-Projekte auf eigene Hooks besser verzichten. Warum?
- Mittlerweile gibt es Child-Themes, die ein abgestuftes Eingreifen in die Template-Struktur eines Theme ermöglichen.
- Und es gibt die zahlreichen, ausreichend referenzierten Hooks des WordPress-Kerns, mit denen sich spezifische Stellen in der Ausgabe von Datenbank-Inhalten ansteuern lassen.
Eigene Theme-Hooks stellen demnach eine nicht standard-konforme Praxis dar, die für Theme-Nutzer nur selten einen echten Wert, viel häufiger jedoch eine Menge mehr Arbeit bedeuten können.*
Für die meisten Anwender ist es viel einfacher, eine Template-Datei in ein Child-Theme zu kopieren und dort anzupassen, als erst den entsprechenden Theme-Hook in der Dokumentation des Theme zu finden und dann eine eigene PHP-Funktion für die gewünschten Anpassungen zu schreiben.
*Eine Ausnahme bilden vielleicht theme-eigene Hooks in kommerziellen Child-Themes. Da es zu einem Child-Theme nicht noch ein weiteres Child-Theme „obendrauf“ geben kann, können Hooks hier u.U. wieder eine sinnvolle Option zur Anpassung des Child-Theme bilden.
Hooks in Plugins: auf jeden Fall!
Völlig entgegengesetzt sieht es bei der Entwicklung von Plugins aus. So etwas wie „Child Plugins“ gibt es nicht. Wohl aber gibt es die Notwendigkeit, den von einem Plugin ausgespuckten Quelltext zu beeinflussen. Deswegen gehören eigene Hooks in einem Plugin überall dort eingesetzt, wo ein Eingriff sinnvoll und nützlich sein kann – z.B. wenn es um die Ausgabe von HTML geht.
Wie siehst du das?
Wolltest schon einmal ein Theme anpassen und hast dich gefragt, wie du das am sichersten anstellst? Welche Erfahrungen hast du mit Child Themes oder mit eigenen Hooks in Themes oder Plugins gemacht? Ich freue mich über dein Feedback!
Im Grunde stimme ich dir zu. Aber wenn man irgendwann anfängt jede einzelne Datei des Parent-Themes zu kopieren, nur um z.B. zwischen Kopf und Inhalt der Seite etwas einzufügen, dann wünscht man sich dann doch einen einfachen Hook für genau diese Stelle. Denn bei einem Update des Parent-Themes muss mann dann sehr genau aufpassen, ob das kopierte Template im Child-Theme dann auch aktualisiert werden muss. Daher haben wohl auch Frameworks wie Thematic ein paar durchaus nützliche Hooks für eben solche häufig verwendeten Stellen.
Danke für das Feedback! Wahrscheinlich macht die Menge auch hier das Gift. Gegen den ein oder anderen Hook – oder viel eher noch: Filter! – im Theme ist sicher nichts zu sagen, solange es sich im nice-to-have-Rahmen bewegt.
Dass ich ein Child-Theme nach einem Update anpassen musste, habe ich noch nie erlebt. Es wäre auch extrem kurzsichtig von einem Theme-Autor, das bestehende Markup so wesentlich zu ändern, dass es einem mit einem Child-Theme das Layout zerschiessen kann. Aber man hat ja schon Gäule vor der Apotheke… 😉
Die klassischen Stellen in einem Theme, die ich selbst via Child-Theme am ehesten anpasse, sind
style.cssundfunctions.php, gleich gefolgt vonheader.phpundfooter.php(meist um überflüssige Hard-Codings rauszuwerfen), sowie die Dateien für die Artikelausgabe, wie z.B.content-irgendwas.php(um 90% der Meta-Informationen zu entfernen, die bei CMS-Kundenprojekten einfach nur im Weg sind).Nette Theme-Autoren bauen an anpassungsprädestinierten Stellen wie der letztgenannten einfach einen Filter ein, oder regeln die Ausgabe gleich über die Theme Options. Das bezieht sich aber auf die Ausgabe von bereits bestehendem Markup. Mit einem Hook füge ich ja eher neues hinzu, und da funktioniert die Lösung via Template-Anpassung für mich persönlich wunderbar – sofern die Anzahl der Template-Dateien im Ganzen von einem passablen geistigen Gesundheitszustands des Theme-Autors zeugt. 😉
die style.css, die functions.php, die header.php, die footer.php und die diversen conten-xyz.php änderst du in einem ChildTheme.
Ich unterschreibe das, doch wozu, wozu um alles in der Welt sollt das dann ein ChildTheme sein, es sind doch mehr als 80% der Sachen neu 😉
Da steh ich als ersters gedanklich an.
Die ganzen Filter//Hooks sind für xyz der Nutzer, die ein ChildTheme haben wollen meist nicht verständlich.
Hey Monika, danke fürs Antworten! Meinst du, wenn ich 80% der Dateien ändere, kann ich auch gleich ein eigenes Theme draus machen? Stimmt natürlich. 😉
huch die EMail Benachrichtigung über einen neuen Kommentar landete in meinem SpamFilter;)
ich kenne auch etliche denen ein ChildTHeme dann schlicht zu kompliziert ist, weil sie eben diese Hooks nicht kennen etc.
Ich stimme dem (Original-) Artikel nicht zu, finde die Argumente wenig überzeugend. Prominente Entwickler wie Otto (Samuel Wood) oder Pippin Williamson haben dem auch widersprochen, aus gutem Grund.
Hooks & Filters sind ein prominentes Grundkonzept von WordPress, und sind sehr wohl auch für Themes da! Es macht die vielbeschworene Flexibilität von WordPress erst möglich.
Man könnte fast auf das Argument abfahren und dasselbe für Plugins fordern, was das ganze Dilemma aufzeigen würde. In meinen Augen sinnlos!
Natürlich muss nicht jedes Theme, was nur ein reguläres, stinknormales „Single Theme“ ist, mit Hooks daherkommen. Aber fürs Child Theme Konzept ist es ungemein hilfreich, vor allem, wenn man es richtig nutzt, wie etwa mit Genesis.
Als Genesis-Experte schwöre ich auf Hooks & Filter und finde sie nicht nur ungemein nützlich und elegant, sondern auch sehr sinnvoll, weil Dinge auch mal wieder ausgehängt werden können… 🙂
Ich denke, was der Autor eigentlich sagen wollte: man sollte sich mal auf 10 Standard-Hooks einigen. Diesem Argument stimme ich absolut zu! Das würde zudem vieles vereinfachen, wo man bisher Javascript bräuchte via Plugins, weil man eben nichts universell in WP Themes einhängen kann (z.B. im Footer), ich meine jetzt explizit nicht wp_head und wp_footer!
Entwickler Doug Stewart (aka zamoose) hat die „Theme Hook Alliance“ ins Leben gerufen, die sich für das Standard-Hook-Konzept stark macht: https://github.com/zamoose/themehookalliance — das wäre wie gesagt extrem sinnvoll.
Generell gegen Hooks in Themes zu Felde zu ziehen, halte ich für ein sinnloses Unterfangen. Kritik in Einzelfällen ist dagegen bisweilen sehr wohl angebracht.
Meine 2 Zent dazu.
-Dave 🙂
Hallo David, danke für dein Feedback und danke für den Tipp mit der Hook Alliance von Doug Stewart, die kannte ich noch nicht.