Archiv für das Jahr: 2020

ACF Position „Nach dem Titel vor dem Inhalt“ funktioniert nicht (Lösung)

ACF Position high funktioniert nicht

Mit dem WordPress-Plugin ACF (Advanced Custom Fields) lassen sich zum Teil sehr komplexe Eingabemasken bauen. Umso wichtiger ist es, daß man auch bestimmen kann, an welcher Stelle welche Feldgruppe angezeogt wird. In ACF stehen dazu grundsätzlich erstmal drei Positionen zur Verfügung: „Nach dem Titel vor dem Inhalt“ (bzw. „High (after title)“ in der englischen Variante) läßt die Feldgruppe zwischen Titel und Texteditor erscheinen – „Nach dem Inhalt“ (bzw. „Normal (after content)“ in englisch) führt dazu, daß die Feldgrupper unterhalb des Texteditor angezeigt wird und bei Auswahl von „Seitlich neben dem Inhalt“ („Side“) wird die Feldgruppe in der Seitenleiste (rechts) angezeigt.  Meine favorisierte Position ist häufig die, bei der die zusätzlichen Eingabefelder zwischen Titel und Texteditor positioniert sind.

Beim Editieren einer Seite kann es dann aber passieren, daß man die Position der Feldgruppe versehentlich ändert. Dann sitzt diese plötzlich unterhalb des Texteditors. Leider kann man die Feldgruppe dann nicht einfach per Hand zurück schieben. Fast alle Elemente der Eingabemaske lassen sich auf fast alle Positionen verschieben – der Bereich zwischen Titel und Texteditor ist aber unerreichbar.

Mithilfe eines Code-Schnippsels, der in der functions.php platziert wird, kann man die manuelle Verschiebung aber rückgängig machen, bzw. aufheben.

function prefix_reset_metabox_positions(){
  delete_user_meta( wp_get_current_user()->ID, 'meta-box-order_post' );
  delete_user_meta( wp_get_current_user()->ID, 'meta-box-order_page' );
  delete_user_meta( wp_get_current_user()->ID, 'meta-box-order_YOUR_CPT_SLUG' );
}
add_action( 'admin_init', 'prefix_reset_metabox_positions' );

Den Code habe ich hier im ACF-Support-Forum gefunden:

Position : High (after title) not working

Aber vorsicht: die Funktion prefix_reset_metabox_positions sorgt dafür, daß die Meta-Boxen immer zurück auf ihre z-B. von ACF vorgegebene Position versetzt werden. Ein manuelles Umorganisieren der Eingabefelder und Feldgruppen ist dann nicht mehr möglich. Mir ist das gang recht – ich möchte nicht, daß Feldgruppen manuell auf eine andere Position geschoben werden. Wer der Redaktion aber diese Möglichkeit zur Umgestaltung der EIngabemaske lassen möchte, sollte den Code-Schnippsel nach erfolgreim Zurücksetzen wieder aus der functions.php entfernen.

Verhindern, dass WordPress große Bilder klein rendert („scaled“)

Wordpress scaled grosse Bilder

Wordpress scaled grosse Bilder – Screenshot/Montage T.Bortels/cpu20.de

Seit Version 5.3 werden „große Bilder“ von WordPress automatisch neu gerendert – also klein gerendert – und mit dem Hinweis „scaled“ im Dateinamen versehen. Das kann nützlich sein, um zu vermeiden, daß allzu große Bilder an die Nutzer ausgeliefert werden. Die Absicht ist also erstmal gut. Doch was gut gemeint ist muß nicht immer gut sein. Was ist ein „großes Bild“ aus Sicht von WordPress? Ab 2560px gilt ein Bild für WordPress als ein „großes Bild“.

Wer sein WordPress-Theme selbst baut möchte volle Kontrolle haben – auch und vor allem über die Größe der angezeigten Bilder. Das Feature, das die Bilder automatisch verkleinert und mit dem Hinweis „scaled“ im Dateinamen versieht, erscheint einem dann eher als Bug.

Um das Problem zu umgehen kann man diese neue Funktion manuell abschalten. Allerdings sollte man die entsprechende Anpassung nach Möglichkeit gleich zu Beginn einbauen, noch bevor zu viele Inhalte bzw. Bilder auf den Server geladen wurden. Sonst verbringt man wohlmöglich viel Zeit damit, die Bilder erneut hochzuladen.

Scaled-Funktion big_image_size_threshold deaktivieren

Um die Funktion nun zu deaktivieren muß man lediglich folgenden Code–Schnippsel einfach in die functions.php einfügen und der Spuk hat ein Ende:

// Prevent WordPress from Scaling Large Images
add_filter( 'big_image_size_threshold', '__return_false' );

Damit ist dieses Feature nun abgeschaltet.

Wie gesagt: am besten, man implementiert diesen Filter bevor man anfängt, viele große Bilder hochzuladen. Sonst muß man nämlich nachträglich nochmal alle großen Bilder hochladen.

Alternativ könnte man auch die Grenze anders definieren, von der an Bilder als große Bilder betrachtet bzw. behandelt werden. Möchte man beispielsweise, daß Bilder ab einer Seitenlänge von 4800px als „groß“ betrachtet werden, kann man folgenden Code-Schippsel in die functions.php einsetzen:

/**
 * Increases the threshold for scaling big images to 4800.
 * In this case all the images that are larger than 4800px (width or height) 
 * will be scaled to 4800px.
 *
 * @param $threshold
 * @return int
 */
function hff_big_image_size_threshold( $threshold ) {
	return 4800; // new threshold
}
add_filter('big_image_size_threshold', 'hff_big_image_size_threshold', 100, 1);

Hier die Seite zur Funktion bei make.wordpress.org/core/ …

Lazyload manuell in WordPress integrieren

Was ist Lazyload? Und warum brauche ich Lazyload?

Lazyload ist ein Skript, das dafür sorgt, dass Bilder, die nicht sichtbar sind, nicht geladen werden. Oder umgekehrt ausgedrückt: es werden nur die Bilder geladen, die im Sichtfeld des Nutzers sind. Und das kann viele Vorteile haben. Vor allem natürlich Performance-Vorteile.

Lazyload ist ein eigenständiges Skript. Somit kann es theoretisch in jede Webseite integriert werden, egal ob diese auf WordPress basiert, oder nicht. Es gibt natürlich inzwischen auch verschiedene WordPress-Plugins, die Lazyload in WordPress integrieren – aber ich bin in solchen Fällen immer gerne für eine Lösung ohne weitere Plugins zu haben.zum Glück funktionert die Implementierung von Lazyload in WordPress auch ausgesprochen problemlos.

Lazyload manuell in WordPress integrieren

Zunächst muss man Lazyload als Skript interieren. Dazu habe ich die Javascript-Datei einfach in ein entsprechendes verzeichnis „js“ in meinem theme hinterlegt. Die js-Datei (sowie viele hilfreiche Tipps) ist hier beim Autor von Lazyload zu finden: https://www.andreaverlicchi.eu/vanilla-lazyload/

 <script src="/wp-content/themes/mytheme/js/lazyload.min.js"></script>

Ich habe das hier mal händisch gemacht – natürlich sollte man das Skript eigentlich über die function.php laden. Aber so geht’s auch.

Dann muß man Lazyload natürlich noch aufrufen. Das habe ich per Skript-Aufruf im Footer (footer.php) eingerichtet:

<script>


var lazyLoadInstance = new LazyLoad({
// Your custom settings go here
});

</script>

Es gibt verschiedene Optionen und Möglichkeiten, wie man Lazyload nutzen kann. Ich habe mich dafür entschieden, daß ich zunächst ein Bild mit geringer Auflösung – und anschließend per Lazyload ein Bild mit hoher Auflösung nachladen möchte. Dazu muß man lediglich jedem Bild bzw. IMG-tag die entsprechenden Quellen zuweisen:

 <img class="lazy" src="<?PHP echo($low_res_url); ?>" data-src="<?php echo esc_url( $high_res_url); ?>" />

Und fertig. Oder?

 

Parent-Child-Seiten – Parent-ID und Child-Tiefe herausfinden

Parent Page Wordpress

Neben einfachen Beiträgen kann man mit einer Standard-Installation von WordPress in der Regel auch Seiten (bzw. Pages) anlegen. Inhalte vom Typ Page lassen sich einfach hierarchisch organisieren – eine Funktion, die selten voll ausgenutzt wird. Mithilfe eines Seitenbaums, bei dem eine beliebige Anzahl von Seiten per Parent-Child-Verbindung hierarchisch organisiert ist, lassen sich komplexe Verzeichnisse aufbauen. Aber wie behält man den Überblick?

Zunächst ist es häufig hilfreich, die ID der übergeordneten Parent-Seite für jede beliebe Seite nutzen zu können. WordPress bringt diese Funktionalitöt mit – jede Seite weiß im Prinzip, wessen Kind (Child) sie ist. Oder um es etwas korrekter auszudrücken: die ID der Parent-Seite ist immer auch Teil des Post-Objektes.

global $post;
$parent_ID = $post->post_parent;

Mithilfe dieses Snippets lassen sich schon eine ganze Menge Dinge umsetzen.

Was aber, wenn man es mit einer mehrstufigen Hierarchie zu tun hat?

Auch dafür gibt es Bordmittel: get_post_ancestors

Über diese Funktion lassen sich im Prinzip alle „vererbenden“ Eltern-Seiten finden – also alle übergeordneten „Parent-Pages“.

(leider habe ich diesen beitrag nie komplettoert. Ich bitte das zu entschuldigen.)