Eine Übersicht unserer Beiträge zur Entwicklung für WordPress und Atlassian Confluence.
Entwicklung, WordPress
Für Entwickler bringt die neue WordPress Version 4.6 eine verbesserte Möglichkeit mit dem WP_Term_Query, Terms aus der Datenbank abzufragen.
Was sind Terms?
Ein Term ist ein Begriff der zu einer Taxonomie gehört. Eine Taxonomie besteht aus einem bis mehreren Terms. Ein oder mehrere dieser Terms können mit einem Beitrag verknüpft werden. Das Ziel dieser Verknüpfung ist es, Beiträge zu Kategorisieren um später schneller nach Beiträgen filtern zu können.
Ein Beispiel dafür ist die Taxonomie Fahrzeugtypen die alle verwendeten Fahrzeugtypen beinhaltet. Der Fahrzeugtyp wie Kleinwagen, Mittelklasse, Kombi oder Geländewagen ist ein Term.
Ein Beitrag über einen VW Polo kann dann mit einem Kleinwagen und einer über einen Golf mit den Fahrzeugtypen Kleinwagen und Mittelklasse verknüpft werden.
Neue Taxonomien wie die aus dem Beispiel können zu allen Beitragstypen hinzugefügt werden. Die bestehenden Kategorien von Beiträgen sind im Hintergrund nichts anderes als Terms innerhalb der Taxonomie “category” und die Schlagworte nichts anderes als Terms innerhalb der Taxonomie “post_tag”.
Abfragen von Terms
Die Klasse WP_Term_Query hilft uns WordPress Entwicklern Terms wie schon die Beiträge (WP_Query), Nutzer (WP_User_Query) und Kommentare (WP_Comment_Query) aus der Datenbank abzufragen.
Diese WordPress-Klassen bringen viele Möglichkeiten mit, ein Element auf einem standardisierten Weg aus der Datenbank zu filtern. Das hat den Vorteil das nicht jeder Entwickler eigene Datenbankabfragen schreiben muss. Innerhalb dieser Klassen wird die Caching-API von WordPress verwendet welche die Datenbankabfragen reduziert und die Anwendung schneller macht.
Weiterhin sind diese Klassen generell sicherer in der Verwendung. Das liegt einerseits daran, dass die Filterung von Eingaben durch den Benutzer berücksichtigt wird und viele Entwickler über diesen Quellcode geschaut haben (Stichwort Codereview). Andererseits können durch WordPress-Updates Fehler innerhalb dieser Klassen einfach und schnell behoben werden.
Mit der Standardisierung fällt es Entwicklern auch viel leichter den Quellcode für Fehleranalysen zu verstehen.
Eigene Abfragen zu schreiben lässt sich in bestimmten Fällen nicht vermeiden. Hier muss dann jedoch auf die Effizienz (Integration der Caching API) und die Sicherheit geachtet werden.
Fazit
Mit dem der Einführung der Klasse WP_Term_Query wird der Quellcode für die eigene Entwicklung weiter standardisiert. Komplexe und schlecht Wartbare und damit fehleranfällige Datenbankabfragen werden reduziert. Die Verständlichkeit für das Lesen von Quellcode wird erhöht.
Entwicklung, Tipps, WordPress
Nicht alle automatischen Ersetzungen des Textes im WordPress-Editor sind sinnvoll oder gewollt. Meiner Meinung nach gehört die automatische Ersetzung des einfachen Bindestrichs mit dem Gedankenstrich dazu. Das Problem dabei ist, dass der Editor im Visuellen Modus immer noch den Bindestrich ausspuckt aber innerhalb der sichtbaren Seite ein Gedankenstrich zu sehen ist.
WordPress hat intern für die Optimierung des Inhalts einen Filter-Hook the_content. Dieser Hook greift nachdem der Inhalt aus der Datenbank geholt wurde und bevor er ins HTML z.B. über die the_content() Funktion geschrieben wird.
Automatische Ersetzung für den Inhalts-Hook entfernen
Im WordPress sind standardmäßig die Funktionen wpautop und wptexturize auf den the_content Hook registriert. Für die automatische Ersetzung des Bindestrichs ist die wptexturize-Funktion verantwortlich. Der Aufruf kann für den Inhalts-Hook in der functions.php über folgende Quellcodezeile deregistriert werden.
remove_filter('the_content', 'wptexturize');
Damit sind jedoch alle automatischen Inhaltsoptimierungen dieser Funktion dahin.
Automatische Ersetzung für weitere Hooks entfernen
Neben dem Inhalts-Hook ist die wptexturize-Funktion auch auf dem Title-Hook und dem Excerpt-Hook registriert und kann deregistriert werden.
remove_filter('the_title', 'wptexturize');
remove_filter('the_excerpt', 'wptexturize');
Entwicklung, WooCommerce, WordPress
Manchmal ist es notwendig die Anzahl der voreingestellten Produkte im WooCommerce zu erhöhen oder zu erniedrigen. Dieser kurze Artikel zeigt wie es geht.
In der functions.php muss dazu der Filter “loop_shop_per_page” um die eigene Funktion erweitert werden.
add_filter( 'loop_shop_per_page', function ( $cols ) {
// Anzahl der Produkte
return 16;
}, 20 );
Diese Funktion gibt die Anzahl der Produkte im Shop (im Beispiel sind es 16) zurück. Der Filter hat als zweiten Parameter noch die Priorität (im Beispiel ist es 20).
Entwicklung, WordPress
In manchen WordPress-Anwendungsfällen kommt es vor, dass im Template “single.php” für einen Beitrag oder für einen benutzerdefinierten Content Typen im Template “single-{post_type}.php” eine Paginierung stattfinden soll.
Ein Beispiel wäre hier, dass alle weiteren Beiträge oder Content Typen direkt unter dem Inhalt des Beitrages oder Content Typen angezeigt und in diesem auch paginiert werden können.
Problem dabei ist, dass der Filter “redirect_canonical” bei einem Aufruf der Beitragsseiten oder Seite des Content Typen mit den Permalink-Parametern für die Paginierung “…/beitrag/page/x” dazwischenfunkt und auf “../beitrag/” weiterleitet. Der Filter kann über folgenden Code angepasst werden:
add_filter( 'redirect_canonical', 'namespace_redirect_canonical' );
function namespace_redirect_canonical( $redirect_url ) {
if ( is_singular( 'MY_CUSTOM_POST_TYPE' ) ){
$redirect_url = false;
}
return $redirect_url;
}
Das Beispiel schaltet die Weiterleitungen für einkommende Links für den Beitragstypen “MY_CUSTOM_POST_TYPE” aus. Ob eine Weiterleitung notwendig ist, kann als Erweiterung dieses Beispiels abgeprüft werden und bei Bedarf mit Paginierungs-Parametern weitergeleitet werden.
