Update von WordPress 6.4.1 auf 6.9 samt neuem Thema und andere Nebenwirkungen
Thema: Ubuntu – MariaDB – WordPress – Apache – Theme.
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. Die Seite dient vor allem der Dokumentation zur Umstellung anderer Blogs auf unserem Server.
Letztes Update 20. Jänner 2026.
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 2026 ein Update erfahren.
Backend nach dem Update nicht aufrufbar
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.
Bei Posts kann man im Classic Editor unter WP 6.9 gewisse Änderungen nicht durchführen
Nach dem Update auf Version 6.9 gehen im Classic Editor die Funktionen/Links zum Ändern des Publikationsdatums, des Status und der Sichtbarkeit nicht. Vorschau, Versionen und Speichern geht. Dieser Fehler hängt nicht vom Thema ab. Die nicht funktionierenden Links gehen aber sehr wohl im Gutenberg Editor. Auch Versuche mit anderen Plugins (wie Disable Gutenberg) bringen keine Abhilfe.
QuickEdit geht ebenso nicht unter WP 6.9
Die Option zum schnellen Editieren von Posts geht im Backend nicht. Die selbe Funktion für Kommentare und Seiten geht aber sehr wohl.
In der Konsole erscheint folgender Fehler in der Datei inline-edit-post.min.js?ver=6.9:2:5002
Uncaught TypeError: e.wpTagsSuggest is not a functionEs handelt sich offensichtlich um einen Fehler in WP Core wo auch keine PlugIns interferieren.
Thema (Design) Kadence
Unser altes 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 Einsatz. 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 anscheinend nur in einer Bezahlversion. Der Versuch mit einem PlugIn ist geschildert. Siehe weiter unten.
- Druckbarkeit der Seiten.
Gallerie-Probleme mit Kadence
Nach wie vor ignorieren WordPress und Layout-Ersteller das Bedürfnis von Photographen Bilder folgendermassen anzuordnen: quer über die ganze Breite, darunter zwei oder drei hochkant nebeneinander sodass alle zu einander gleich weit auseinander stehen 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 Galerien sind zwar sauberer, aber man muss schon auch im CSS eingreifen. Das geht im Thema unter “Additional CSS”. Man muss die Anweisungen gezielt verschachteln.
Achtung: dies sind funktionierende Anweisungen, jedoch ohne spezieller tiefgreifender Prüfung.
Anweisungen für den Classic Editor
Der Classic Editor generiert anderen Code am Frontend beim Betrachter als der Gutenberg Editor. Folgende Anweisungen gelten nur für den Classic Editor!
Mit diesem Code werden unnötige Ränder der 2er-Gallerie entfernt:
.gallery-columns-2 .gallery-item {
padding:0em;
}
Mit dem Code hier unten werden Bilder in 3-Gallerien so wie in den 2-Gallerien angeordnet:
.gallery-columns-3 .gallery-item {
padding:0em;
}
.gallery-columns-3 img {
width:100%;
}
Es fehlt nun noch das Justieren in der Höhe bei Bildern ohne Titel. Dazu braucht es verschiedene Anweisungen, welche jeweils in den unteren Rand eingreifen. Bei den 2er- und 3er-Gallerien liegen die einzelnen Bilder in <figure> Elementen, welcher mit der ersten Anweisung der untere Rand ganz genommen wird. In der zweiten Anweisung wird dem zusammenfassenden <div> ein passender Standardabstand gegeben (0.5em), dieser Abstand besteht nach den Anweisungen oben auch horizontal zwischen den Bildern.
Die dritte Anweisung setzt das Ganze auch für Querbilder über die ganze Breite um. Diese liegen in einem einfach en <p> welches ich lieber durch das <img> darin als allgemeine Container darüber definiert. Mit der Pseudoklasse :has geht das mittlerweile ganz gut.
.gallery-columns-3 figure, .gallery-columns-2 figure {
margin-bottom:0em;
}
.gallery-columns-3, .gallery-columns-2 {
margin-bottom:0.5em
}
p:has(img.aligncenter,img.size-large) {
margin-bottom:0.5em;
}
Es bleibt noch ein Problem: Auf schmalen Bildschirmen wie Handys werden die 3er-Gallerien in 2+1 umgebrochen. Das dritte Bild liegt zwar noch immer sauber unter dem ersten darüber, aber das schaut nicht prima aus und mittlerweile werden ein grossteil der Webseiten auf Handys und kleinen Displays betrachtet. Die Ursache ist der grundsätzliche Aufbau jeder Gallery mit dem Stil display:grid. Umbrüche werden grundsätzlich mit display:inline-block verhindert, allerdings macht dies die ganze Galerie wieder kaputt.
Es gibt aber mit display:flex Abhilfe. Man ergänzt die zweite Anweisung im Block oben folgendermassen:
.gallery-columns-3, .gallery-columns-2 {
margin-bottom: 0.5em;
display:flex;
}
Dadurch werden die Bilder in der 3er-Galerie komischerweise unterschiedlich gross (zwei winzige und ein grosses) obwohl die Anordnung nach wie vor passt und auch kein Umbruch mehr stattfindet. So erzwingt man den Ausgleich, diesmal sind wir im dritten Block von oben unterwegs:
.gallery-columns-3 .gallery-item {
padding:0em;
width:33%;
}
Obwohl die 2er-Galerie am Handy nicht umgebrochen wird, schadet es trotzdem nicht diese Aufteilung auch dort einzufügen:
.gallery-columns-2 .gallery-item {
padding: 0em;
width:50%;
}
Diese Art der Aufteilung (33% und 50%) wird durch andere Anweisungen verändert, dass die Ränder zwischen den Bildern der Galerien entstehen. In diese horizontalen Abstände wurden durch die Eingriffe oben nicht eingegriffen.
Wenn man links- oder rechtsbündige Bilder in der Breite jener der 2er-Galerie will, jedoch mit Text auf der anderen Seite, dann fügt man das Bild eben links oder rechtsbündig ein.
p > img[class*="alignleft wp-image-"],p > img[class*="alignright wp-image-"] {
max-width: 50%;
}
Leider reicht dies nicht aus, und man muss sicherheitshalber auch noch mit <figure> arbeiten. Der jeweils zweite Filter (hier mit size-AeGallery2Rows), erfasst Beiträge mit Bildformaten aus dem alten Design.
figure.alignleft:has(img.size-medium), figure.alignleft:has(img.size-AeGallery2Rows){
max-width: 50%;
margin-right: 15px;
}
figure.alignright:has(img.size-medium),figure.alignright:has(img.size-AeGallery2Rows){
max-width: 50%;
margin-left: 15px;
}
Zusammenfasst schaut der eingefügte Code so aus:
.gallery-columns-2 .gallery-item {
padding: 0em;
width:50%;
}
figure.alignleft .size-medium {
width: 386px;
margin-left:0px;
}
.gallery-columns-3 .gallery-item {
padding: 0em;
width:33%;
}
.gallery-columns-3 img {
width: 100%;
}
.gallery-columns-3 figure, .gallery-columns-2 figure {
margin-bottom: 0em;
}
.gallery-columns-3, .gallery-columns-2 {
margin-bottom: 0.5em;
display:flex;
}
p:has(img.aligncenter,img.size-large) {
margin-bottom:0.5em;
}
p > img[class*="alignleft wp-image-"],p > img[class*="alignright wp-image-"] {
max-width: 50%;
}
figure.alignleft:has(img.size-medium), figure.alignleft:has(img.size-AeGallery2Rows){
max-width: 50%;
margin-right: 15px;
}
figure.alignright:has(img.size-medium),figure.alignright:has(img.size-AeGallery2Rows){
max-width: 50%;
margin-left: 15px;
}
Anweisungen für den Gutenberg Editor
Der Code welcher der Gutenberg Editor beim User ausgibt ist wesentlich komplexer als jener des Classic Editors. Es braucht dabei diese Ergänzungen zu den Zeilen oben. Achtung, dies funktioniert nur, wenn man die Bildtitel (Caption) inline im Bild hat (über unscharfen Bildhintergrund) so wie es Gutenberg vorsieht. Allerdings haben wir in diesem Bereich seit jeher Wasserzeichen im Bild, die dann ebenso unscharf erscheinen würden.
Aus diesem Grund haben wir nach nun einer Woche mit Versuchen sauber mit Gutenberg zu arbeiten wieder davon Abstand genommen. Statt dem PlugIn Classic Editor verwende ich nun Disable Gutenberg, man merkt keinen Unterschied, auch die oben genannten Fehler beim Editieren von Datrum und Status bleiben.
figure.columns-2, figure.columns-3, .wp-block-gallery, {
margin-bottom: 0.5em!important;
}
/*VERTICAL SPACE GALLERY*/
.single-content figure.wp-block-gallery{
margin-bottom: 0.5em;
}
/*VERTICAL SPACE IMAGE SINGLE*/
.single-content figure.wp-block-image {
margin-bottom: 0.5em;
}
div.wp-block-image .alignleft, div.wp-block-image .alignright{
margin-top: 0em;
}
Grösse der Bilder im Editor reduzieren
Da nun grössere Bilder im Einsatz sind, erscheinen diese auch riesig im Editor im Backend. Nach langem Herumgesuche mit der KI von Mistral.ai fand ich diese Lösung für den Classic Editor unter WP 6.9 mit dem Thema Kadence. Man schreibt sie in die Datei functions.php welches man im Backend unter dem Thema editieren kann. Vom Code her müsste dies auf mehre Designs und Versionen passen solange TinyMCE im Hintergrund läuft.
function custom_tinymce_settings($settings) {
$style = 'img { max-width: 30% !important; height: auto !important; }';
if (isset($settings['content_style'])) {
$settings['content_style'] .= ' ' . $style;
} else {
$settings['content_style'] = $style;
}
return $settings;
}
add_filter('tiny_mce_before_init', 'custom_tinymce_settings');
Passende Höhe des Editors im Backend
Mich stört seit Anbeginn, dass im Backend beim Editieren von Posts, nun mit dem Classic Editor und TinyMCe, das Editierfenster viel zu hoch ist und das Menü dadurch oben verschwindet wenn man weiter unten editiert. Die Höhe dieses <iframe> ist nicht festgelegt und wird per script mehrmals verändert. Zuerst einmal auf einen einigermassen passenden Wert (bei mir 674px bei einem Bildschirm mit 2560 x 1440 px). Dieser Wert steht auch im Browser Inspector. Dann allerdings wird er nochmal auf ca. das 5-fache erhöht. Dies macht das Scrollen echt so mühsam, besonders weil auch das Interface rechts eine Scrollbar hat. Ich habe nun lange mit Mistral.ai herumprobiert und und Scripts gesucht, die hier flexibel einwirken. Erstens ist das ausführende Script kaum zu identifizieren da es in den minimisierten JavaScript-Dateien steckt. Man kann sich mit Timern usw. helfen, aber das ist echt hatschert. Es klappte auch nicht das Script flexibel an den Bildschirm anzupassen
Ich bin nun dabei gelandet, sodass ich auch noch unten das letzte Speicherdatum sehen kann. Man fügt es unter Design > Datei Editor > functions.php ein. Achtung, die Höhe 610px ist hier fix und für grössere Bildschirme zu klein.
Dieses Script funktioniert unter WP 6.9 mit dem Kadence Design und Classic Editor. Leider aber nicht unter allen Instanzen.
function lock_tinymce_height_and_width() {
echo '<script>
jQuery(window).on("load", function() {
// Désactiver le redimensionnement automatique de TinyMCE
if (typeof tinyMCE !== "undefined") {
tinyMCE.init({
selector: "#content",
auto_resize: false,
setup: function(editor) {
editor.on("init", function() {
// Bloquer toute modification de hauteur
this.getDoc().body.style.overflowY = "scroll";
this.getWin().on("resize", function() {
jQuery("#content_ifr").css("height", "610px");
});
});
}
});
}
// Forcer la hauteur de l\'iframe sans toucher à la largeur
jQuery("#content_ifr").css({
"height": "610px",
"max-height": "610px",
"overflow-y": "auto",
"width": "100%" // Garantit que la largeur reste intacte
});
// Écraser les styles inline ajoutés par TinyMCE ou d autres scripts
jQuery("#content_ifr").attr("style", function(i, style) {
return style + "; height: 610px !important; max-height: 610px !important; overflow-y: auto !important; width: 100% !important;";
});
// Forcer le body de l iframe à ne pas dépasser
jQuery("#content_ifr").on("load", function() {
jQuery(this).contents().find("body").css({
"min-width": "100%",
"overflow-y": "scroll"
});
});
});
';
}
add_action('admin_footer', 'lock_tinymce_height_and_width');
Grosser Slider auf der Startseite
Kadence bietet in der Basisversion keinen Slider an. Es gibt aber verschiedene Plugins, die dies ebenso können. Man erhält dabei einen Shortcode zum einfügen in Interface erhält. Das Problem, der Slider sollte nur auf der Startseite sein und hier bietet weder das WP-Backend noch das Thema an, spezielle Widgets einzufügen. Es bleibt nur das hard coden im Thema und dort zum Beispiel unter (wp-content/themes/[thema]/index.html in einer Form wie dieser, hier für das PlugIn Smart Slider 3:
if (is_front_page()) {
echo '<div class="kadence-container content-area" style="max-width:1200px; margin:0 auto;">';
echo do_shortcode('[smartslider3 slider="3"]');
echo '</div>';
}
An der mehr als holprigen Beitenformatierung sieht man bereits, dass diese Lösung problematisch und jedenfalls nicht anpassungsfähig ist. Ich möchte in den zukünftigen Versionen tunlichst vermeiden im Quellcode zu editieren, da diese Änderungen bei Updates immer futsch sind und ggf. danach nicht mehr funktionieren. Der Slider muss also derzeit weichen.
Featured Image bei Postings
Es ist anscheinend Standard, dass ein Posting immer mit dem Hauptbild in gross startet. Es ist jenes welches auch in den Suchtreffern und beim Listing als Thumbnail erscheint. Dieses Einblenden das Bilds in gross macht vielleicht bei voll designten Blogs Sinn, aber bei einem Beitrag wie diesen Hier gibt es ev. nur technische Screenshots oder einen symbolischen Platzhalter wie hier die Rückseiten einer alten Photographie:
Diese sind als Teaser oben auf der Seite fehl am Platz. Man entfernt sie unter Kadence unter Appearence > Custumize > Post/Pages Layout > Single Post Layout und hier deaktiviert man Show Featured Image?.
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:
- es werden noch zwei andere Formate erzeugt wenn das Bild ursprünglich gross ist. Ich muss noch recherchieren wo dies definiert ist.
- 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.
Deleted: 300x300, 1050x1050, 820x530, 400x270, 300x220, 100x80, 794x794, 258x258, 200x200
Regenerate: 1024x1024, 150x150, 392x392, 768x768
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.
Neuer Umgang mit Bildformaten
Ich lasse nun die ergänzenden Bildformate weg und habe wie oben beschrieben die anderen grossen Formate auskommentiert und sie werden nicht mehr generiert. Die Standard-Bildformate die nun bleiben sind
Thumbnail150 x 150 pxMedium300 x 300 pxLarge1024 x 1024px
Ich verändere die Medium-Size auf 392 x 800. Dies zielt vor allem auf ab auf hochkant Bilder welche nebeneinander auf den Seiten erscheinen (siehe weiter oben). Für 2er- und für 3-Galerien wird nun nur das Format Medium eingesetzt. Aufgrund des responsiven Designs passt die Bildgrösse sowieso nie, auch wird sie durch Buffer (padding, margin) meist im Browser verringert. 2 x 392 oder eben 1 x 1024 Pixel in der Breite reicht für die meisten Designs (Themen) aus.
Umgang mit alten Beiträgen
Bilder in alten Beiträgen haben nach wie vor Sonderformate, welche noch in dieser Form am Server liegen. Löscht man diese durch Force Regenerate Thumbnails, fehlen diese und es werden nur mehr die Thumbnails angezeigt. Da wir die meisten Bilder nicht anklickbar und vergrösserbar haben, ist das besonders widersinnig.
Aber auch beim Editieren dieser alten Beiträge muss man aufpassen. Weil das Backend die Sonderformate nicht (mehr) kennt, werden Bilder Galerien mit Sonderformaten im Editiermodus als Thumbnails angezeigt. Bei den grossen Bildern im Querformat fällt dies nicht auf, sehr wohl aber bei den Galerien. Das liegt daran, dass die Bilder im Backend auf ein (nun anderes) Standardformat zurückgreifen, welches im Editiermodus nicht mehr existiert. Ändert man nun Text ohne die Bilder anzurühren, so ändert sich auch nichts am Frontend beim Betrachter. Fügt man neue Bilder ein oder ändert das Format von alten Bildern, so gibt es nur mehr die neuen Bildformate. Somit können in einem Beitrag auch unterschiedliche Formate gemischt sein. Es ist nämlich egal ob die Grundlage eines Querbilds 1024 oder 1000 Pixel ist, wenn das Layout sie alle auf 950 Pixel zwingt.
All dies ist kein Fehler von WordPress sondern ein Fehler von damaligen Designs (Thema) und auch von mir selber weil ich noch zusätzliche Bildformate generieren habe lassen.
