Obecnie jestem w trakcie migracji zawartości witryny ze starej witryny w wersji wcześniejszej niż 4.1 do nowej konfiguracji i trafiam na problem z błędem zaokrąglenia # 18532 i odpowiednią poprawką .
Podsumowując, naprawiono długotrwałe złe zaokrąglanie po stronie WordPressa:
Wyobraźmy sobie, że przesyłamy obraz o wymiarach 693 x 173 i skalujemy do szerokości 300:
- przed 4.1: 300 x 74
- post 4.1: 300 x 75
Problem
Zasadniczo nie powoduje to żadnych problemów, ponieważ istniejące pliki <img>
nie są dotykane.
Ale kiedy regenerujący kciuki lub importowanie załączników z pliku WXR dostają różnie generowane w systemie plików pozostawiając wszystko <img>
w post_content
martwy.
Poszukuję rozwiązania
Myślałem o różnych rozwiązaniach:
Wracając do złych, starych czasów
Changeset 30660 wprowadził nowy filtr, wp_constrain_dimensions
którego można użyć do podłączenia starego zachowania sprzed wersji 4.1. To rozwiązuje problem. Ale zastanawiam się, czy może to spowodować później problemy i ogólnie chciałbym to naprawić, więc chociaż działa, uważam, że nie jest idealny.
Czasy się zmieniają'
Pozostaje nam zatem kolejny cel: oczyścić bazę danych i zastąpić wszystkie odniesienia do starych plików odniesieniami do nowych plików. Pytanie, które tutaj zadaję, brzmi: jak to zrobić. Szukam skutecznego i ogólnie stosowalnego rozwiązania, ponieważ podejrzewam, że ten problem dotyczy i wpłynie na wiele osób
Mój obecny pomysł jest następujący:
- Importuj, regeneruj lub cokolwiek, co pozostawia nam nowe pliki i uszkodzone tagi.
- Utwórz listę A ze wszystkich plików o zmienionym rozmiarze w systemie plików lub uzyskaj te informacje z bazy danych
- Przeanalizuj tę listę i utwórz drugą listę B z nazwami plików przesuniętymi o jeden piksel, tak jak wyglądałby przed 4.1
- Wykonaj wyszukiwanie i zamień w całej bazie danych, zastępując wszystkie wystąpienia B odpowiednim wpisem w A
Po prostu nie jestem pewien, czy jest to najinteligentniejszy i najskuteczniejszy sposób poradzenia sobie z tą sytuacją. Czuje się też trochę zbyt brutalnie. Przed wdrożeniem chciałem tylko sprawdzić z nieskończoną mądrością tłumu WPSE;)
[edytuj] Po przeczytaniu odpowiedzi ck-macleod (dzięki!) Myślę, że poprawka powinna rozwiązać to raz na zawsze, więc nie musisz ciągle trzymać tego problemu z tyłu głowy. [/edytować]
[edit2] Właśnie znalazłem powiązany bilet na Trac . Dodawanie w celach informacyjnych. [/ edit2]
error issue of #13852
na myśli#18532
? :)Odpowiedzi:
Jest to inne podejście niż inna odpowiedź, która działa podczas importowania treści za pomocą importera i naprawia adresy URL raz na zawsze. Znowu: To nie jest testowany w bitwie, ale rozwiązanie, na którym się zdecydowałem i zadziałało.
Wolę to, ponieważ rozwiązuje problem raz na zawsze, a jeśli działa, działa. Ponieważ nie zostawiasz uszkodzonych elementów w bazie danych i nie naprawiasz ich na ekranie, nie musisz martwić się późniejszym uszkodzeniem elementów.
źródło
Rozwiązanie problemu globalnie i doskonale dla WSZYSTKICH plików obrazów (i linków) w dużej witrynie - biorąc pod uwagę, na przykład, możliwość, że niektóre osoby czasami zmieniają nazwy plików obrazów ręcznie imitując styl WP - i inne dziwne odmiany - może być trudne. Operacje wyszukiwania i zamiany bazy danych pociągają za sobą również komplikacje (i ryzyko!).
Czy potrafisz poradzić sobie z ogromną większością błędów - zepsutymi obrazami i zepsutymi linkami do obrazów - i osiągnąć pożądany efekt końcowy lub rozsądny faks za pomocą następującej metody?
Określ datę, przed którą wszystkie obrazy o zmienionym rozmiarze zostały przeskalowane przy użyciu starej metody „intval” zamiast nowej metody „okrągłej”. (Można również stworzyć inny rodzaj granicy, ale data wydaje się najłatwiejsza).
Dla wszystkich opublikowanych postów <= data graniczna, uruchom preg_replace na the_content () w czasie ładowania / renderowania, przechwytując wszystkie pliki obrazów z problematycznym wzorem lub wzorami i zastępując je pożądanym wzorem. Baza danych pozostanie niezmieniona, ale w większości przypadków dane wyjściowe będą wolne od błędów. Nie jestem pewien, czy rozwiązanie musiałoby dotyczyć zarówno „pojedynczej” zawartości postów stron, jak i archiwizować strony i inne procesy.
Jeśli rozwiązanie tego typu byłoby pomocne, następnym pytaniem byłoby, czy wzorce problemów i zamienniki mogłyby być odpowiednio zdefiniowane. Z listy proponowanych rozwiązań wynika, że prawdopodobnie można wyodrębnić kilka typowych wzorców (być może zaczerpniętych z wcześniejszych ustawień multimediów tworzących miniatury i inne obrazy).
Napisałem już prostszą funkcję, której używam (i jestem w trakcie przekształcania się we wtyczkę), która globalnie zastępuje wszystkie pliki obrazów w wyznaczonych katalogach, do określonej daty, domyślnym obrazem lub linkiem do obrazu, zgodnie z wyżej opisaną metodą. Była to witryna, w której operatorzy usunęli wszystkie swoje zdjęcia w nadmiarze ostrzeżeń dotyczących praw autorskich, nieświadomi, że oprócz brzydkich wyników na starych stronach, zgłaszali również tysiące błędów, po dwa dla każdego wizerunek.
Jeśli możesz zawęzić bardziej szczegółowo wzorzec problemu, a przypadki, w których wynik musiałby zostać zmieniony, mógłbym zobaczyć o podłączeniu go do mojego formatu - co nie jest bardzo skomplikowane i które dla lepszego RegExer niż mógłbym nawet być łatwym. Z drugiej strony nie chciałbym marnować twojego czasu, jeśli takie podejście nie rozwiązałoby problemu.
źródło
wp_constrain_dimensions
jak wspomniano w pytaniu podczas importowania i powstrzymanie się od odbudowywania kciuków, byłoby czystsze.Ok, to jest podstawowe podejście do zastępowania uszkodzonych obrazów w locie. Pamiętaj, że jest to bardziej dowód koncepcji niż rozwiązanie sprawdzone w walce. Po prostu włącza
the_content
filtr, który może (prawdopodobnie ma) pewne niepożądane skutki uboczne w niektórych sytuacjach. Ostrożnie. :)Chociaż tak też napisano w kodzie, chcę również podziękować @Rarst za tę odpowiedź użytą w moim kodzie.
źródło