Как сохранить пропорции картинок в WordPress?

Question

[Lici]

Картинки от превьюшек выводятся сильно покоробленными, если поле для превьюшки и сама картинка не совпадают по пропорциям.

Скрин: habrastorage.org/files/954/e4a/ac6/954e4aac6ec94d3...

Вот тут inform.kharkov.ua

Выводится это так:

echo '<div class="spec"><a class="spec-img" href="'.get_permalink().'">'.get_the_post_thumbnail($page->ID, 'thumbnail').'</a><div class="spec-title"><a href="'.get_permalink().'">'.get_the_title().'</a></div></div><div class="its">';

Я бы с радостью сделал вместо вывода картинок - вывод div блока нужных размеров с фоном-катинкой и было бы все ок.

Но я не знаю, как получить ссылку на картинку в виде переменной.

Или какие есть решения в моей ситуации?

Answer 1

[Игорь Воротнёв]

Не надо подключать всякие BFI_thumb, TinThumb и прочую ересь, я вас умоляю! У WP есть родные средства!

Получить урл картинки:

<?php wp_get_attachment_image_src( $attachment_id, $size, $icon ); ?>

где $size - либо название размера (medium, large), либо массив из двух чисел - высота и ширина
На выходе получите массив:

[0] => url
[1] => width
[2] => height
[3] => boolean: true if $url is a resized image, false if it is the original.

codex.wordpress.org/Function_Reference/wp_get_atta...

Comments

[Lici]

img src="<?php wp_get_attachment_image_src( $attachment_id, $size, $icon ); ?>" ?

[Александр Зеленин]

@HeadOnFire как раз тут нужно создать дополнительный размер картинки.

[Игорь Воротнёв]

@zelenin для начала можно обойтись изменением одного из предустановленных размеров. И только если этих разных размеров заметно больше, нельзя использовать что есть (в том числе уменьшая и подгоняя по размеру в css) - только тогда создавать дополнительные размеры. Ибо каждый дополнительный размер будет создаваться для каждой фотографии. Я, как владелец 2х новостных порталов, знаю чем это выползет через 2 года, когда картинок будет гигов 10. И когда захотите сменить тему, а там другие размеры.

[Lici]

@HeadOnFire в моем случае 7 гигов ;) пережимал потом bash скриптом)

[Игорь Воротнёв]

@Lici Нет.
$src_arr = wp_get_attachment_image_src( $attachment_id, $size, $icon );
$src = $src_arr[0]; // здесь урл в чистом виде

[Игорь Воротнёв]

@Lici есть плагин ajax thumbnail rebuild, отлично справляется. Но все же это лишний гемор. Мне с первым новостным сайтом пришлось уйти от хостера не потому, что места или трафика больше ел, а inodes не хватало. Файловая система была забита всякими дополнительными размерами и прочей ерундой.

[Lici]

@HeadOnFire я имею ввиду пережимал качество до 70% дабы уменьшить размер ибо очень много весило.

[Lici]

@HeadOnFire благодарю. пока мне подучить php.

[Александр Зеленин]

@HeadOnFire wp_get_attachment_image_src выдает ссылку на готовую картинку. Если она не подходит по пропорциям - фейл.
10 гигов картинок - пустяки. Плагин сам пережмет все картинки.
Новая тема - пустяки. 30 секунд на добавление новых размеров.

[Игорь Воротнёв]

@zelenin все относительно. Например, я для оптимизации скорости работы сайтов использую VPS от Digital Ocean, который на SSD. Гигабайты SSD весьма недешевые. Простая математика. Пример: новостной сайт по шоу-бизнесу. Редакторы загружают целые фотоотчеты с каких-то вечеринок. Грузят файлы любых размеров, в том числе оригиналы прямо из камеры. Сверху еще генерится куча превьюшек разных размеров. Каша. Вес папки uploads увеличивается как на дрожжах. Далее ставится плагин Imsanity который ограничивает максимальный размер (грузить можно любой файл, но он потом ресайзится, таким образом оригинальный размер всех файлов никогда не превышает заданные размеры), ставится EWWW Image Optimizer для сжатия без потерь качества, проводится инспекция всех размеров картинок и из 6 разных размеров, созданных ЛЕНИВЫМ девелопером оставляются стандартные 3, которых в реальности более чем достаточно. В итоге, было почти 20Гб мусора, около 50 000 файлов. Становится 6Гб и меньше 20 000 файлов. В деньгах это выражается просто - экономия $20 каждый месяц.

Если картинка не подходит по пропорциям - есть CSS overflow. Это не я узко мыслю, я как раз стараюсь мыслить эффективно. А вот ленивые разработчики, вместо того, чтобы думать стратегически, плодят кучу дополнительных размеров, подключают сторонние библиотеки, и т.д. Владельцу проекта такой необдуманные подход рано или поздно вылазит боком.

[Александр Зеленин]

@HeadOnFire

Преждевременная оптимизация — корень всех (или большинства) проблем в программировании

https://ru.wikiquote.org/wiki/%D0%94%D0%BE%D0%BD%D...

[Александр Зеленин]

@HeadOnFire нет, вы мыслите узко, как человек, борющийся за мегабайты, за которые следует бороться, только когда их не хватает. А я разработчик - борюсь за то, чтобы все работало как часы.
overflow не подходит для всех вариантов.

[Игорь Воротнёв]

@zelenin не нужно путать со здравым смыслом. Оптимизация не преждевременная, а как раз на базе накопленного опыта и наступания на грабли. Толковый разработчик изначально систему строит оптимизированной на необходимом уровне. И здесь дело не только в мегабайтах, хотя и они безусловно важны. Чем меньше разных размеров, тем меньше самих файлов грузит пользователь, меньше запросов обслуживает сервер. Те превьюшки, которые он получил на главной, на других страницах уже берутся из кеша. Это тоже большой плюс. Здесь нужно видеть все шире. Ваше утверждение неприменимо. Оптимизированная система тоже работает как часы, ничем не хуже, и даже лучше. Одно другому не мешает. Вы же эти понятия фактически противопоставляете, что в корне неверно. Я занимаюсь разработкой тем для WordPress уже не один год, и с размерами под разные форматы вывода сталкивался уже очень много раз. Паттерн "не плодить ничего лишнего без крайней на то необходимости" всегда был, есть и будет самым разумным подходом. Ваша позиция по "преждевременной оптимизации" - это обычная лень и нежелание разработчика принимать стратегические решения. "Сначала сделаем абы работало, а потом посмотрим, если что - допилим".

Answer 2

[Руслан]

Или BFI_thumb или задавайте блоку с картинкой размеры и overflow:hidden
UPD:
или регистрируем новые размеры превью с помощью add_image_size( $name, $width, $height, $crop )

Comments

[Lici]

BFI_thumb - куда и как использовать?

Блоку размеры и обрезать не получается, тк картинки превью почему-то очень большого размера и обрезается кусок больной.

[Руслан]

@Lici
Подключаем(functions.php)
require_once('BFI_Thumb.php');

Вызываем, оно обрежется по указанным размерам
the_post_thumbnail( array( 1024, 400, 'bfi_thumb' => true ) );

Другой путь: регистрируем новые размеры превью с помощью add_image_size( $name, $width, $height, $crop )

[Игорь Воротнёв]

@rOOse боже упаси плодить дополнительные размеры и тем более подключать сторонние библиотеки. Все есть уже давно в самом WP! Смотрите мой ответ.

[Руслан]

@HeadOnFire это просто проставление размеров, картинка будет выбираться из 3 существующих

[Игорь Воротнёв]

@rOOse и один из 3х существущих вполне должен подходить, их размеры можно изменить в настйроках или через код. Я там на сайте вижу 2 размера - превьюшка поменьше и превьюшка побольше (о которой и идет речь). Первая - thumbnail, вторая - medium, и еще остается large для вставки больших картинок и original для полноразмерного просмотра в лайтбоксе, если нужно (хотя вряд ли). Зачем здесь плодить дополнительные размеры? Чтобы через год-два работы сайта папка uploads весила на 20% больше? Или чтобы при смене темы (дизайна) нужно было опять пересоздавать все превьюшки, менять размеры, создавать новые... Зачем?

[Александр Зеленин]

@HeadOnFire вы как владелец двух сайтов, мыслите достаточно узко. Правильно для владельца, но узко для разработчика. Конечно следует сначала посмотреть - возможно старые размеры подходят по пропорциям. Но нужно учесть, что такая практика может вылезть боком в неучтенной ситуации. Поэтому лучше всегда создавать дополнительные размеры.
Объем папки uploads должен волновать только при сопоставимом объеме всего хостинга.

[Руслан]

@HeadOnFire Может походить, а может и нет, в данном случае может и подойдет, а если бы изначально были выставлены размеры для превью, то и вовсе замечательно, иногда нужны точно обрезанные картинки, што вы так разволновались =) для разных случаев разные подходы, я предложил варианты, вы предложили, дальше ТС сам уже решит что ему больше подходит.

[Игорь Воротнёв]

@rOOse просто я пурист) В основном работаю на запад, там по умолчанию стараются использовать по максимуму богатые возможности ядра, на то они там и есть. Последний год начал осваивать рунет, и начал прозревать от того количества костылей, которые строят над WP там, где это вообще не нужно. Вместо того, чтобы почитать доки и полистать код самого WP, среднестатистический рунетовский разработчик запилит сверху костыль. Как евангелист WP стараюсь препятствовать этому везде, где это возможно. Особенно это касается новичков, которые только осваивают WP. Дай им дурной совет - и вырастет еще один костылестроитель. Направь в правильное русло - вырастет толковый разработчик. Ничего личного :)

[Руслан]

@HeadOnFire =) так это не костыли) добавление еще одного размера как раз функция ядра, ВП сам говорит, делай так =), а bfi_thumb кем написан? На западе и написан, просто если у тебя стоят размеры к примеру 400х200, а прям сейчас нужны 200х200 то тут уж кроме как bfi_thumb ничем другим не обойдешся. Давайте примеры костылей и как надо, а то я сам любитель костылей =)

[Игорь Воротнёв]

@rOOse ну вот bfi_thumb и есть костыль. Ресайзы на лету - плохая практика, неразумное использование ресурсов. Картинки должен выпллевывать Nginx даже без обращения к PHP, не то что процессить их на лету. Ясно, что на западе тоже своих клоунов хватает) Но процентное соотношение заметно меньше. Генерить допразмеры можно и нужно, если это необходимо. В данном случае я вообще не вижу необходимости, на сайте 3 разных размера картинок. И как раз 3 (не считая оригинала) WP предлагает по умолчанию. Зачем генерить новый размер, если можно изменить стандартный? Если на постоянной основе нужно кропнутый (например, тот же 600х600) - это тоже можно сделать, все настраивается, кроп можно задать и для размера medium, и large, если в этом есть необходимость - не только для thumbnail. Если же нужно временное решение "в нескольких местах", то создавать лишний размер - тем более глупо, ибо он будет создан для ВСЕХ загруженных картинок, из которых большинство не будет использоваться. Вместо этого лучше использовать уже существующий, например, 900х600, и оборачивать его в overflow:hidden.

[Руслан]

@HeadOnFire bfi_thumb там кэш) генерится 1 раз, оферфлоу тоже предлагал, самый лучший вариант, ничего делать не надо)

[Игорь Воротнёв]

@rOOse ну если б он не сохранял сгенеренную картинку - это же вообще был бы мрак) Сам по себе инсструмент нормальный, тем более что он хукается в родные функции. Просто в данном случае я не вижу вообще никакой необходимости использовать сторонние решения, инклудить и выполнять лишний класс, если поставленная задача решается родными средствами на ура, без дополнительных плясок. По воробьям из пушки)