Pods: Ошибка с обработчиками миниатюр PDF-файлов WP 4.7.1 {@_src} проходит через pods_image_url добавляет суффикс изображения

Забыл скриншоты. Вот мои настройки поля Pod, шаблон Pod и некоторые результаты.

Похоже, нам нужен лучший обработчик для ссылок на файлы вложений, не являющихся изображениями.

https://github.com/pods-framework/pods/blob/2.x/classes/Pods.php#L1452

Прямо сейчас _src и _src.{size} проходят через функцию pods_image_url() .

Я не хочу быть вредителем, просто интересно, есть ли в этом какие-то движения. Я сам не разработчик плагинов, меня просто направили сюда с форумов WP, чтобы привлечь к нему внимание.

Никакого прогресса в решении этой проблемы нет, мы много работали над подготовкой Pods 2.7 к бета-версии. Я добавлю это в свой список, чтобы вернуться к нему, когда у меня появится свободная минута в ближайшие дни.

@portlandian, вы могли бы использовать https://codex.wordpress.org/Function_Reference/wp_get_attachment_url против него, то есть:

{@test_result_pdf.ID,wp_get_attachment_url}

@portlandian
Просто интересно, почему вы просто не используете {@test_result_pdf} ?
Это возвращает URL-адрес PDF, когда я тестирую его здесь. Нет необходимости добавлять ._src или что-то еще.

Такие термины, как full или large относятся ко всем типам изображений, они показаны только потому, что это общее поле файла Pods. Они вам не нужны для типов полей, кроме изображений.

@ sc0ttkclark
Спасибо за своевременный ответ, с нетерпением жду 2.7

@jimtrue
Спасибо за обходной путь. Я не знал об этом. К счастью, мне не понадобится с тех пор ...

@JoryHogeveen
Только потому, что я не знал, что это сработает. Я ссылаюсь исключительно на http://pods.io/docs/build/using-magic-tags/ всякий раз, когда использую шаблоны, и я никогда не видел этого в разделе о тегах для получения URL-адресов файлов. Если он есть, и я его пропустил, это плохо, но, возможно, обращение к файлам без изображений в этом разделе может быть хорошей идеей. Я изменил свой шаблон, чтобы использовать этот тег, и теперь он работает. Проблема решена.

Вы молодцы!

@portlandian Рад слышать, что у вас все заработало!

возможно, хорошей идеей будет обращение к файлам без изображений в этом разделе.

@jimtrue Может быть, действительно хорошая идея! :)

Хорошая мысль, но да, можно подумать, что @_src получит просто URL-адрес файла. В основном, не используя ни то, ни другое, просто используя сам тег для файла, вы получаете «вывод файла» как обычно. Я не уверен, что это сработало бы, если бы у вас было несколько файлов и вам нужно было [каждый файл_образа] [/ каждый] через них, потому что в этот момент нет «тега» для вызова URL, кроме {@_src}, так что нам все еще нужно адресовать и исправлять этот вывод. Это все еще ошибка.

В частности, из заметок Скотта:
Похоже, нам нужен лучший обработчик для ссылок на файлы вложений, не являющихся изображениями.

https://github.com/pods-framework/pods/blob/2.x/classes/Pods.php#L1452

Прямо сейчас _src и _src. {Size} проходят через функцию pods_image_url ().

@jimtrue
Очень хорошее замечание о каждой петле. # 4111 исправляет это.

@ sc0ttkclark Примечание: я сделал пиар против 2.x.

Ах да, @jimtrue .
Комментарий в PR (может быть что-то для документации)

При использовании шорткодов с вложениями PDF ._src возвращает изображение, начиная с WP 4.7.
С этим исправлением он вернет URL-адрес PDF.
Получение изображений, сгенерированных в формате PDF (WP 4.7), по-прежнему возможно с использованием ._src.image_size или ._img.

Принято к сведению!! Я добавлю их как в старые, так и в новые документы

Это исправлено в # 4111.

@JoryHogeveen @pglewis К сожалению, это все еще не работает. Я могу подтвердить, что {@_src} по-прежнему предоставляет ссылку на восстановленные эскизы для PDF-файлов.

Просмотрите беседу в этом тикете по адресу :

Похоже, это связано с хостом, создающим эскизы PDF-файлов. My Local от Flywheel этого не делал, поэтому он правильно связывал файлы PDF, но в WPEngine (который генерирует эскизы) тег {@_src} указывает _ только_ на эскиз изображения, а не на PDF. Очень назойливый.

@ brian-milnes предоставил очень хороший обходной путь, который позволяет получить правильный PDF-файл, так что, возможно, проблема в нашем обработчике для _img и _src:

Мы сделали обходной путь, используя
{<strong i="14">@ID</strong>,wp_get_attachment_url}

Если это вещь, связанная с окружающей средой, мы должны сначала создать аналогичную среду для воспроизведения.
Я знаю, например, что у WP Engine есть собственный плагин, который необходимо использовать.
Можем ли мы составить для этого список?

@JoryHogeveen Я думаю, проблема может быть в том, что мы все еще прорабатываем обработчик 'image' для {@_src}; Я не уверен, почему WordPress отдает предпочтение просмотру эскизов для PDF-файла самому PDF-файлу, но, возможно, это один из тех случаев, когда вместо этого нам нужен тег {@_file}, если {@_src} маршрутизируется через pods_image_url. Нам нужен способ перенаправить их на get_attachment_url.

Я умею составлять список, просто не знаю, есть ли смысл создавать новый тег только для файловых вложений (потому что я предполагаю, что мы столкнемся с этим и с другими файлами) или если нам нужно сделать _src {@_src} умнее.

Мое чутье: {@_img}, _img и любой _src.size должны возвращать эскизы изображений. _src всегда должен возвращать URL-адрес файла.

@ sc0ttkclark Мысли?

Да, и в тестовой среде, да, у нас есть один с themer.pods.io, или мы можем развернуть еще один на нашем хосте pods.io WPEngine, если это поможет @JoryHogeveen

Теперь правильная ссылка # 4964 - тоже хороший пример!

гул, похоже, ни {@_src}, ни {@permalink} не работают в [each]: /

@quasel Предоставьте пример вашего шаблона? Я делаю это все время, и сейчас у меня есть несколько, которые отлично работают.

Просто чтобы подтвердить, обработчики изображений изменились в последних нескольких версиях. Это активная проблема?
@quasel У вас есть быстрый тест для проверки?

Просто чтобы подтвердить, обработчики изображений изменились в последних нескольких версиях. Это активная проблема?
@quasel У вас есть быстрый тест для проверки?

Это все еще проблема с 2.7.22, я обновил свой код шаблона / w временное решение, но он все еще пытается связать эскизы для PDF-файлов.

но он все еще пытается связать эскизы для PDF-файлов.

@zushiba Что вы имеете в виду под "попыткой"? Можете ли вы поделиться случаем использования, который будет неправильным выводом?

но он все еще пытается связать эскизы для PDF-файлов.

@zushiba Что вы имеете в виду под "попыткой"? Можете ли вы поделиться случаем использования, который будет неправильным выводом?
У меня есть поле для загрузки нескольких файлов, оно используется моими пользователями для загрузки PDF-документов, которые затем отображаются на странице с помощью следующего шаблона.

<h1>{@post_title}</h1>
<ul>
[if form_files]
[each form_files]
<li><a href="{@_src}">{@post_title}</a></li>
[/each]
[/if]
</ul>

После загрузки 2 PDF-файлов сегодня один из моих пользователей обнаружил, что при загрузке их PDF-файла полученная ссылка на странице перешла к миниатюре PDF-файла .jpg, а не к фактическому PDF-файлу. Мне удалось подтвердить, что PDF-файлы были загружены на сервер, и в интерфейсе панели управления для элемента модуля он ссылался на нужный файл, но сама ссылка была на миниатюру jpg.

Проблема исправлена ​​в № 5854.
Если пользователи захотят протестировать этот патч, это будет здорово!