Redirect 301 vs. 302

Wenn von einer Webseite auf eine andere Webseite umgeleitet wird, so wird hierfür meist der HTTP-Statuscode 301 oder 302 genutzt. Der Statuscode 301 leitet eine Anfrage permanent zur angegebenen URL um, während der Statuscode 302 früher für die temporäre Umleitung gedacht war. Unter Nginx könnte eine solche Umleitung wie folgt aussehen:

server {
  listen   443 ssl;
  listen [::]:443 ssl;

  server_name .example.com;

  return 301 https://example.org;
}

In diesem Fall würde alle Anfragen von example.com auf die URL https://example.org umgeleitet. Der Statuscode 301 zeigt dem Client hierbei an, dass die Umleitung permanent ist. Dies ist z.B. wichtig bei Suchmaschinen; sie würden der neuen URL mehr Beachtung schenken und die alte URL unter Umständen schneller aus dem Index entfernen. Der Statuscode 302 ist mittlerweile nicht mehr als Moved Temporarily, sondern als Found definiert.

Neben diesen Statuscodes, existieren eine Reihe weitere Statuscodes wie 303 (See Other), 307 (Temporary Redirect) und 308 (Permanent Redirect). Im Gegensatz zu den Statuscodes 301, 302 und 303 wird bei den neueren Statuscodes 307 und 308, das angefragte HTTP-Verb beibehalten. Fragt der Clients in einem solchen Fall mit dem HTTP-Verb POST an, so bleibt dieses bei der Weiterleitung bestehen.

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.

curl zur Abfrage von REST-APIs benutzen

Die Aufgabe des freien Kommandozeilentools curl ist einfach beschrieben: Datentransfer. So unterstützt curl unterschiedlichste Protokolle wie FTP, HTTP, HTTPS, IMAP, SCP, SMB und viele mehr. Ein einfacher Download einer Datei über HTTP bzw. HTTPS würde mit curl wie folgt aussehen:

curl -O https://example.com/file.zip

Auch ein Transfer z.B. per FTP ist kein Problem:

ftp://example.com/file.zip

Allerdings beherrscht curl wesentlich mehr Operationen als nur das Herunterladen von Dateien. So kann curl genutzt werden, um REST-APIs zu benutzen. Diese APIs arbeiten nicht nur mit dem HTTP-Verb GET, sondern auch mit anderen Verben wie POST und PUT. Ein einfacher GET-Request wurde mittels curl wie folgt aussehen:

curl -X GET https://example.com/

Ein POST-Request wird auf die gleiche Art durchgeführt:

curl -X POST https://example.com/

Sollen zusätzlich Daten übertragen werden, so geschieht dies mit dem Parameter -d:

curl -X POST https://example.com/  -d '{
	field: "data",
	field2: "data",
	field3: "data"
}'

Damit werden die Daten im Body des Requests mitgesendet. Auch die Übergabe von Headern ist mittels curl möglich:

curl -X POST https://example.com/ 
 -H 'HeaderField: headerValue'
 -d '{
	field: "data",
	field2: "data",
	field3: "data"
}'

Manche APIs und andere Services blockieren Abrufe über curl manchmal. Dabei wird der Useragent von curl ausgesperrt. Allerdings kann dieser einfach geändert werden:

curl -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0" -X GET https://example.com/

Damit können solche fragwürdigen Maßnahmen, welche zum Ausschluss von curl führen, umgangen werden. Daneben verfügt curl über viele weitere Operationen bzw. Optionen. So kann z.B. mittels des Parameters -I nur der Header des Response bezogen werden:

curl -I -X GET https://example.com

Somit bietet curl die entsprechende Funktionalität um REST-APIs für Tests und ähnliches flexibel abzufragen.