die Korrektur – WP Smush.it und der Fehler „Konnte nicht gefunden werden“ im WordPress Media Manager

Das hat mich für eine Weile verrückt gemacht. Alle meine neuesten Bilder in WordPress konnten von WP Smush it „zerquetscht“ werden, aber alles vor 2009 hatte eine Massenfehlermeldung. Wenn Sie hier sind, haben Sie sie wahrscheinlich schon gesehen, aber nur um sicherzugehen, dass wir alle auf der gleichen Seite sind, hier ist, wie sie aussehen könnte:

WP Smush It kann Datei nicht finden

 

Im Wesentlichen heißt es dort: Konnte /home/yaddayadda/public_html/etc nicht finden. Und in diesem Fall, wenn Sie sich den Ort ansehen, fließt er tatsächlich zweimal durch – Sie sehen den doppelten Schrägstrich // nach den ersten „uploads“ und er beginnt wieder von vorne. Ich hatte ein wenig nach einer schnellen Lösung gesucht, aber kein Glück gehabt, also war es Zeit, mit dem Graben anzufangen!

 

Die Ursache (für mich jedenfalls)

Normalerweise werden die Speicherorte der Bilder mit ihrem relativen Pfad in der WordPress-Datenbank gespeichert. Dies bedeutet so etwas wie 2006/04/image.png. Wenn es an der Zeit ist, das Bild zu finden, schaut WordPress auf Ihr Setup, um zu sehen, wo Ihre Bilder gespeichert sind (normalerweise i ), und beginnt, alles zusammenzusetzen, um den endgültigen vollständigen Pfad zu erhalten. Das ist großartig, weil es die Dinge portabler macht.

Leider wurden damals, als ich die WordPress-Website 2006 erstellte, aus welchem Grund auch immer, die von mir hochgeladenen Bilder mit ihrem absoluten Pfad in der Datenbank gespeichert. Für diejenigen, die den Fachjargon nicht kennen, bedeutet absolut in diesem Fall so etwas wie /home/server_account/public_html/i/2006/04/image.png. Wie Sie vielleicht vermuten, kann dies ein Problem verursachen, wenn Sie jemals Ihren Upload-Ordner (oder die WordPress-Installation) an einen anderen Ort auf dem Server (oder auf einen anderen Server mit einem anderen Kontonamen) verschieben. Als ich 2008 auf einen anderen Host umgezogen bin, muss ich offensichtlich eine Änderung vorgenommen haben, die die Verwendung eines relativen Pfades korrigiert hat, weshalb alles, was seit 2009 hochgeladen wurde, für mich erdrückend gut war.

Jedenfalls, während WordPress selbst mit einem absoluten Pfad überleben kann (solange er korrekt ist), stellt der absolute Pfad für WP Smush.it ein Problem dar. Soweit ich das beurteilen kann, wird es den Speicherort Ihres Upload-Ordners vor dem Pfad auf jeden Fall blockieren. Wenn Ihre Bilder also mit einem absoluten Pfad in der Datenbank gespeichert wurden, geraten Sie am Ende ein wenig in die Zwickmühle.

 

Ok, genug gejammert. Wie reparieren?!

Nur zur Vorwarnung: Ein Teil dieses Prozesses beinhaltet die manuelle Bearbeitung Ihrer WordPress-Datenbank. Wenn Sie sich dabei nicht wohl fühlen, sollten Sie vielleicht weitersuchen und hoffen, dass jemand eine elegantere Lösung gefunden hat. Und selbst wenn Sie sich dabei wohlfühlen, ***** sichern Sie zuerst*****, nur für den Fall!!!

Nun werde ich hier eine Vermutung äußern – erinnern Sie sich daran, dass ich sagte, dass meine letzten Bilder gut funktionierten (sie wurden ordentlich zerquetscht). Ich gehe davon aus, dass dasselbe auch für Sie gilt und dass, wenn Sie jetzt ein neues Bild hochladen würden, dieses problemlos gelöscht werden würde. Wenn das *nicht* der Fall ist, sollten Sie sich zuerst mit diesem Problem befassen.

Schritt 1 (nach der Datensicherung) – Bearbeiten der Datenbank

A) der sicherere (aber längere) Weg – manuelle Bearbeitung

Ich habe phpMyAdmin verwendet, aber es gibt wahrscheinlich einige WordPress-Datenbank-Plugins, die Sie verwenden können, wenn Sie keinen Zugang zu phpMyAdmin haben.

1) Öffnen Sie Ihre WordPress-Datenbank und wählen Sie die „wp_postmeta„-Tabelle
2) Suchen Sie die „_wp_attached_file„-Einträge, bei denen Sie ein Problem beim Löschen haben, und klicken Sie auf „Bearbeiten(Edit)„. (Machen Sie sich nicht die Mühe, die „_wp_attachment_metadata„-Einträge zu editieren – Änderungen dort vorzunehmen, funktioniert nicht, und so werden wir WordPress dazu bringen, sie später neu zu generieren).

Klicken Sie auf das Bild unten für eine größere Ansicht

wp-smushit-could-not-find-02-database

Beachten Sie, dass der „meta_value“ der ersten 2 (mit „GOOD“ bezeichnet) 2006/03/sitemaps1.gif ist, was ein relativer Pfad ist. Auf der anderen Seite haben diejenigen, die mit „BAD“ bezeichnet sind, einen Pfad, der mit /home/ beginnt, was ein absoluter Pfad ist, den wir nicht wollen.

TIPP: Wenn Sie sich das Bild angesehen haben, haben Sie wahrscheinlich bemerkt… das ist ein ziemliches Durcheinander. Eine Sache, die hilfreich sein kann, ist es, einen anderen Browser (oder Tab) mit Ihrer WordPress-Medienbibliothek geöffnet zu haben und nach der ID der URL zu suchen, wenn Sie mit der Maus über jedes der problematischen Bilder fahren (solange Ihr Browser die Statusleiste am unteren Rand anzeigt, sollten Sie sie dort sehen). Sie können auch mit der Maus über die Schaltfläche „Re-smush“ fahren – es wird dieselbe ID-Nummer angezeigt. Vergleichen Sie diese mit der Nummer in der Spalte „post_id“ in der Datenbanktabelle, um die Bilder mit dem Datenbankeintrag abzugleichen.

3) Sobald Sie sich auf der Bearbeitungsseite befinden, trimmen Sie den Speicherort/Pfad der Datei herunter. Klicken Sie auf die Bilder unten für ein Vorher und Nachher.

Bearbeiten der Tabelle - VORHER Bearbeiten der Tabelle - NACH

Wenn Sie WordPress so eingerichtet haben, dass Bild-Uploads nach Jahr und Monat organisiert werden, stehen die Chancen gut, dass Ihr Endergebnis identisch mit dem zweiten Bild aussieht, wobei alles bis einschließlich der i gelöscht wird und der Rest übrig bleibt.
Denken Sie daran, dass Sie keinen führenden Schrägstrich wünschen.

4) Sobald Sie auf „Go“ klicken, sollten Sie die Tabelle erneut ansehen. Und der Eintrag, den Sie gerade bearbeitet haben, sollte korrekt aussehen.

TIPP: Bevor Sie den nächsten (und den nächsten, und den nächsten) bearbeiten, sollten Sie wahrscheinlich mit dem nächsten Schritt weiter unten fortfahren, nur um sicherzustellen, dass nichts durcheinander kommt. Außerdem wäre es schade, hundert davon zu editieren, nur um herauszufinden, dass Ihr Zeug aus irgendeinem Grund am Ende immer noch nicht vernichtet ist. Kümmern Sie sich vorerst nur um dieses eine Bild, bis Sie wissen, dass alles A-OK ist.

B) der schnelle und gefährliche Weg

Anstatt all diese Zeilen manuell zu editieren, können Sie, wenn Sie Zugriff auf phpMyAdmin haben und keine Lust haben, Dutzende von Zeilen manuell zu editieren (möglicherweise Hunderte von Zeilen, je nachdem, wie viele Bilder Sie haben), eine MySQL-Abfrage durchführen, um ein großes Suchen & Ersetzen durchzuführen.

Beachten Sie, dass ich Ihnen dringend empfehle, mindestens 1 Zeile zuerst manuell zu editieren – wenn nichts anderes dabei herauskommt, wird es Ihnen ein Verständnis dafür geben, was Sie tun. Oh, und wenn Sie es aus irgendeinem Grund noch nicht getan haben, vergewissern Sie sich doppelt, dass Sie ein Backup erstellt haben. Eine schiefgegangene SQL-Abfrage kann Ihre Website im Handumdrehen zerstören.

 

Die Vorrunde: 

Wenn Sie sich an unsere obige manuelle Methode erinnern, ändern wir im Wesentlichen Dinge wie

/home/username/public_html/i/2006/08/image.jpg

zu:

2006/08/image.jpg

Dieser /home/username/public_html/i/ wird grundsätzlich immer wieder gelöscht, einmal für jedes Bild. Anstatt es manuell zu tun, können wir MySQL, um etwas Zeit zu sparen, anweisen, einfach die gesamte wp_postmeta-Tabelle zu durchlaufen und jede Instanz von /home/username/public_html/i/ zu löschen, die er findet. Das ist ein wenig gefährlich, denn wenn WordPress oder ein anderes Plugin aus irgendeinem Grund diese Zeile für etwas anderes dort ablegt und sie dort…. braucht, dann ist sie weg. Ich habe einen kurzen Blick darauf geworfen und nichts bemerkt, was problematisch sein sollte, aber nach allem, was ich weiß, haben sie vielleicht in der nächsten Version von WordPress etwas Neues dort, das dies zerstören wird. Habe ich schon erwähnt, dass Sie sich erst einmal absichern sollten?

Lassen Sie uns anfangen.

1) Folgen Sie bis zu diesem Punkt den obigen „Handbuch“-Anweisungen:

Kopieren Sie diese Zeile in die Zwischenablage

 

Sie werden sehen, dass ich die Anweisungen leicht modifiziert habe. Sie werden dies auswählen und mit CTRL-C, oder CMD-C auf dem Mac, in die Zwischenablage kopieren. Oder klicken Sie mit der rechten Maustaste auf Kopieren. Oder…. Nun, sagen wir einfach, wenn Sie nicht einmal wissen, wie man kopiert, bin ich sehr schockiert (und doch extrem beeindruckt), dass Sie sich beim Bearbeiten einer Datenbank wohlfühlen.

Nun fügen Sie diese Zeile irgendwo in ein Textdokument ein. Wir müssen damit beginnen, die SQL-Abfrage zusammenzustellen.

Das Format, das wir verwenden werden, lautet wie folgt:

UPDATE `table_name` SET `field_name` = replace(same_field_name, 'unwanted_text', 'wanted_text')

Es ist vielleicht am besten, die gesamte Zeile einfach in eine Textdatei zu kopieren, anstatt sie abzutippen. Es gibt 2 verschiedene Arten von Anführungszeichen, die in der obigen Zeile ` ‚ verwendet werden, und es ist leicht, versehentlich das falsche zu verwenden. Wir müssen diese farbigen Elemente in die richtigen Werte ändern, also werden wir sie folgendermaßen ändern.

table_name is going to be wp_postmeta (if you have a prefix other than „wp_„, make sure you use your prefix instead)
field_name is going to be meta_value (you can see in the above image that was the name of the field we were editing)
same_field_name is going to be meta_value also
unwanted_text is the line we copied with CTRL-C before
wanted_text will be deleted, leaving just the 2 single-quotes.

table_name wird wp_postmeta sein (wenn Sie ein anderes Präfix als „wp_“ haben, stellen Sie sicher, dass Sie stattdessen Ihr Präfix verwenden)
field_name wird zu meta_value (Sie können im obigen Bild sehen, dass dies der Name des Feldes war, das wir bearbeitet haben)
same_field_name wird auch meta_value sein
unwanted_text ist die Zeile, die wir zuvor mit CTRL-C kopiert haben
wanted_text wird gelöscht, so dass nur die 2 einfachen Anführungszeichen übrig bleiben.

Fahren Sie fort und nehmen Sie diese Änderungen jetzt vor. Mit den Änderungen an Ort und Stelle sollten Sie jetzt etwas haben, das dies *ähnlich* macht:

UPDATE `wp_postmeta` SET `meta_value` = replace(meta_value, '/home/username/public_html/i/', '')

Die Chancen stehen gut, dass bei einer Standard-Installation Ihre bis auf die grüne Linie identisch aussieht (es sei denn, Ihr Webhost hat Ihnen buchstäblich „username“ als Benutzernamen gegeben und es ist Ihnen gelungen, genau das gleiche Pfadproblem wie mir zu haben). Denken Sie daran, dass Sie die Zeile verwenden, mit der Sie ein CTRL-C gemacht haben.

Nun also, um sie einzufügen:

1) Wenn Ihre Datenbank ausgewählt ist, wählen Sie oben die Registerkarte SQL.
2) Fügen Sie Ihre „UPDATE“-Zeile ein (wenn es einen Standardtext gibt, kopieren Sie ihn einfach darüber)
3) Drücken Sie „Los“.

phpMyAdmin-Datenbank-Abfrage

 

Wenn Sie erfolgreich sind, gelangen Sie auf eine nächste Seite, auf der Ihnen die # Anzahl der Zeilen angezeigt wird, die geändert wurden. Vielleicht möchten Sie die Tabelle wp_postmeta durchsuchen und einen kurzen Blick darauf werfen, um sicherzugehen, dass die Änderung korrekt durchgeführt wurde. Wenn stattdessen etwas ziemlich Schreckliches passiert ist (oder etwas wirklich schwer zu beheben ist… wie z.B. wenn Sie einen Schrägstrich übersehen und „upload“ statt „upload/“ gelöscht haben), stellen Sie sicher, dass Sie die gesicherte Datenbank bereit haben und stellen Sie sie wieder her.

Schritt 2 – Raus aus dem Datenbank-Editor und hinein in ein Plugin.

Leider reicht es nicht aus, nur die Datenbank zu bearbeiten. Wir brauchen WordPress, um die Metadaten der Anhänge neu zu generieren (im Grunde die Zeilen in der Datenbanktabelle, die wir nicht bearbeitet haben).

Der einfachste Weg, den ich gefunden habe, dies zu tun, ist über ein Plugin namens „Regenerate Thumbnails„. Um ehrlich zu sein, tut es mehr, als wir benötigen, aber ich hatte Probleme, ein Plugin zu finden, dessen einzige Aufgabe darin bestand, die Metadaten neu zu generieren. Hier ist der Grund, warum es für uns gut funktioniert:

1) Es lässt sich einfach installieren (Sie können es aus WordPress heraus installieren) und es gibt keine Konfiguration, die man durcheinander bringen muss.
2) Wenn Sie nur Miniaturansichten (und Metadaten) für bestimmte Bilder neu generieren möchten, können Sie das tun, und es ist einfach.
3) Wenn Sie Miniaturansichten (und Metadaten) für alles neu generieren möchten, können Sie das auch tun, und es ist einfach.

Natürlich gibt es ein paar mögliche Nachteile… das Plugin wird die Miniaturansichten auf der Grundlage der aktuellen Werte in Einstellungen/Medien neu erstellen (für Miniaturansicht, klein, mittel und groß). Wenn Sie die Einstellungen für die Bildgröße in der Vergangenheit einige Male geändert haben, benutzen Sie einfach Ihre Vorstellungskraft, und Sie können das Potential für einige unbeabsichtigte Konsequenzen erkennen. Auch wenn eine große Anzahl Ihrer Bilder nicht gelöscht werden konnte und Sie planen, dieses Plugin zu benutzen, um *alle* Bilder auf einmal zu regenerieren, könnte Ihre Serverlast in die Höhe schnellen, bis sie vollständig ist. Möglicherweise sollten Sie dies früh morgens tun, um die Auswirkungen auf den Web-Verkehr zu minimieren. Seien Sie sehr vorsichtig, wenn Sie dieses Plugin auf einem gemeinsam genutzten Server verwenden, besonders wenn Sie Tausende von Bildern haben.

Sie sollten vielleicht ein Bild nach dem anderen regenerieren, um auf der sicheren Seite zu sein. Denken Sie daran, dass es wahrscheinlich eine Reihe anderer Plugins gibt, die funktionieren würden, wenn Sie etwas anderes bevorzugen würden – Regenerate Thumbnails war einfach das erste, das mir begegnet ist, das aussah, als würde es meine Bedürfnisse erfüllen.

Ich empfehle Ihnen dringend, Ihre Bilder zu sichern, bevor Sie fortfahren, nur für den Fall, dass… Sie können ein vollständiges Website-Backup einfach über cPanel erstellen, wenn Ihr Host es benutzt. Andernfalls targen oder zippen Sie zumindest den Inhalt Ihres Upload-Ordners.

Ok, also vorausgesetzt, Sie haben es installiert und das Plugin aktiviert, hier sind die nächsten Schritte:

Miniaturansicht regenerieren und erneut löschen

1) Öffnen Sie die Medienbibliothek, suchen Sie das von Ihnen bearbeitete Bild in der Datenbank, und klicken Sie auf Miniaturansichten neu generieren.

2) Angenommen, es wird ohne Fehler abgeschlossen (es sollte funktionieren, wenn die Bearbeitung der Datenbank gut verlief), drücken Sie Re-Smush.

Die unangenehme Meldung *konnte nicht finden* (could not find) sollte nun verschwinden, und……

 

Aaaund….. VOILA!

wp-smushit-could-not-find-06-fixed

 

Wenn Ihr Einzelbildversuch funktioniert hat, gehen Sie zurück zu Teil 1 und beginnen Sie, die Bilder zu durchstöbern (überprüfen Sie Ihre Beiträge regelmäßig, um sicherzustellen, dass die Bilder immer noch angezeigt werden, ohne dass es zu unerwünschten Nebenwirkungen kommt).

Dinge einpacken

Ok, das war eine Menge Arbeit. Aber hoffentlich können am Ende alle Ihre Bilder leicht zerquetscht werden. Werfen Sie einen Blick auf einige Ihrer Beiträge, um sicherzugehen, dass alles noch so aussieht, wie es sollte, und halten Sie diese Backups bereit, für den Fall, dass Sie ein paar Tage später auf ein Problem stoßen.

Wenn Sie den Prozess durchlaufen haben und irgendwelche Tipps oder Geschichten zu erzählen haben (hoffentlich gute Erfolgsgeschichten, aber auch Horrorgeschichten werden es tun), können Sie dies gerne im Kommentarbereich unten tun!

 

2 Anmerkungen | Sagen Sie einen Kommentar

  1. Ausgezeichneter Artikel Matt. Tolle Lektüre und ein großartiger Rundgang. Ich hatte genau das gleiche Problem auf meiner Website durch einen ähnlichen Prozess. Ich wollte das Schritt für Schritt aufschreiben, aber nicht nötig. Ich werde einfach darauf hinweisen, was du hier gemacht hast.

    Thnx schon wieder!

    -S
  2. Sehr nette bildliche Repräsentation.
    :D

Sagen Sie einen Kommentar

Sie können einen Alias und gefälschte E-Mails verwenden Wenn Sie sich jedoch für die Verwendung einer echten E-Mail entscheiden, werden "Gravatare" unterstützt. Lesen Sie die Datenschutzerklärung für weitere Details.