Externe Links unter WordPress in neuem Fenster öffnen

Im Web hat es sich eingebürgert, dass externe Links in einem neuen Tab geöffnet werden, während interne Links im selben Tab geöffnet werden. Wer WordPress als CMS nutzt, kann dieses Verhalten mittels eines Plugins nachrüsten.

Open in New Window Plugin
Preis: Kostenlos

Das Plugin Open in New Window Plugin fügt externen Links das Attribut:

target="_blank"

hinzu. Im Gegensatz zu einigen anderen Plugins funktioniert das Open in New Window Plugin auch auf mobilen Systemen unter iOS und Android.

Panorama-Plugin für WordPress

Für die Darstellung eines 360° Panorama, in der Rektangularprojektion (equirectangular), gibt es unter WordPress einige Plugins. Eines dieser Plugins ist DImage 360.

DImage 360
Preis: Kostenlos

Mithilfe des Plugins können Panoramen einfach per Shortcode in die Seite eingebunden werden:

[dimage attachment_id="123" control=true auto-rotate=true]

Übergeben wird hierbei die Attachment-ID, welche über den Medienmanager von WordPress ermittelt werden kann. Auf Mobilgeräten beherrscht DImage 360 einen Cardboard-Modus, sodass die Panoramen auch in einer Cardboard-kompatiblen VR-Brille angeschaut werden können.

Das Plugin in Aktion

Einziger Wermutstropfen bei der Nutzung über mobile Geräte ist ein Problem mit dem Vollbildmodus, welcher sich nur auf dem Desktop aktivieren lässt. Der Quellcode für das Plugin ist auf GitHub zu finden. Leider sind dort keinerlei Lizenzinformation hinterlegt.

Cachify-Cache per Cronjob bereinigen

Cachify ist ein WordPress-Plugin zum einfachen und effektiven Cachen der eigenen WordPress-Instanz. Das Plugin bietet unterschiedliche Methoden für das Caching an. So kann der Cache z.B. in der Datenbank oder auf der Festplatte angelegt werden. Meine bevorzugte Methode ist die Ablage des Caches auf der Festplatte.

Cachify
Preis: Kostenlos

Dies hat einige Vorteile. So kann der Cache, wenn vorhanden, direkt über den Webserver ausgeliefert werden. Die Ausführung von PHP oder die Anfrage auf der Datenbank entfällt. Dies wirkt sich extrem positiv auf die Geschwindigkeit aus. Allerdings funktioniert der automatische Ablauf des Caches bei der Festplatten-Methode leider nicht. Hier muss stattdessen ein Cronjob eingerichtet werden:

sudo -u www-data crontab -e

Im Cronjob soll einmal der Cache bereinigt werden und anschließend die Hauptseite geöffnet werden, damit für diese wieder ein Objekt im Cache angelegt wird:

rm -rf /var/www/example/main/wp-content/cache/cachify/*
curl --silent https://example.net > /dev/null

Beim ersten Befehl wird der Ordner, in welchem der Cache liegt, gelöscht. Anschließend wird mit cURL die Hauptseite aufgerufen, um den Cache wieder aufzufüllen. In der Crontab-Datei sieht dies wie folgt aus:

0    *    * * *   rm -rf /var/www/blankensee/main/wp-content/cache/cachify/* & curl --silent https://blankensee.net > /dev/null

Damit wird der Cache einmal in der Stunde gelöscht und der Cache der Hauptseite wieder neu aufgebaut.

Post-ID unter WordPress ermitteln

Manchmal wird die Post-ID einer Seite unter WordPress benötigt. Dann stellt sich die Frage, wie diese ID ermittelt werden kann? Wenn die ID Teil des Permalinks ist, so kann sie einfach anhand der URL ermittelt werden.

Die Post-ID spiegelt sich im Permalink wieder

Bei Beiträgen funktioniert diese Variante in vielen Fällen, bei Seiten wird dies schwieriger. Um die Post-ID einer beliebigen Seite oder eines Beitrages zu ermitteln, muss diese im WordPress-Backend bearbeitet werden. Dort findet sich in der Adressleiste eine URL nach folgendem Schema:

https://seeseekey.net/wp-admin/post.php?post=125008&action=edit

Der Wert hinter dem Parameter post spezifiziert die Post-ID, welche somit ermittelt wurde.

WordPress-Suchwidget auf bestimmte Post Types beschränken

Für eine WordPress-Installation war ich auf der Suche nach einer Möglichkeit die Suche bzw. im Speziellen das Suchwidget so zu beschränken das nur die Post Types page und post durchsucht und angezeigt werden. Möglich ist dies, indem ein Filter für pre_get_posts in die functions.php des Themens hinzugefügt wird:

function search_only_in_specific_post_types( $query ) {
	
  // Modify query (but only in frontend)
  if ( $query->is_search && is_admin() == false ) {
    $query->set( 'post_type', array( 'page','post') );
  }
	
  return $query;
}

add_filter( 'pre_get_posts', 'search_only_in_specific_post_types' );

Der Filter passt die Query an, wenn die Query für eine Suche genutzt wird und diese Nutzung aus dem Frontend heraus geschieht. Die Begrenzung auf des Frontend ist notwendig um keine Suchqueries im Backend zu stören. Damit würde die modifizierte Suche nur noch Dokumente mit dem Post Type page und post finden.