WordCamp Berlin 2017 - WordPress Architektur Grundlagen

Wie erweitere ich WordPress korrekt, warum ist die Theme functions.php kein guter Weg für Erweiterungen und warum Katzenbabies durch den Hack von WordPress Core Funktionen sterben.

Transcript

1. mv functions.php /dev/null Das kleine WordPress Architektur 1x1
3. ARCHITEK-WAS?
4. WordPress Code Ebenen WordPress Core Plugins Themes mu-plugins Child Themes Actions Filter Theme / Template Loader
5. Userland WordPress Core Plugins Themes mu-plugins Child Themes Actions Filter Theme / Template Loader /wp-content/plugins/ /wp-content/themes/ /wp-content/
6. Funktionale Teilung WordPress Core Plugins Themes mu-plugins Child Themes Actions Filter Theme / Template Loader • Themes – Optische Darstellung von Inhalten – Templating – Anpassung bestehender Themes – Vordefinierte Inhalte („Starter Content“)
7. Funktionale Teilung WordPress Core Plugins Themes mu-plugins* Child Themes Actions Filter Theme / Template Loader • Plugins – Erweiterung um Features – Veränderungen bestehender Funktionen – Veränderung des Verhaltens anderer Plugins – Einzeln aktivierbar und deaktivierbar – Automatisch aktualisierbar (wenn im wp.org Repo) * Für Interessierte: https://codex.wordpress.org/Must_Use_Plugins
8. Badlands WordPress Core Plugins Themes mu-plugins Child Themes Actions Filter Theme / Template Loader /wp-content/plugins/ /wp-content/themes/
9. Nogoland WordPress Core Plugins Themes mu-plugins Child Themes Actions Filter Theme / Template Loader /wp-content/plugins/ /wp-content/themes/
10. WORDPRESS RICHTIG ERWEITERN
11. functions.php • Teil des Themes • Funktionalität steht nur dem aktuell aktiven Theme zur Verfügung • Seiteneffekte mit Plugins möglich • Nach Theme Updates möglicherweise nicht mehr vorhanden • Docs: „The functions file behaves like a WordPress Plugin “ Siehe: https://codex.wordpress.org/Functions_File_Explained
12. WordPress Plugins • Nicht Theme gebunden • Separat aktivierbar / deaktivierbar • Separat Updatebar • Versionierbar (git, svn etc) • Deploybar (SFTP, git pull, gulp, Jenkins, etc.)
13. WordPress Plugins • Mehraufwand für ein WordPress Plugin statt functions.php: • Gesparter Wartungsaufwand durch Plugin: ca. 90 Sekunden (bei IDE Unterstützung) unbezahlbar
14. WordPress Plugins
15. WordPress Plugins
16. Wartungsaufwand? • Zustand eines Plugins einfach ersichtlich • Logische Platzierung für Funktionen • Plugincode einfach in GIT versionierbar • Code logisch in mehrere Plugins clusterbar
17. Und das Theme? • Die üblichen Verdächtigen im Child Theme: – style.css – einzelnen Templates (*.php) – functions.php Child-Theme verwenden!
18. Child Theme • Mehraufwand für ein Child Theme statt direkte Anpassung des Themes: • Gesparter Wartungsaufwand durch Child Theme: ca. 5 Minuten (bei IDE Unterstützung) unbezahlbar
19. WordPress Plugin Child Theme Theme add_filter add_hook CSS Templating
20. Real Life Probleme • Themes bundeln immer wieder Plugins – Updates der Plugins nur über Theme Updates (Das TimThumb Debakel) • Für viele Endanwender ist der Aufwand ein Plugin zu erstellen immer noch zu groß • Entwickler sehen zum Teil nicht den langfristigen Betrieb, sondern nur die kurzfristige Aufgabenerfüllung • Fehlersuche bei Code in functions.php unnötig komplex • Themewechsel wird zum Alptraum weil alles Mögliche in der functions.php gecoded ist • Codeversionierung einer functions.php nicht sinnvoll möglich Grundsätzlich sollte Code, der von Dritten entwickelt und betreut wird NICHT verändert werden
21. Architektur noch immer ein Fremdwort? Jan Thiel Jan@WLWP.eu https://WLWP.eu Icon made by Freepik from www.flaticon.com are licensed under CC BY 3.0