Update von WordPress 6.4.1 auf 6.9 samt neuem Thema und andere Nebenwirkungen

Thema: Ubuntu – MariaDB – WordPress – Apache – Theme.

---

Letztes Upadate 16. Jänner 2026.

Nach einem selbst verursachten Stillstand des Servers (Log-Partition voll), kam ich wieder dazu Versionen von WordPress, dem Layout und Plattennutzung zu prüfen. An allen drei Stellen gibt es Handlungsbedarf.

Update von WordPress 6.4.1 auf 6.9

Dieser Schritt war dann doch mühsamer als gedacht. Zuerst musste PHP auf eine Version über 8.0 gebracht werden. Dies war nötig weil die darunterliegende Ubuntu-Version schon alt ist. Dieser Teil wird voraussichtlich im Sommer ein Update erfahren.

Weil wir mit SSH-Keys arbeiten und auch sonst recht strikte Dateirechte pflegen, können wir keine automatischen Updates durchlaufen lassen. Es muss also dieser Anleitung gefolgt werden. Das geht soweit recht gut, jedoch entsteht ein Fehler wenn man vor dem Austausch der Dateien nicht ausloggt. Das äussere Zeichen ist, dass der Blog funktioniert, aber man nicht auf die Verwaltungsebene kommt. Es liegt nicht am Browser-Cache. In den Apache-Logs steht dann folgendes:

[Fri Jan 16 11:34:15.248583 2026] [php:error] [pid 458003] [client [IP]] PHP Fatal error: Cannot redeclare wp_admin_headers() (previously declared in [PATH]/wp-includes/functions.php:7168) in [PATH]/wp-admin/includes/misc.php on line 1416, referer: https://andre.carto.net/wp-login.php

Das Problem liegt in der Datei misc.php. Die Nebenfrage ist wie man überhaupt eine Datei mit diesem Namen in einer “sauberen” Programmierung brauchen kann? Dort steht ab Zeile 1416 folgendes relaod(). Dieses muss man zuerst auskommentieren (//).

function wp_page_reload_on_back_button_js() {
?>
  <script>
    if ( typeof performance !== 'undefined' && performance.navigation && performance.navigation.type === 2 ) {
    //  document.location.reload( true );
    }
  </script>
<?php
}

Dann kann man Einloggen und es folgt das automatische Update der Datenbank nach dem Versionsupdate. Zuletzt entfernt man wieder die // unter misc.php. Anschliessend läuft alles normal.

Thema (Design) Kadence

Das Thema Cleanblogg erfährt kein Update mehr und die Firma dahinter gibt es auch nicht mehr. Zusätzlich besteht dabei das Problem mit den vielen Bildversionen welche dadurch generiert werden. Das ist also keine Dauerlösung. Ich habe, etwas faul, die KI befragt, welches Thema am ehesten wie Cleanblogg konfigurierbar ist, also mit Vignetten auf der Startseite, relativ einfache Seiten und verwendbar mit dem Classic Editor. Die Antwort war OceanWP, Astra und Kadence.

• OceanWP kann ich nun  mit der neuen WP-Version testen, es ist aber zu schlicht und das Interface zur Gestaltung ist recht mühsam.
• Astra würde entsprechen, wenn es für die Vignetten auf der Startseite nicht starr verzerren würde. Ich fand keine schelle Lösung dies zu umgehen ohne alle Bilder neu beschneiden zu müssen.
• Kadence habe ich derzeit im Test. Die Vignetten schauen sauber aus, das Gitter ist je nach Browserbreite 3-, 2- oder 1-spaltig. Es werden nur die Bilder in den Formaten generiert wie es WordPress standardmässig macht und der Classic Editor geht ebenso. Eine Sidebar mit Login-Widgets, Themenliste, Schlagwortliste udgl. geht ebenso, sie wird direkt aus WP übernommen. Die Plugins zum Einfügen von Werbeblöcken funktionieren auch. Zu testen bleibt:
  • Footer-Content, sollte über Widgets gehen.
  • Gosser Bilder-Slider auf der Startseite, der geht anscheindend nur in einer Bezahlversion.
  • Druckbarkeit der Seiten.

Gallerie-Probleme

Nach wie vor ignorieren WordPress und Layout-Ersteller das Bedürfnis von Photographen Bilder folgendermassen anzuornen: quer über die ganze breite, darunter zwei oder drei hochkant nebeneinander sodass alle zu einander gleich weit auseindanderstehen und besonders die kleineren (hochkant) auch so weit an den Rand gehen wie die breiten. Mit dem Thema Cleanblogg klappte das nur nach vielen herumeditieren im Quellcode. Aussehen soll es so:

Aber auch mit Kadence geht das nicht von alleine. Die Gallerien sind zwar sauberer, aber man muss schon auch im CSS eingreifen. Das geht unter “Additional CSS”. Man muss die Anweisungen gezielt Verschachteln und forcieren.

Mit diesem Code werden unnötige Ränder der 2er-Gallerie entfernt:

.gallery-columns-2 .gallery-item {
   padding: 0em!important; //.5em;//
}

Mit folgendem Code wird ein einzelnes linksbündiges Bild passend unter ein linkes Bild in einer 2er-Gallerie platziert. Es wird dabei konkret auf die Breite angepasst, die auch dem einzelnen Bild in der 2er-Gallerie bleibt (386px).

figure.alignleft .size-medium {
   width: 386px!important;
   margin-left:0px!important;
}

Mit dem Code hier unten werden Bilder in 3-Gallerien so wie in den 2-Gallerien angeordnet:

.gallery-columns-3 .gallery-item {
   padding: 0em!important; //.5em;//
}

.gallery-columns-3 img {
   width: 100% !important;
}

Es fehlt nun noch das Justieren in der Höhe bei Bildern ohne Titel.

Plattennutzung durch zu viele Medien-Versionen

Die Plattennutzung ist vor allem durch Photos explodiert. Am Server ist es kein Problem, aber es macht Backups mühsam. Bilder werden original abgespeichert und von WordPress automatisch in den Formaten Thumbnail, Medium und Large. Diese entsprachen bei dem vorigen Layout Cleanblogg nicht den Bedürfnissen und es legt noch mal ungefragt zwei Versionen des Bilds an. Weil mir die Formate der Bildgalerien nicht passen, habe ich auch hier mehrere neue Formate definiert. Da ich auch Wasserzeichen verwende, wird auch hier das original bewahrt. Sprich: es gibt dann je Bild bis zu 15 Versionen. Statt nur einem Bild mit ca. 1mb liegen 3.5mb herum. Wenn man diese Formate ändert, kann man grundsätzlich neue Bilder generieren lassen, aber die alten werden nie gelöscht, egal ob man sie braucht oder nicht. Hier muss jedenfalls noch aufgeräumt werden.

Bilder von Grund auf neu generieren

Es gibt zwar das das Plugin Force Regenerate Thumbnails, welches alle Bilder bis auf das original löscht und anschliessend nur jene unter Settings erzeugen sollte, aber es gibt zwei Probleme:

1. es werden noch zwei andere Formate erzeugt wenn das Bild ursprünglich gross ist. Ich muss noch recherchieren wo dies definiert ist.
2. natürlich erfolgt das Löschen und Regenerieren ohne Rücksicht auf das in den Posts verlinkten Bilder. Diese können ja nach anderen Formaten generiert worden sein wie die neuen und diese Format steht hart im Dateinamen welcher auch hart verlinkt ist (m.e. ist das ein Programmdesignfehler). Solch ein Plugin sollte zusätzlich auch prüfen welche Bilder wie wo verlinkt sind. Das würde sich natürlich auf die Ausführzeit des Plugins niederschlagen.

In der WP-Version 6.9 steht in der Datei /wp-includes/media.php ab Zeile 5694 folgende Funktion. Sie wird nur unter /wp-includes/default-filters.php auf Zeile 672 aufgerufen. Sie generiert Bildgrössen, auf welche nur Plugins für Slider und dergleichen zugreifen können. Dummerweise greift auch Force Regenerate Thumbnails dieses Formate auf. Wenn man diese auskommentiert, erscheinen auch zwei weitere Formate nicht.

function _wp_add_additional_image_sizes() {
  // 2x medium_large size.
  // add_image_size( '1536x1536', 1536, 1536 );
  // 2x large size.
  // add_image_size( '2048x2048', 2048, 2048 );
}

Unter /wp-admin/includes/schema.php steht auf Zeile 532 die Zahl 768 für eine Bildbreite die ebenso zusätzlich generiert wird.

// 4.4.0 
'medium_large_size_w'             => 768, 
'medium_large_size_h'             => 0,

Es bringt allerdings nicht diese Formate hier auszukommentieren, da sie in der Datenbank eingetragen sind. Das Format dient vor allem responsivem Design. Es ist wohl zu umständlich dieses Dateien zu entfernen und dafür zu sorgen, dass sie nicht mehr erzeugt werden.

Durch diese Änderung statt ca. 15 Versionen pro Bild auf nur mehr 5, wobei das Originalbild hier auch mitzählt. Dieses sollte man generell nicht übergross hochladen. Statt 3.5mb, kommt man so auf unter 1mb pro Bild.