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.
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.
Für die Darstellung eines 360° Panorama, in der Rektangularprojektion (equirectangular), gibt es unter WordPress einige Plugins. Eines dieser Plugins ist DImage 360.
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 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.
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.
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.
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.