В настоящее время я выполняю миграцию содержимого сайта со старого сайта до 4.1 на новую настройку и решаю проблему с ошибкой округления # 18532 и соответствующим исправлением .
Подводя итог, можно сказать, что исправлено давнее поведение при округлении на стороне WordPress:
Представьте, что мы загружаем изображение размером 693х173 и масштабируем его до ширины 300:
- до 4.1: 300х74
- пост 4.1: 300х75
Проблема
Как правило, это не вызывает никаких проблем, потому что существующие файлы <img>
не затрагиваются.
Но когда вы регенерируете большие пальцы или импортируете вложения из файла WXR, они генерируются по-разному в файловой системе, оставляя все <img>
в post_content
живых.
Ищем решение
Я думал о различных решениях:
Возвращаясь к плохим старым временам
Changeset 30660 представил новый фильтр, wp_constrain_dimensions
который можно использовать, чтобы просто подключить старое поведение, предшествующее 4.1, обратно. Это решает проблему. Но мне интересно, может ли это вызвать проблемы позже, и, как правило, я бы хотел исправить это, поэтому, хотя это работает, я бы посчитал его неидеальным.
Времена, когда они меняются
Таким образом, это ставит нас перед другой целью: очистить БД и заменить все ссылки на старые файлы ссылками на новые файлы. Вопрос, который я сейчас задаю, заключается в том, как это сделать. Я ищу эффективное и общеприменимое решение, так как подозреваю, что эта проблема затрагивает многих людей.
Моя текущая идея заключается в следующем:
- Импортируйте, регенерируйте или что угодно, что оставляет нас с новыми файлами и битыми тегами.
- Создайте список A из всех файлов с измененным размером в файловой системе или, альтернативно, получите эту информацию из базы данных.
- Проанализируйте этот список и создайте второй список B с именами файлов, смещенными на один пиксель, как это было бы до 4.1
- Выполните поиск и замените всю базу данных, заменив все вхождения B соответствующей записью в A
Я просто не уверен, что это самый умный и эффективный способ справиться с этой ситуацией. Он также чувствует себя слишком грубо. Поэтому, прежде чем приступить к реализации, я просто хотел проверить бесконечную мудрость толпы WPSE;)
[править] Прочитав ответ ck-macleod (спасибо!), я думаю, что исправление должно решить это раз и навсегда, поэтому вам не нужно постоянно держать эту проблему в затылке. [/редактировать]
[edit2] Я только что нашел связанный билет на Trac . Добавление для справки. [/ edit2]
error issue of #13852
ввиду#18532
? :)Ответы:
Это другой подход, отличный от другого ответа, который работает при импорте контента с помощью импортера и исправляет URL-адреса раз и навсегда. Опять же: это не проверено в бою, но это решение, на котором я остановился, и оно сработало.
Я предпочитаю это, поскольку это решает проблему раз и навсегда, и если это работает, это работает. Так как вы не оставляете испорченные вещи в БД и исправляете их на дисплее, вам не нужно беспокоиться о том, что что-то сломается позже.
источник
Решение проблемы глобально и идеально для ВСЕХ файлов изображений (и ссылок) на большом сайте - учитывая, например, возможность, что люди могут иногда переименовывать файлы изображений вручную, имитируя стиль WP - и другие странные варианты - может быть затруднительно. Операции по поиску и замене в базе данных также связаны с осложнениями (и рисками!).
Могли бы вы справиться с подавляющим большинством ошибок - неработающими изображениями и неработающими ссылками на изображения, я полагаю, - и достичь желаемого конечного результата или приемлемого факсимильного сообщения следующим способом?
Определите дату, до которой все изображения с измененным размером были изменены с помощью старого метода «intval», а не нового «круглого» метода. (Можно также создать другой вид отсечения, но дата кажется более простой.)
Для всех опубликованных сообщений <= дата завершения, запустите preg_replace для the_content () во время загрузки / рендеринга, захватив все файлы изображений с проблемным шаблоном или шаблонами и заменив их требуемым шаблоном. База данных останется неизменной, но вывод будет безошибочным в большинстве случаев. Я не уверен, что решение должно будет применяться как к «единственному» содержимому публикации страниц, так и к архивированию страниц и других процессов.
Если бы решение такого типа было бы полезным, то следующий вопрос состоял бы в том, могут ли модели проблемы и замены быть адекватно определены. Из вашего списка предлагаемых решений видно, что, возможно, несколько типичных шаблонов могут быть фактически изолированы (возможно, взяты из предыдущих настроек мультимедиа, создающих миниатюры и некоторые другие изображения).
Я уже написал более простую функцию, которую я использую (и нахожусь в процессе превращения в плагин), которая глобально заменяет все файлы изображений в назначенных каталогах, до определенной даты, изображением по умолчанию или ссылкой на изображение, согласно вышеописанному способу. Это было для сайта, где, из-за чрезмерной осторожности с авторскими правами, операторы просто удалили все свои изображения, не подозревая, что, помимо получения ужасных результатов на старых страницах, они также выдают тысячи ошибок, по две на каждую образ.
Если вы можете сузить образец проблемы более конкретно, и случаи, когда выходные данные должны были бы быть изменены, тогда я мог бы видеть о подключении его к моему формату - который не очень сложен, и который для лучшего RegExer, чем я мог бы даже быть легким. С другой стороны, я не хотел бы тратить ваше или мое время, если этот подход не решит проблему для вас.
источник
wp_constrain_dimensions
как упоминалось в вопросе, при выполнении импорта и воздержаться от восстановления превью было бы чище.Хорошо, это базовый подход к замене сломанных изображений на лету. Имейте в виду, что это скорее подтверждение концепции, чем проверенное в бою решение. Он просто подключает
the_content
фильтр, который может (возможно, имеет) некоторые нежелательные побочные эффекты в некоторых ситуациях. Обращаться осторожно. :)Хотя в коде тоже так сказано, я также хочу отметить @Rarst за этот ответ, использованный в моем коде.
источник