Seit WordPress 5.4 wird standardmäßig das WordPress-Logo als Favoriten-Icon (Favicon) ausgegeben. Wer bisher kein Favicon im Customizer definiert hat, der wunderte sich vielleicht, warum da plötzlich das WordPress-Logo angezeigt wird. Die Erklärung dahinter ist aber gar nicht so einfach und hat eine lange Geschichte. Gehen wir dem doch mal ein wenig auf dem Grund.
Das Ticket im Core-Trac ist bereits 15 Jahre alt und zeigt schon das grundsätzliche Problem, dass hier eigentlich verhandelt wird. Geschwindigkeit. Denn wenn es kein Standard-Icon gibt, dann wird ein 404 für den Request fällig (der über WordPress gerendert wird) und das belastet den Speicher, die Datenbank und den PHP-Interpreter unnötig.
Ein zusätzliches Problem ist, dass grundsätzlich zwei Möglichkeiten gibt ein Favicon einzubinden. Über eine Zeile im Markup oder indem die Datei in den Webroot gelegt wird.
Lösung Nummer 1 war dann auch entsprechend simpel. Es wurde nur unterbunden, dass WordPress doppelt geladen wird und die Header für ein leeres Favicon wurden gesendet. Damit war das grundsätzliche Problem erst einmal gelöst. Dann aber wurden Favicons immer beliebter und als auch Google anfing, sie anzuzeigen, wurde die Frage laut, wie das standardisiert werden könnte.
Das führte daher Jahre später zu Ticket #16434 und WordPress 4.3 , welches das Site Icon Feature in den Customizer brachte. Damit konnte -neben dem Favicon- auch andere Icons (zum Beispiel für das Hinzufügen auf dem Smartphone) einfach eingebaut werden. Dafür sollte das Bild nur mindestens 512×512 Pixel haben.
Dann wurde das ursprüngliche Problem nochmal in Ticket #47398 aufgemacht, denn die bisherige Lösung war nicht flexibel genug. Da WordPress ein „leeres“ Favicon sendete, sofern keine favicon.ico-Datei im Webroot ist, war es schwer bis unmöglich programmatisch einzugreifen via Filter (denn der war nicht vorhanden und wäre auch schweirig einzubinden gewesen, da zu diesem Zeitpunkt die Plugins noch nicht geladen waren). Was uns zu der Lösung mit dem WordPress-Logo als Standard-Icon bringt, welches in der Dev Note erklärt wird. Die neue Logik war wie folgt:
Wenn im Customizer ein Site Icon eingestellt ist, werden Anfragen an /favicon.ico auf dieses im Customizer definierte Icon aus der Mediathek umgeleitet. Ist kein Icon definiert, dann wird das WordPress-Logo als Standard-Icon verwendet. Sofern eine reale /favicon.ico-Datei vorhanden ist, passiert gar nichts und der Server beantwortet einfach die Anfrage mit der entsprechenden Datei.
(Das klappt allerdings nur dann korrekt, wenn WordPress im Webroot installiert ist.)
Mit dem do_faviconico Action Hook kann das Verhalten auch wieder geändert werden:
<?php
//Inspiration: https://gist.github.com/florianbrinkmann/a879099f3d28c5e1d64f2aeea042becf
add_action( 'do_faviconico', function() {
//Check for icon with no default value
if ( $icon = get_site_icon_url( 32 ) ) {
//Show the icon
wp_redirect( $icon );
} else {
//Show nothing
header( 'Content-Type: image/vnd.microsoft.icon' );
header( 'Content-Length: 0' );
}
exit;
} );
Der Vorteil an diesem Gist ist, dass er nur das WordPress-Logo verhindert und das Favicon nicht generell unterbindet. Gerade bei Multisites mit gemischten Websites, die mal mit und mal ohne Site Icon ausgestattet sind, ist dies der bessere Ansatz.
Meine Empfehlung wäre jedoch in jedem Fall ein Site Icon einzurichten. Für ganz unkreative Menschen, einfach eine 512×512 Pixel große farbige Fläche in der Akzentfarbe der Website. Alles ist besser als der leere Header oder das WordPress-Logo. Im besten Fall natürlich ein eigenes Logo.
