Zahllose Kopien von Bildern in jahrelang genutzen WordPress-Instanzen reduzieren

Du betreibst seit über 10 Jahren einen WordPress-Blog, hast schon mehrere Designs (Layouts) im Einsatz habt und vielleicht setzt du auch grundsätzlich viele Bilder ein. Das Mass ist irgendetwas über 10000 Bilder. Unter ungünstigen Umständen können dadurch über 30gb Daten am Server unter dem Ordner /wp-content/uploads/ entstehen. Das sind, gemessen an den 10000 Bildern und dass unsere Seiten eigentlich nur für das Web und für kleinere Geräte ausgerichtet sind, viel zu viel an Daten.

Grundlage:

• WordPress 7.x
• Linux-Server mit root-Zugriff
• Classic Editor
• “Händisches” Eingreifen in die Beiträge
• “Händisches” Eingreifen in die Medien unter /wp-content/uploads/
• PlugIns
• WP-CLI
• MariaDB und root-Zugriff

Die letzten drei Eingriffsmöglichkeiten sind überlappend redundant: WP-CLI ersetzt viele PlugIns und ist auch mächtiger als diese. Mit WP-CLI kann man auch in die Datenbank eingreifen, aber SQL-Anweisungen sind mächtiger.

Letztes Update: 29. September 2026.

Mehrfach Duplizierung aller Bilder

WordPress alleine

Wie kommen diese Unmengen an Daten zustande? WordPress alleine macht schon sechs Versionen von jedem Bild. Aber nur drei davon sind unter Einstellungen > Medien einstellbar. Drei davon werden automatisch generiert und ggf. auch im Backend bei adaptiven Medien (siehe weiter unten), ungefragt ausgeliefert.

1. Vorschaubilder (thumbnail)
2. Mittelgroß (medium)
3. medium_large: oft ungefragt im Einsatz im Backend
4. Gross (large)
5. 1536x1536 ist für grosse Displays gedacht
6. 2048x2048 ist für grosse Displays gedacht

Neben diesen 6 liegt natürlich auch das Originalbild am Server, welches ebenso ungefragt ausgespielt werden kann. Es liegt also schon mal viel herum und das wird durchaus auch grossformatig in die Webseite eingebunden. Plattenplatz und Datendurchsatz explodieren.

Durch Designs generierte Bilder

Aber so als ob dem nicht genug sei, generien auch Designs Bilder für ihre Zwecke. Das ist meist für Features wie Sliders oder verschiede Thubnailgrössen. Hier unten ein Beisipel des Designs Cleanblogg (welches wir eine Zeit lang einsetzten, das aber nicht mehr unterstützt wird). Man sollte sich von dem Begriff “thumb” unten nicht irritieren lassen, das sind schon auch grosse, datenintensive Bilder.

1. cleanblogg-mini-thumb, 100x80pxCrop, im Widget Post on Tab
2. cleanblogg-grid-thumb, 400x270pxCrop, Tabellen-Vorschau
3. cleanblogg-list-thumb, 300x220pxCrop, Listen-Vorschau
4. cleanblogg-full-thumb, 1050x0pxCrop, Slider-Bild-Standard

Selber generiere Bilder

Man will ja unter Umständen selber eingreifen um Photos passend und schön zu platzieren. Das ging vor 10 Jahren noch schlechter, also war das legitim. So korrigierte ich das Design Cleanblogg folgendermassen:

1. sliderLarge, 1200x0px, ersetzt cleanblogg-full-thumb
2. landscape, 794x0px, Querbild
3. zweiAx, 392x0px, für zwei Bilder nebeneinander
4. dreiAx, 258x0px, für drei Bilder nebeneinander
5. leftOrRightSmall, 200x0px, zum links- oder rechtsbündig Einbinden

Wir sind jetzt, wenn man zusammenzählt, bei 15 generierten Bildern plus das Original!

Wasserzeichen-Plugins

Wir verwenden auch Wasserzeichen, konkret Copyright-Hinweise meist rechts unten. Es sind im den Sinne keine halbtransparenten Wasserzeichen. Unabhängig von den gestalterischen Problemen mit diesen sind sie auch datenintensiv. Da man auch das Original mit einem Wasserzeichen versehen kann, wird von diesem Original eine 1:1-Kopie angelegt (in mindestens einem Unterordner von /wp-content/uploads/).

Ausgangslage

Damit sind wir bei 17 Versionen pro Bild. Bei 10000 Bilder macht das 170000 Bilder. So sind dann langsam 30gb möglich. Nun ist es so, dass wenn man Design wechselt und zum Beispiel eines einsetzt, welches keine zusätzlichen Bilder generiert, Bilder des alten Designs einfach am Server bleiben. Die zusätzlich generierten Bilder gelten immer nur für das gewählte Design und die im Einsatz befindlichen Plugins. Deswegen ist der Wechsel von Designs auch so kompliziert. Es gibt zwar helfende Plugins wie Regenerate Thumbnails, die arbeiten sauber mit den Bildern, sie sanieren aber nicht die einzelnen Referenzierungen in die Beiträgen.

Wir werden, bei einigen Insatzen nach 15 Jahren, versuchen hier etwas aufzuräumen. Die Sache läuft nur halbautomatisch, mit starker Betonung auf “halb”.

Neue Bildgrössen

Unter Einstelungen > Medien kann man zwei Hauptgrössen von Bildern neben der kleinen 200x200px-Vorschau einstellen. Standarmässig ist die kleine zu klein und die grosse zu gross. Es geht um Mittelgross (medium) und Gross (large). Das Ziel ist es möglichst brauchbare grössen für das Layout zu haben, das sind im unseren Fall 400px breit für hochkant (portait) für 2er- und 3-Galerien und 900px breit für quer (landscape) und das Header-Bild. Um die jeweils andere Seite nicht beschneiden zu lassen, setzt man 0 ein.

Warum 400px und 900px?

Wir verwendeten das Design Cleanblogg und nun Kadence. Beide bieten die Möglichkeit Bilder in 2er- und 3er-Galerien sowie vollbreite Bilder untereinander bündig anzuorden. Natürlich braucht es dazu auch ein bisschen CSS-Ergänzung, aber grundsätzlich geht es. Bei Kadence ist der Content-Bereich etwa 900px breit. Bilder darin werden dann ohnehin kleiner eingenblendet, der Browser scaliert sie unabhängig vom Code in der Seite herunter. Das ist nicht nobel und nicht im Sinne des W3C, aber jahrelanger Usus. Wir wollen es nicht so weit treiben WordPress zu zwingen Bilder strikt 1:1 auszuspielen.

Die Bilder haben in einer Standardseite am PC nun folgende eingeblendete Breiten:

• 864px Header
• 780px large
• 386px für ein Bild in einer 2er-Galerie
• 254px für ein Bild in einer 3er-Galerie

Um die Menge an Bildern nicht wieder sinnlos zu vergrössen werden diese zu je zwei Grössen zusammengefasst und zwar so, dass die grosse Grösse breiter als die zwei grossen Formate ist und die kleine kleiner als das kleinste der grossen Formate. So vermeidet man, dass nicht grosse Formate in die Galerien gespielt werden.

• 900px grösser als 864px und 780px
• 400px kleiner als 864px und 780px aber auch grösser als 386px und 254px

Generieren von unnötigen Formaten unterbinden

Man sollte auch unnötige Bildgrössen entfernen, so spart man Platz am Server. Das geht unter Design/Thema-Datei-Editor/functions.php. Dort diese Anweisung unten hinzufügen. Man kann das nicht anders machen, weil die Angaben im Code an vielen verschiedenen Stellen stehen. Einige Plugins erkennen diese Formate als gültig an, aber sie werden nicht mehr generiert sobald dies eingefügt ist. Achtung, beim Update des Designs können diese eingefügten Funktionen wieder weg sein, man muss sie also ggf. nachträglich wieder einfügen. Am Besten fügt man den Code ganz unten ein und markiert diese Blöcke mit einem Kommentar am Anfang und am Ende (// KOMMENTAR….)

function remove_default_image_sizes( $sizes ) {
  unset( $sizes['medium_large'] );
  unset( $sizes['1536x1536'] );
  unset( $sizes['2048x2048'] );
  return $sizes;
}
add_filter( 'intermediate_image_sizes_advanced', 'remove_default_image_sizes' );

Mit diesen Änderungen bleiben vier Bildgrössen am Server, sofern man nun ein Design verwendet, welches keine eigenen Bilder genieriert und man auch nicht selber noch dementsprechende Anweisungen im Code hat. Dies gilt nur für neu hochgelade Bilder ab dem Zeitpunkt der Änderung!

1. IMG_6391-200x200.jpg ist für echte Thumbnails
2. IMG_6391-400x533.jpg für Galerien
3. IMG_6391-900x600.jpg für Bilder quer
4. IMG_6391.jpg ist das Original

Verkleinerte Bilder neu generieren

Wir zeigen unten einen zeitlichen Ablauf der nötigen Änderungen, es befinden sich darin aber auch immer Alternativ-Vorschläge.

Einzeln in der Mediathek

Das Plugin Regenerate Thumbnails ermöglich das genieren neuer Bilder nach den gültigen Einstellungen unter Einstellungen > Medien. Dieses Plugin zeigt auch die versteckten Formate medium_large, 1536x1536 und 2048x2048 an, aber diese werden wegen der Anweisung weiter oben nicht mehr generiert.

Man kann es generell für alle Datein lancieren, davon raten wir aber dringend ab! Am Besten macht man es je Blogeintrag weil man diese danach auch einzeln sanieren muss.

Man landet anschliessen mit Anwenden im Interface des Plugins.

Mit dem zweiten Hackerl werden auch alle alten Bilder gelöscht, das ist genau was wir wollen. Die angebene Warunung ist korrekt, viele Bilder werden anschliessend in besagten Blogbeitrag fehlen.

Es werden beim Regenerieren die originalen Bilder herangezogen, das sind jene am Server ohne Formatangaben im Dateinamen, also zb. IMG_6204.jpg und nicht IMG_6204-400x270.jpg.

Das Regenerieren dauert durchaus, je nachdem wieviele Bilder man ausgewählt hat und je nachdem wie gross die Originaldateien sind.

Nach dem Ende des Prozess, nicht wieder auf Medien klicken sondern im Browser zurück gehen damit die ausgewählten Bilder für den nächsten Schritt erhalten bleiben.

Mit WP-CLI

WP-CLI ist ein Programm, das auf Linux-Servern ausgeführt werden kann. Die Syntax ist wp [befehl] --parameter. Wenn man mit Daten arbeitet, welche dem User www-data gehören (wie das Bilder generell sind), muss man als root arbeiten, dann braucht es immer den zusätzlichen Parameter --allow-root.

Zum Installieren führt man dies hier aus:

# curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
# chmod +x wp-cli.phar
# sudo mv wp-cli.phar /usr/local/bin/wp

Der Befehl wp sucht beim Ausführen im aktuellen Verzeichnis nach der Datei wp-config.php. Dies ist ein Kontextmechanismus: jede WordPress-Instanz wird automatisch über ihre wp-config.php-Datei (und dessen Unterverzeichnis wp-content/) erkannt. Daher wirkt sich die Ausführung des Befehls nur auf die aktuelle Verzeichnisstruktur aus. Der verwendete Befehl lautet wp media regenerate. Man kann ihn generell für alle Bilder anwenden oder für einzelne mit der passenden ID:

Für alle:

wp media regenerate --yes --allow-root

einzelne nach ID:

wp media regenerate 25571 25570 25573 25572 25574 --yes --allow-root

Dieser Befehl arbeitet alle Medien von den neuesten zu den alten durch bei 10000 Bildern kann man gut 20 Minuten am Weg sein. Es werden Bilder nach den Angaben unter Einstellungen > Medien sowie weiterer ggf. unter Design/Thema-Datei-Editor/functions.php erzeugt und andere alte Formate gelöscht. Letztes passiert nur wenn das Bild in der Datenbank vermerkt ist. Bilder die “frei” herumliegen werden nicht entfernt. Zusätzlich stellt der Befehl regenerate die volle Datenstruktur je Bild in der Datenbank wieder her, also Daten zum Originalbild samt Name und Grösse in Pixel, sowie zu verkleinerten Ableitungen wieder mit Name und Grösse in Pixel.

Hauptbilder verkleinern

Man kann zentral die hochladebare Dateigrösse (MB) in php.ini festlegen, aber das sagt nichts über die grösse in Pixel aus. Nach mehreren Jahren auf verschiedenen Servern, kann dieser Wert auch varieren. Daher können auch sehr grosse Orignalbilder am Server liegen. Das braucht viel Plattenplatz und diese Bilder sind ohne speziellen serverseitigen Einstellungen frei zum Herunterladen. Mit dem Plugin Resize Image After Upload kann man das zwar das Hochladen nicht unterbinden, die Bilder werden aber sogleich reduziert. Wir haben 1200x1200px gewählt. Dieses Plugin arbeitet von sich aus vor anderen wie das Setzten von Wasserzeichen.

Mit Image Magick kann man jedenfalls ordnerweit Bilder im Nachhinen verkleineren. Rekursiv geht das nur per Shell-Script. Die Wildcards, die man einsetzen kann, sind die selben wie bei Suchen mittels ls, das ist eine stark abgespeckte RegEx-Anweisung.

mogrify -resize 1200x1200 *[a-z].jpg

Mit der Methode wird das Bild hart verändert. Aber die Grösse des urspunglichen Bilds bleibt in der WordPress-Datenbank erhalten. Das ist zwar nicht hinderlich, aber auf Dauer sehr inkonsistent. Der oben genannte Befehl wp media regenerate schreibt aber auch die Metadaten des Hauptbilds neu.

WordPress-Verkleinerungen mit “scaled”

WordPress verkleinert unabhängig von allen Plugins grosse Bilder die das Ausmass 2560x2560px überschreiten. Vom grossen Ursprungsbild bild.jpg, das erhalten bleibt, wird eine Datei namens bild-scaled.jpg erstellt. Dummerweise heissen die normalen Verkleinerungen davon bild-900x600.jpg und nicht bild-scaled-900x600.jpg.

Wenn man nun aber, wie zuvor beschrieben, mittels wp media regenerate Bilder neu generiert hat, so lauten die neuen Verkleinerungen sehr wohl bild-scaled-900x600.jpg. Als Resultat hat man dann alle Verkleinerungen doppelt und natürlich auch noch das überhaupt zu grosse Bild herumliegen.

Nun gibt es zwei Möglichkeiten: die Dateien mit scaled im Namen zu lassen und nur die zu grosse ursprüngliche Datei bild.jpg zu löschen oder alle *scaled* zu löschen und die Einträge in der Datenbank danach flicken. Ich habe dazu keine passende einfache Lösung gefunden, hier meine Arbeitsschritte je Medienordner.

Ursprungsdatei Löschen undscaled im Namen der Datei belassen

Keine gute Lösung, da der Name der Ursprungsdatei auch in der WP-Datenbank tief begraben liegt.

Dateinamen mit scaled löschen und Verkleinerungen neu generieren

Der einigermassen saubere Weg, der aber sehr langwierig ist.

1. Die generelle Verkleinerung mit mogrify über alle Dateien ist schon erfolgt.
2. Löschen je betroffene Dateie mit scaled im Namen: rm bild-scaled*, das löscht auch die Verkleinerungen und lässt nur mehr die Ausgangsdatei übrig.
3. Je betroffener Datei wp search-replace 'bild-scaled.jpg' 'bild.jog' --regex --allow-root ausführen.
4. In der Mediathek nach dem Bild suchen um die [media-id] zu erfahren.
5. Je betroffener Datei wp media regenerate [media-id] --yes --allow-root ausführen.
6. Je betroffener Datei Wasserzeichen neu setzen. Falls dies nicht klappt, zuerst mit update wp_postmeta set meta_value = 0 where meta_key = 'iw-is-watermarked'; Wasserzeichen-DB löschen.
7. Den Beitrag mit dem Betroffenen Bild editieren und prüfen, ob das Bild gändert und vorhanden ist. Ggf. auf den Browser-Cache achten.

Nur alle Bilder verkleinern und es dabei belassen

1. Mit mogrify -resize 1200x1200 *.jpg.

Wasserzeichen anbringen

Nun  müssen wir die Wasserzeichen neu überlagern, sie sind ja weg weil aus dem Originalbild die neuen Bilder generiert wurden. Wir verwenden das PlugIn Image Watermark, es ist nicht perfekt, aber stabil und gratis. Dies geht wiederum unter dem Menü in Medien, hier mit den  ausgewählten Bildern Apply Watermark ausführen. Man bleibt dabei auf der Medien-Seite, es wird jedes Bild nacheinander abgearbeitet. Der Prozess dauert, weil ja alle Verkleinerungen mit Wasserzeichen versehen werden.

Achtung, dies geht nach dem Ändern der Bilder wie oben nur für danach neu hochgeladene Bilder. Der Grund: auch das das PlugIn “merkt” sich Bildinformationen und wenn diese nicht mehr mit jenen aus der Mediathek zusammenpassen, werden alle Informationen zu Verkleinerungen aus der DB gelöscht. Dadurch liefert Worpress immer nur das Hauptbild aus! Es passiert auch, wenn die Kopie unter iw-backup/ fehlt oder wenn diese Kopie jünger als das Originalbild ist. Man kann das wieder mit wp testen:

wp post meta get [MEDIA-ID] _wp_attachment_metadata --allow-root

Dies liefert einen Array, der folgendermassen ausschauen sollte. Wenn die Liste sizes fehlt, dann fehlen die Verkleinerungen in der Datenbank und man muss wieder wp media regenerate [MEDIA-ID] --yes --allow-root drüberlaufen lassen.

array (
  'width' => 800,
  'height' => 1200,
  'file' => '2022/04/20220315-143437_6935_7D.jpg',
  'filesize' => 252448,
  'sizes' =>
    array (
    'medium' =>
     array (
       'file' => '20220315-143437_6935_7D-400x600.jpg',
       'width' => 400,
       'height' => 600,
       'mime-type' => 'image/jpeg',
       'filesize' => 66280,
     ),
     'thumbnail' =>
     array (
       'file' => '20220315-143437_6935_7D-200x200.jpg',
       'width' => 200,
       'height' => 200,
       'mime-type' => 'image/jpeg',
       'filesize' => 14185,
     ),
   ),
'image_meta' =>
  array (
   'aperture' => '8',

  ....

Das Plugin Image Watermark macht unter Umständen nicht 100% opake Wasserzeichen. Bei mir hängt der Wert auf maximal 76% obwohl das PNG richtig formatiert ist. Dies kann mehrere Ursachen haben wie eine dumme Kombibationen aus alter PHP-Version, unpassender GD-Version (Linux-Basisprogramm zum Bearbeiten von Bildern) und JavaScript-Konflikte zwischen den WordPress-Plugins. All dies kann das PlugIn Image Watermark blockieren. Dann kann man in der darunterliegenden Datenbank direkt eingreifen, dies sollte auch via wp db query gehen. Hier unten jedenfalls die DB-Anweisungen. Die Informationen liegen in einem Array mit Längenkontrolle und diese müssen sauber gesucht/ersetzt werden.

UPDATE wp_options SET option_value = REPLACE(option_value, 's:11:"transparent";i:50;', 's:11:"transparent";i:100;') WHERE option_name = 'image_watermark_options';

Man kann so auch andere bockige Einstellungen hart setzen. Im Interface sind sie nachher nicht mehr rückgängig zu machen (?).

UPDATE wp_options SET option_value = REPLACE(option_value, 's:19:"manual_watermarking";b:0;', 's:19:"manual_watermarking";b:1;') WHERE option_name = 'image_watermark_options';

Image Watermark legt Kopien der Originaldatei unter /wp-content/uploads/iw-backup/ ab, dies mit der selben Ordnerstruktur wie unter /wp-content/uploads/. Der Grund: das Plugin ermöglicht auch die Originaldatei mit Wasserzeichen zu versehen. So hat das Plugin unter Medien auch die Option Remove watermark. Das macht durchaus Sinn, man muss sich aber der Verdopplung der Originaldateien am Server bewusst sein. Man kann dies aber auch unter Einstellungen abstellen.

Eine Methode diese Daten für Image Watermark wieder herzustellen ist den Inhalt von iw-backup/ zuerst zu löschen:

wp-content/uploads/# rm -r iw-backup/

Dann duplizieren wir alle Bild-Ordner. Diese fangen bei uns alle mit 20* an:

cp -R 20*/ iw-backup/

Nun liegen aber auch die Verkleinerungen sinnlos unter iw-backup/ herum. Sie zu löschen ist nicht ganz trivial, aber es geht, indem man nach den Formatangaben in den Dateinamen sucht:

find . -maxdepth 3 -regextype posix-extended -regex ".*-[0-9]+x[0-9]+\.jpg" -delete

Nun kann man mit Image Watermark seitenweise die Wasserzeichen anbringen. Man kann unter Ansicht anpassen die Anzahl der Medien pro Seite verändern. Es macht auch Sinn zu prüfen ob immer die passende Anzahl der Bilder mit Wasserzeichen versehen wurden. Diese Nummer erscheint unten in grün. Fehler werden oben in rot herausgeschrieben. Leider fehlt die Angabe, um welche Datei es sich handelt. Wenn rote Fehler erscheinen, können die Metadaten des Bilds zerschossen werden (siehe weiter oben).

Man kann nun den Inhalt von iw-backup/ löschen und rund 2/5 des Plattenplatzes der Bilder wieder einsparen. Das PlugIn Image Watermark wird für neue Bilder wieder Kopien dort anlegen und auch Wasserzeichen setzen. Will man bei alten Bildern Wasserzeichen ändern, muss man besagte Bilder (oder dessen Ordner) wieder dorthin kopieren und anschliessend wieder entfernen.

Nun kann das PlugIn noch immer meckern. Es hilft es gännlich zu deinstallieren, die restlichen (!) Einträge in der DB zu löschen und das PlugIn wieder zu installieren. Zum Löschen der Daten geht man folgendermassen vor:

delete from wp_options where option_name LIKE '%watermark%'; # Löscht drei Einträge
update wp_postmeta set meta_value = 0 where meta_key = 'iw-is-watermarked'; # Löscht u.U. so viele Einträge wie Bilder

Händische Eingriffe im Blogbeitrag

Anschliessend in den besagten Blogbeitrag gehen, denn nun müssen die Bilder teilweise neu verknüft werden. Das ist der Grund, warum wir nicht pauschal alle Bilder für den ganzen Blog neu generiert haben. Unten eine Ansicht aus dem Backend, einmal visuell und einmal als Code. Hier sehen wir viel zu grosse Bilder in einer 2er-Galerie und ein fehlendes Einzelbild. Manche Bilder sind real da, mache nur vermeintlich weil auch der Browsercache wirkt. Ggf. die Seite neu laden (strg+R). Wir müssen dazu sagen, das wir nach wie vor den Classic Editor verweden, der macht es etwas komplizierter, aber mit Gutenberg ist es auch nicht perfekt.

Die Bilder erscheinen falsch oder gar nicht, weil wir nun andere Bilder generiert hatten. Die nötigen Änderungen können varieren, das hängt vom Design und von der Vorgeschichte des Blogs ab. Bei uns erscheinen die Galerien weil das Bild von Typ large tatsächlich existiert. Auch wenn hier etwas anderes steht, z.B. eine altes privates Format welches nicht mehr existiert, dann wird automatisch auf large im Backend und im Frontend gesprungen.

Oben im Screeshot sind das

gallery link="none" columns="2" size="large" ids="23048,23050"
gallery link="none" columns="2" size="large" ids="23058,23061"

Galerien lassen sich einfach adapieren indem man in der der Code-Ansicht  alle size="large", oder was auch immer dort steht, duch size="medium" ersetzt. Das geht ggf. besser wenn man die Code-Ansicht in einen brauchbaren Texteditor kopiert und am Ende wieder zurückkopiert.

Einzelbilder (breit) sind schwieriger weil sowohl der Dateiname als auch die Attribute width und height geändert werden müssen. Man kennt zwar die Breite dieser Bilder, da sie der Breite der grossen Bilder unter Einstellungen > Medien entspricht, man kennt aber nicht immer die Höhe. Man kann sie nicht von den vorliegenden Werten berechnen, das es bei vollen Pixel zu Rundungsfehlern kommt. Man kann daher nur diese Dateien einzeln im Backend anwählen und das Format gross auswählen. Es ist dabei egal ob ein Bild zuvor noch sichtbar war oder nur ein leerer Platzhalter da war. Das Bild war sowieso weg nachdem man Vorschaubilder regenerieren angeworfen hat.

Man kann in der Code-Ansicht unter Umständen folgendes Suchen/Ersetzen machen, wenn man sicher ist, dass alle Bilder das selbe 40/30- oder 45/30-Verhältnis haben. Bei mir war die Ausgangslage für ein Bildformat z.B.:

-794x529.jpg" alt="" width="794" height="529" />

und ich kann es en bloc durch:

-900x600.jpg" alt="" width="900" height="600" />

ersetzen. Es bleiben dann unter Umständen einige Dateien mit abweichenden Höhen übrig, die man händisch ändern muss. In der Regel unter “visuell” das Bild anwählen, meist erscheint es dann schon und gross auswählen.

Mit WP-CLI kann man auch Suchen/Ersetzen incl. RegEx in der Datenbank ausführen. Dazu muss man natürlich genau wissen was man macht. Ich habe in einem Blog Bilder die so aussehen, man sieht schon die falschen Formate:

<img class="size-AeFullWidth wp-image-34638" src="https://www.voyage-hors-saison.fr/wp-content/uploads/2023/01/20220831-161801_carte_du_kystriksveien-794x596.jpg" alt="" width="794" height="596" />

welche aber so aussehen sollten:

<img class="size-large wp-image-34638" src="https://www.voyage-hors-saison.fr/wp-content/uploads/2023/01/20220831-161801_carte_du_kystriksveien-900x675.jpg" alt="" width="900" height="675" />

Mittels Suchen/Ersetzen kann man das global in der Datenbank machen. Weil ich einen eindeutigen Kenner AeFullWidth habe, brauche ich nicht speziell aufpassen. Zu “merkende” Zeichenketten werden in () gesetzt, ersetzt werden sie mit \1, \2, etc. (statt $1, $2, etc. wie unter regulären Ausdrücken üblich).

wp search-replace '<img class="size-AeFullWidth (.*)-794x596.jpg" alt="(.*)" width="794" height="596" />' '<img class="size-large \1-900x675.jpg" alt="\2" width="900" height="675" />' --regex

Andere Änderungen

Damit all dies Sinn macht, muss man auch unterbinden, dass adaptiver Inhalt ausgeliefert wird wo pro Bild alle Versionen dem Browser übergeben werden. Da dieser aber durch schlechtes Design-Layout nicht die Gesamtbreite der Seite kennt, lädt der er immer die grössten Dateien, also die Originaldatei. Wenn man den adaptiven Content unterbindet, wird die Bildgrösse ausgliefert, die im Backend angegeben wurde, in dem Fall unsere Grössen 400px Breite für hochkant und 900px Breite für quer. Und eben nur diese.

add_filter( 'big_image_size_threshold', '__return_false' );

Auf diese Art und Weise wird auch die Grösse der Wasserzeichen einheitlicher weil nicht mehr riesige Bilder in kleine Rahmen reduziert werden.

Mit folgendem Code unter  Design/Thema-Datei-Editor/functions.php bewerkstelligt man ähnliches:

// Man sucht die Bilder mit bekannten Formatgrössen wie size-medium, size-large)
if (preg_match_all('/<img[^>]+class="[^"]*size-([^"\s]+)[^"]*"[^>]+src="([^"]+)"/i', $content, $matches, PREG_SET_ORDER)) {
  foreach ($matches as $match) {
    $taille_choisie = $match[1]; // 'medium', 'large', etc.
    $url_actuelle = $match[2];
    // Wenn die URL aber das Orignalbild anzeigt (kein -400x533 im Dateinamen)
    if (!preg_match('/-\d+x\d+\.(jpg|jpeg|png|webp|gif)$/i', $url_actuelle)) {
      $attachment_id = attachment_url_to_postid($url_actuelle);
      if ($attachment_id) {
        // Wir zwingen zum Auspielen des im Backend angebenen Formats
      $image_exacte = wp_get_attachment_image_src($attachment_id, $taille_choisie);
        if ($image_exacte) {
          $content = str_replace($url_actuelle, $image_exacte[0], $content);
        }
      }
    }
  }
}
return $content;
}
add_filter('the_content', 'corriger_url_image_frontend_classique', 999);