Избегайте суффиксов размера изображений WordPress в именах файлов

«Безопасно ли использовать шаблон суффикса размера изображения WordPress в именах файлов изображений?»

Вы когда-нибудь задавали себе этот вопрос? Я думаю, нет. С несколькими годами опыта разработки WordPress за моей спиной вопрос до меня тоже не поднимался до недавнего времени. Когда я полировал старый код, я столкнулся с этой относительно редкой, но более интересной проблемой. Давайте углубимся более детально.

При загрузке изображений или манипулировании ими программным способом, например, с помощью плагина Regenerate Thumbnails, WordPress создает пару альтернатив разного размера из исходного изображения, известных как миниатюры.

В результате когда мы загружаем файл с именем «image.jpg», в дополнение к исходному изображению мы получим несколько файлов, таких как image-150×150.jpg или image-300×550.jpg. Количество миниатюр и их размеры зависят от ваших настроек, установленных плагинов и вашей темы.image-{width}x{height}``-{width}x{height}

Но что произойдет, если исходное имя файла содержит шаблон размера изображения, и у нас уже есть сгенерированный файл с тем же именем? Должны ли мы слепо доверять WordPress, чтобы справиться с этим правильно? Посмотрим. Может показаться ненужным иметь дело с именами файлов, но мы вряд ли будем проверять имена изображений одно за другим при загрузке. Возможно иметь такие суффиксы в именах файлов фотографий или контента, случайно взятых из поиска картинок Google. Поэтому полезно знать, что происходит в таких случаях.

Давайте перейдем к делу

Чтобы узнать правду как можно быстрее, давайте проведем простой тест. Нам нужны два разных изображения: « cat.jpg » и « cat-150×150.jpg » и зарегистрированный размер изображения с шириной и высотой 150 пикселей. (Это размер миниатюр по умолчанию в WordPress).

Сначала загрузите файл «cat.jpg», а затем файл «cat-150×150.jpg». Не удивительно: мы можем видеть как изображения в библиотеке мультимедиа, так и соответствующие им изменения размера в папке загрузки. WordPress проделал большую работу, переименовав исходный файл «cat-150×150.jpg» в «cat-150×150-1.jpg», чтобы избежать конфликтов имен.

Теперь давайте повторим процесс в обратном порядке. Сначала загрузите файл «cat-150×150.jpg», а затем файл «cat.jpg». Закончив, мы видим, что что- то пошло не так. Есть два одинаковых изображения в библиотеке мультимедиа. Однако в папке выгрузки есть только один файл «cat-150×150.jpg». Автоматически измененная версия «cat.jpg» (cat-150×150.jpg) перезаписала наш оригинальный файл «cat-150×150.jpg». На этот раз WordPress не переименовал загруженный файл. Один из наших загруженных файлов отсутствует, и наша база данных стала несовместимой.

Кроме того, если мы удалим изображение «cat.jpg» из библиотеки мультимедиа, файл «cat-150×150.jpg» также будет удален из папки загрузки, оставив поврежденное изображение в библиотеке мультимедиа.

Почему это происходит?

WordPress использует функцию во время загрузки. Это гарантирует, что загруженные файлы имеют санированные и уникальные имена для данного каталога, чтобы предотвратить перезапись наших текущих файлов. Однако эта функция сравнивает только исходное имя файла с существующим в выбранной папке. Он не имеет дело с потенциально сгенерированными миниатюрами – он не видит будущего. Вот почему файл с шаблоном суффикса размера изображения в WordPress может быть легко перезаписан автоматически сгенерированным файлом .wp_unique_filename()

Как избежать размера изображения в оригинальном имени файла?

Изучение имен файлов вручную перед загрузкой не имеет смысла. Как разработчики WordPress, мы можем создать функцию для изменения имени загружаемого файла на лету, чтобы предотвратить такие конфликты. Подключите нашу функцию к sanitize_file_nameфильтру, который вызывается в начале функции. С одной стороны, это хорошо, так как санитарная обработка – это первый шаг при создании безопасных и уникальных имен файлов. Обеззараженное имя используется для проверки уникальности имени файла.wp_unique_filename()

С другой стороны, мы должны быть осторожны, поскольку наша функция выполняется после основного процесса очистки. Это делает WordPress неспособным помочь, сохраняя вещи в чистоте. Наша задача – не использовать никаких специальных символов.

Вот наш маленький фрагмент кода, который делает эту работу. Вы можете вставить его в файл functions.php (дочерней) темы:

/**
 * Modify the WordPress image size suffix pattern
 * in the uploaded jpg, png and gif filenames.
 *
 * @param string $filename Sanitized filename.
 * @param string $filename_raw Filename prior to sanitization.
 * @return string Filtered filename.
 */
function lwp_1866_replace_size_pattern( $filename, $filename_raw ) {
    if ( !preg_match(
            '/.(?:jp(?:e)?g|png|gif)$/',
            $filename
    ) ) return $filename;

    return preg_replace(
            '/(d+)x(d+)/',
            'w$1xh$2$3',
            $filename
    );
}

add_filter( 'sanitize_file_name', 'lwp_1866_replace_size_pattern' );

Но что именно происходит? Мы фиксируем все шаблоны в именах файлов JPG, PNG и GIF и заменяем их шаблонами. Для лучшей согласованности имен мы изменяем подходящие шаблоны в любом месте имени файла, а не только в суффиксе. Наша новая замена не использует никаких конфликтных специальных символов.{width}x{height}``w{width}xh{height}

Вы можете проверить исходный код функции в виде шпаргалки для специальных символов при создании пользовательского шаблона. sanitize_file_name()sanitize_file_name()

Результат, который мы получили после применения кода:

Незначительный глюк в заголовке приложения

Посетители могут заметить проблему на последнем скриншоте. Название вложения осталось без изменений. Чтобы понять, что происходит, мы должны снова заглянуть под капот.

При ручной загрузке изображения в медиатеку мы выполняем его через поле ввода файла методом POST. WordPress использует функцию для обработки самого запроса POST и создания сообщения вложения. Мы найдем причину при копании в его исходном коде:<input type="file" ... >media_handle_upload()

function media_handle_upload( ... ) {

    ... some code ...

    $file = wp_handle_upload( $_FILES[$file_id], $overrides, $time);

    if ( isset($file['error']) )
        return new WP_Error( 'upload_error', $file['error'] );

    $name = $_FILES[$file_id]['name'];
    $ext  = pathinfo( $name, PATHINFO_EXTENSION );
    $name = wp_basename( $name, ".$ext" );

    $url = $file['url'];
    $type = $file['type'];
    $file = $file['file'];
    $title = sanitize_text_field( $name );
    $content = '';
    $excerpt = '';

    ... some code ...

}

Загруженные временные файлы хранятся в $_FILESсупер глобальном массиве. Это выглядит так:

Асинхронная загрузка это имя следующего поля ввода файла:

Это часть формы загрузки, которую WordPress генерирует для загрузки файлов.

В массиве хранятся данные о ранее загруженном временном файле. Эти данные передаются в функцию. Как следует из названия, он обрабатывает фактическую загрузку, включая санитарную обработку. Функция возвращает массив, который хранится в переменной. (См. Вставленный фрагмент кода из функции выше.)$_FILES['async-upload']wp_handle_upload()$file``media_handle_upload()

Его структура похожа на $_FILESмассив:

Теперь начинается интересная часть. При определении заголовка вложения ( $nameпеременная в коде) функция использует исходное имя файла вместо очищенного имени. Это ошибка или особенность? Я не знаю, но мы должны адаптироваться к этому.media_handle_upload() $_FILES[$file_id]['name']``$file['file']

Окончательное решение

Мы также должны расширить нашу функцию для очистки $_FILESданных массива.

Мы сохранили исходную концепцию, так как первый код правильно обрабатывает имена файлов. Хотя из-за упомянутого поведения функции (возможно, ошибки) мы должны также отфильтровать $_FILES суперглобальный. Просматривая весь $_FILESмассив, ища подходящие файлы – это дает нашему коду гибкость, позволяющую работать и с пользовательскими решениями для загрузки.

Результат:

Вывод

Хотя вероятность низкая, может случиться так, что мы не получим ожидаемый результат после загрузки изображений. Для этого несколько условий должны совпадать. Чем больше количество зарегистрированных размеров изображений, с которыми мы работаем, тем выше риск. Используя функции выше, мы можем уменьшить этот низкий риск к нолю. Удачной загрузки!