1. Januar 2018 • Ekkart • plugin, postponeposts, Wordpress • ToDo
Ich hab wieder ein WordPress-Plugin geschrieben, diesmal etwas sinnvoller als mein letztes.
Das Postpone-Posts-Plugin verschiebt alle zukünftigen Beiträge um x Tage (x wählbar). Das soll es mir erleichtern, Beiträge vorzuschreiben und nicht mühsam einzeln zu verschieben, wenn etwas dazwischenkommt. Wir werden sehen, ob das klappt.
Das Plugin liegt auf WordPress.org unter https://wordpress.org/plugins/postpone-posts/, der Quellcode in github unter https://github.com/ekleinod/postpone-posts.
Entwickelt habe ich das mit Texteditor und Docker. Texteditor (jEdit) für die Plugin-Datei, Docker für die Entwicklungsumgebung, ohne mir den Rechner mit Datenbank, Server etc. vollzumüllen.
Docker ist tatsächlich recht einfach nutzbar, die Doku ist ok, meine Notizen dazu stehen unter http://www.ekkart.de/computer/wordpress/plugins.html
Die Plugin-Entwicklung selbst ist relativ einfach (das Problem war auch nicht schwierig), die WordPress-API ist durchaus vernünftig aufgebaut und halbwegs gut dokumentiert, es gibt ein Plugin-Entwicklungshandbuch.
Das “halbwegs” ist dabei das oft ein Problem, viele Dinge werden nicht wirklich gut erklärt, das ist beim Verstehen einer API eher schlecht. Zu den meisten Problemen gibt es im Handbuch oder unter der API-Beschreibung Beispielcode oder in Google eine schnelle Antwort. Ich kann trotzdem nur empfehlen, mit einem sehr einfachen Plugin mit der Entwicklung zu beginnen.
Der Code des Plugins ist in github abgelegt.
Ich habe allen Code in eine Klasse gepackt, um Namensprobleme mit existierenden Funktionen zu vermeiden. Die Entscheidung funktioniert für mein Plugin, dessen Funktionalität wenig Code umfasst. Bei einem größeren Projekt würde ich evtl. eher mit Präfixen für Funktionen arbeiten, um den Code in einzelnen Dateien kapseln zu können. Oder mehrere Klassen verwenden, das käme auf den Versuch an.
Was ich sehr verwirrend fand, waren die verschiedenen IDs, Slots und sonstigen Bezeichner, die für die Nutzung der API und der Hooks nötig sind. Deshalb sind diese Dinge meist exzessiv kommentiert, damit ich mich da wieder reinfitzen kann.
Die Lokalisierung und Internationalisierung war erstaunlich problemlos möglich. Ich hatte Datumausgaben sowieso in einer eigenen Methode gekapselt, die ich nur einmal anpassen musste. Für Texte habe ich auch gleich die __-Methoden genutzt. Für die Singular/Plural-Unterscheidung und Nummerformatierung gibt es ebenfalls eigene Methoden, die ich erst später gefunden habe. Sie einzubauen war aber auch kein Problem. Für die Internationalisierung der reinen Texte gibt es ein gutes Werkzeug – poedit.
Insgesamt war es eine gute Idee, ein einfaches Problem mit relativ wenig Code anzugehen, die Funktionalität fertigzubauen und die Schleifen (i18n etc.) erst später umzusetzen. Zu lange darf man mit den Schleifen aber auch nicht warten, um nicht zu viel Code umstellen zu müssen.