Wpis w bazie przeżył plik zdjęcia

Objaw

Karta produktu z pustym miejscem, ikoną zepsutego obrazka albo grafiką zastępczą tam, gdzie powinno być zdjęcie. W bibliotece mediów obrazek jest wymieniony z nazwy i wygląda jak każdy inny załącznik — jego miniatura potrafi nawet nadal się wyświetlać, z zachowanego wariantu.

Wiersz w bazie jest nienaruszony. Pliku, na który wskazuje, nie ma na serwerze.

To przychodzi prawie zawsze na jeden z czterech sposobów: migracja, która skopiowała bazę, ale nie wp-content/uploads, synchronizacja ze środowiskiem testowym puszczona w złą stronę, wtyczka odciążająca media usunięta, gdy pliki wciąż leżały zdalnie, albo dobrze pomyślane sprzątanie katalogu uploads.

Ile to kosztuje

• Produkt wygląda na zepsuty, a nie tylko na nieilustrowany. Brakujące zdjęcie czyta się jako zaniedbanie, a ocena dotyczy całego sklepu, nie jednego produktu.
• Konwertuje znacznie gorzej niż produkt ze zdjęciem — dlatego w uczciwym audycie należy do sekcji o pieniądzach, a nie do technicznego załącznika.
• Jest niewidoczne z panelu. Listy produktów pokazują tytuł załącznika, a nie to, czy plik istnieje. Nic w WordPressie tego samo nie sprawdza, nigdy.
• Kopie zapasowe potrafią to przenieść dalej. Kopia bazy przywrócona na serwer, na którym nigdy nie odtworzono uploads, daje dokładnie ten stan — od razu w skali.

Jak to sprawdzić samodzielnie

Tego akurat nie odpowie SQL, bo pytanie dotyczy systemu plików. WP-CLI potrafi zapytać obie strony naraz:

wp eval '
foreach ( get_posts([
    "post_type"      => "attachment",
    "post_mime_type" => "image",
    "posts_per_page" => -1,
    "fields"         => "ids",
]) as $id ) {
    $file = get_attached_file( $id );
    if ( $file && ! file_exists( $file ) ) {
        printf( "%d\t%s\n", $id, $file );
    }
}'

W dużej bibliotece przechodzi to przez każdy załącznik, więc uruchom poza godzinami szczytu. Jeśli nic nie wypisze, każdy obrazek, o którym WordPress wie, leży tam, gdzie WordPress się go spodziewa.

Jak naprawić

1. Ustal, czy pliki gdzieś jeszcze są, zanim ruszysz bazę. Kopia zapasowa, stary serwer, kopia testowa, zdalny bucket. Odtworzenie katalogu jest zawsze tańsze niż powtórna sesja zdjęciowa albo ponowne pozyskanie zdjęć od dostawcy.
2. Jeśli przepadły, podmień zdjęcie na produktach, które go używają, a dopiero potem usuń osierocony załącznik. Usunięcie załącznika w pierwszej kolejności zostawia produkty bez obrazka i bez informacji, co tam było.
3. Sprawdź liczbę. Dwa brakujące pliki to wypadek; dwa tysiące to migracja, która się nie dokończyła — a naprawą jest ją dokończyć, nie poprawiać produkty po jednym.
4. Po każdej migracji uruchom kontrolę ponownie. To jest najbardziej użyteczny moment na nią.

Kiedy to fałszywy alarm

• Media odciążone na zewnątrz. Jeśli Twoje obrazki mieszkają na S3, R2 albo podobnej usłudze, lokalnego pliku nie ma z założenia, a sklep serwuje je zdalnie bez problemu. To jest zdecydowanie najczęstszy fałszywy alarm tej kontroli i jeśli odciążasz media, ta kontrola nie mierzy dla Ciebie niczego sensownego — ukryj raz, zostanie ukryte.
• CDN przepisujący adresy bez przenoszenia plików zachowuje kopię lokalną, więc go to nie dotyczy.
• Załączniki, których nic nie używa. Warto posprzątać, ale są nieszkodliwe.

Jak znajduje to Merchlint

Merchlint bierze ścieżkę zapisaną dla każdego zdjęcia produktowego i pyta system plików, czy taki plik istnieje. Nic nie jest pobierane po sieci — nie idzie zapytanie ani do frontu własnego sklepu, ani nigdzie indziej — więc kontrola działa identycznie na kopii lokalnej, na środowisku testowym i na produkcji.

Przy znalezisku widać identyfikator załącznika, zapisaną ścieżkę i produkty, które go używają.

Pewność: F — fakt z bazy i z systemu plików. Ścieżka wskazuje na plik albo nie.

Ponieważ jeden obrazek może należeć do wielu produktów, znalezisko zgłasza załącznik. Poprawienie go raz poprawia każdy produkt, który go używał.