Alle Beiträge von zauni

Positionierung von Custom Fields oder wie bekomme ich Felder in die Sidebar: Der ‚context‘-Parameter ist dein Freund!

Wir verwenden ACF und Custom Fields sehr häufig um unseren Produkten einen deutlich komplexeren Aufbau zu ermöglichen.
Daher machen wir uns auch immer reichlich Gedanken darüber, wie wir den Aufbau so einfach und logisch wie möglich gestalten können.

Dazu gehört nicht nur die Auswahl der Darstellungsform, sondern natürlich auch die Auswahl des Orts, wo wir unsere Custom Fields eingeblendet haben wollen.

Wenn ein Artikel z.B. ein alternatives Beitragsbild erhalten soll, ist es unsinnig dieses Feld direkt nach dem Titel anzuzeigen. Es sollte natürlich seitlich in der Nähe des primären Beitragsbild zu finden sein. Und das können wir ja ganz einfach steuern, oder?

Custom Fields und ACF

Wie wir Custom Fields erstellen, soll hier nicht Thema sein. Daher gehe ich nur auf die Funktion ein, mit der wir die Position festlegen können.

Hierfür verwenden wir die Funktion „add_meta_box( $id, $title, $screen, $context, $priority, $callback_args );„. Diese Metabox soll dann unsere Custom Fields beherbergen.

Der „context“ gibt dabei an, in welchem Bereich die Metabox angezeigt werden soll und mit „priority“ können wir zu einem bestimmten Grad festlegen, ob die Metabox vor oder nach anderen Metaboxen angezeigt wird.

ACF hat dafür natürlich einen eigenen Einstellungsbereich, bei dem wir ohne etwas zu programmieren zu unsern Custom Fields kommen.

Beispiel für die ACF Einstellungen

Hier im Screenshot sehen wir die Auswahl der Position unserer neuen Feldgruppe mit ACF.

Die Freiheit der Benutzer, die (unnötige?) Arbeit des Entwicklers

Egal wie gut und durchdacht unsere Logik dahinter ist, so bietet WP jedem Benutzer die Möglichkeit seine Eingabemaske so umzustellen, wie er oder sie es gerne hätte.

Denn die Informationen, wie Custom Fields und ACFs im Backend angezeigt werden, speichert WP in der Datenbank für jeden Nutzer einzeln in der Tabelle „_usermeta“ mit dem Key „meta-box-order_page“ ab.

Aber ist diese Geistesanstrengung dann überhaupt nötig?

Absolut! Immerhin dürfen wir nicht vergessen, dass der Großteil der Nutzer dieses Feature vermutlich gar nicht kennt. Außerdem zählt ja auch der erste Eindruck. Und den geben immer noch wir vor!

Aber einen wichtigen Punkt gibt es hierbei zu bedenken und der ist auch der Grund für diesen Artikel.

Achtung bei nachträglichen Änderungen

Sobald wir uns entscheiden, ein Feld im Nachhinein umzustellen, kann es passieren, dass ein Nutzer von dieser Umstellung nichts mitbekommt.

Denn jeder Nutzer, der bereits aktiv mit unseren Custom Fields oder unsern ACFs gearbeitet hat, der hat noch die alten Positionsangaben in der Datenbank stehen und ist somit von unseren Umstellungen ausgeschlossen.
(Zumindest solange wir hier nicht programmatisch eingreifen und auch gleich diesen Wert in der „_usermeta“-Tabelle ändern…)

In Kurz: Hat ein User bereits ein bestehendes ACF-Feld bearbeitet, wird zu den Usermetadaten die Aufteilung des Backends gespeichert und Änderungen kommen beim User nicht an!

Das ist für alle Entwickler zu bedenken, die im Nachhinein ACF-Felder bearbeiten und in der Position verschieben.

 

weiterführende Links:

Custom Fields

Custom Meta Boxes

add_meta_box()

Creating a Field Group

Aus einem hell-braunen Platzhalter wird ein Bild

WordPress beschleunigen und optimieren – Ein Blick auf srcset/sizes und lazy-loading

Damit die eigenen Artikel oder Produkte heutzutage aus der Masse heraus stechen, sollte man tief in die Trickkiste greifen.

Dieser Artikel soll aber nicht an dieser Trickkiste rütteln, sondern zwei Techniken näher beleuchten, die einem dabei helfen können. Es geht dabei um die HTML5 Attribute „srcset“ und „sizes“ und um die Technik des „lazy-loadings“.

Das Grundproblem

Wenn ich heute als Autor im Internet ein Bild hochlade, dann ist mir meist egal, welche Größe das Bild hat. Immerhin lebe ich Österreich oder Deutschland  in einem Land, das mir schnelles, unlimitiertes Internet für wenig Geld anbietet. (Gut – für Deutschland gilt das unter Vorbehalt :p )

Doch bereits in Deutschland gibt es Orte, an denen das bereits Luxus ist. Um allen Nutzern der Website das best mögliche Erlebnis zu bieten, sollte ich die Bilder also besser aufbereiten, damit niemand mehrere Sekunden warten muss oder mehrere MB herunterladen muss, um die Seite komplett sehen zu können.

Die Techniken

srcset- & sizes-Attribut

Der erste Bereich sollte heutzutage wirklich kein Thema mehr sein.

Wer selbst an einem Theme schreibt, der wird höchstwahrscheinlich die WordPress Funktionen „get_the_post_thumbnail()“ oder „the_post_thumbnail()“ verwenden.

Diese Funktionen geben mir bereits alles was ich brauche. Sie liefern gleich das ganze HTML mit dem srcset- und dem sizes-Attribut aus. Für Bilder, die nicht als featured-image eingebunden wurden, gibt es noch die Funktion „wp_get_attachment_image( $attachment_id )“, der wir als ersten Parameter die „$attachment_id“ des Bildes übergeben.

Auch hier erhalten wir wieder ein voll funktionsfähiges HTML mit srcset- und sizes-Attribut. Praktisch, dass WordPress im Hintergrund ohnehin für jedes hochgeladene Bild mehrere Versionen für die verschiedenen Größen anfertigt und auf der Festplatte des Servers abspeichert.

img-Element mit srcset- und sizes-Attribut
img-Element mit srcset- und sizes-Attribut

Aber da wir immer wieder auf Themes stoßen, die die beiden Attribute noch nicht verwenden, möchte ich hier auf ein praktisches Plugin verweisen, das Bilder aus dem Contentbereich nachträglich das srcset-Attribut verpasst.

responsify-wp

Es handelt sich um „responsify-wp“ von Stefan Ledin. Für das Plugin sei allerdings angemerkt, dass seine Möglichkeiten begrenzt sind und z.B. keine Bilder außerhalb des eigentlichen Contents mit den mächtigen HTML5-Attributen versehen kann.

Die wichtigsten Einstellungen zu responsify-wp
Die wichtigsten Einstellungen zu responsify-wp

Sollte ein Theme sehr viele verschiedene Bildgrößen definieren, kann man in den Einstellungen praktischerweise steuern, welche Bildgrößen für die beiden Attribute verwendet werden sollen. Das verhindert das unnötige aufblähen des img-Elements.

responsify-wp. Steuerung, welche Bildgrößen verwendet werden sollen.
responsify-wp. Steuerung, welche Bildgrößen verwendet werden sollen.

Warum sind diese Attribute so mächtig?

Nun durch diese Attribute kann sich der Browser selbst aussuchen, in welcher Größe das Bild geladen und angezeigt wird. Auf Smartphones, deren Bildschirm sehr viel kleiner ist als ein 24‘‘ Bildschirm, brauche ich kein Bild laden, das die 9 fache Größe hat, oder? Das wäre in mehrfacher Hinsicht unnötig.

lazy-loading

Beim lazy-loading geht es nicht mehr darum, wie groß das Bild an sich ist, sondern darum, ob das Bild überhaupt geladen/angezeigt werden soll.

Bilder, die auf dem aktuellen Bildschirmausschnitt nicht zu sehen sind, müssen nicht unbedingt vom Server heruntergeladen werden.

Wer kann schon wissen, ob der Nutzer überhaupt weitere Bereiche der Seite ansieht oder nicht vielleicht schon auf einer anderen Seite ist?

Daher haben wir in weiterer Folge ein paar Tipps für Plugins, die einem das ermöglichen.
Anders als das srcset-Attribut, das in seiner Handhabung nun wirklich keine Hexerei ist, ist es doch mit erheblichem Mehraufwand verknüpft, diese Funktionalität selbst zu programmieren. Deshalb besprechen wir ein paar Plugins.

Dominant colors lazy loading

Zu Beginn hätten wir mit „Dominant colors lazy loading“ einen besonders interessanten Vertreter, der diese Funktion auch gleich mit einem weiteren grafischen Schmankerl versehen hat.

Zu Beginn wird die Mediathek vom Plugin nach Bildern durchsucht um eine dominante Farbe aus jedem einzelnen Bild zu identifizieren.

Einstellungen des Plugins 'dominant colors lazy loading'
Einstellungen des Plugins ‚dominant colors lazy loading‘

So lange das Bild nicht geladen wird, wird der Bereich des Bildes stattdessen in der zuvor errechneten dominanten Farbe angezeigt.

Das löst auch gleich ein anderes Problem, das auftreten kann, wenn Bilder sehr viel später auf der Seite angezeigt werden, als reiner Text. Wenn statt dem Bild einfach nichts gezeigt werden würde, müsste sich das Bild erst einen Platz verschaffen um angezeigt zu werden. Dadurch kann es zu unschönen Sprüngen im Contentbereich kommen.

Aus einem hell-braunen Platzhalter wird ein Bild
‚dominant colors lazy loading‘ bei der Arbeit: Aus einem hell-braunen Platzhalter wird ein Bild

Bei diesem Plugin ist zu beachten, dass es die WordPress-typische CSS Klasse (z.B. wp-image-5) für Bilder benötigt, um seiner Arbeit nachgehen zu können.
Sollte ein Theme diese nicht hinterlegt haben, wird dieses Plugin leider nicht funktionieren.

Andere lazy loading Plugins

Daneben sind noch „rocket lazy load“ und vor allem „crazy-lazy“ zu erwähnen, die in den meisten Fällen ohne Probleme funktionieren sollten. Ein etwas älterer Vertreter ist „lazy-load“, das allerdings seit über 2 Jahren kein Update mehr erhalten hat.

Nonces in WordPress

Im WP-Kontext sind Nonces eine zufällige Aneinanderreihung von Zahlen und Buchstaben, die zwar mehrmals verwendet werden (im Gegensatz zur üblichen Implementierung von Nonces – Number used once), aber ein klar definiertes Ablaufdatum haben.

Wie bereits im Artikel WordPress Sicherheit bei Formulareingaben und AJAX Aufrufen – verwendet Nonces! beschrieben wurde, sollen Nonces dabei helfen, URLs und Formulare auf Websites vor missbräuchlicher Benutzung und anderem Unfug zu schützen.

Erstellung

URLs

werden mit wp_nonce_url( $actionurl, $action, $name ); aufgerufen.

  • $actionurl ist die URL, die wir mit der Nonce „absichern“ wollen.
    • required; Default: None
  • $action ist der Name der action, die wir frei wählen können.
    • optional; Default: -1
  • $name ist der Name der so generierten Nonce.
    • optional; Default: _wpnonce

Als Rückgabewert erhalten wir eine bereinigte URL mit zusätzlicher Nonce. Diese sieht in etwa so „http://example.com/wp-admin/post.php?post=123&action=trash&_wpnonce=b192fc4204“ aus.

Forms

werden mit wp_nonce_field( $action, $name, $referer, $echo ); aufgerufen. Diese Funktion generiert uns bis zu zwei hidden input Elemente.

  • $action definiert den Namen der action.
    • optional, aber empfohlen; Default: -1
  • $name ist der Name der so generierten Nonce.
    • optional. Default: _wpnonce
  • $referer gibt an, ob ein zusätzliches hidden input Element erstellt werden soll, das den Output der Funktion wp_referer_field beinhaltet.
    • optional; Default: true
  • $echo gibt an, ob die so erstellten inputs im HTML ausgegeben werden.
    • optional; Default: true

Als Rückgabewert erhalten wir ein oder zwei hidden input Elemente, wenn $referer true ist.

Beispiel für wp_nonce_field in Formularen.

Validierung

Allgemein

check_admin_referer( $action, $name ); überprüft sowohl die Nonce als auch den $referer.

  • $action ist der Name der action, die wir frei wählen können.
    • optional; Default: -1
  • $name ist der Name der so generierten Nonce.
    • optional; Default: _wpnonce
AJAX

check_ajax_referer( $action, $query_arg, $die ); überprüft nur die Nonce im Zuge eines AJAX-Requests.

  • $action ist der Name der action, die wir frei wählen können.
    • optional; Default: -1
  • $query_arg ist der Name der so generierten Nonce
    • optional; Default: false
  • $die gibt an, ob das script angehalten werden soll, wenn die Überprüfung fehlschlägt
    • optional; Default: true
Basic

wp_verify_nonce( $nonce, $action ); überprüft nur die Nonce.

  • $nonce ist der Name der Nonce, die überprüft werden soll.
    • required; Default: None
  • $action ist der Name der action.
    • optional; Default: -1

Eine einfache Überprüfung könnte z.B. so aussehen:

Validierung der wp-nonce mit wp_verify_nonce.

Weiterführende Informationen:

Update vom 10. Juli. 2018:
In der Wikipedia gibt es jetzt eine Erklärung zum Begriff „Nonce“:
https://de.wikipedia.org/wiki/Nonce