Pods: Bug with WP 4.7.1 PDF Thumbnails {@_src} handlers goes through pods_image_url appends image suffix

Created on 9 Mar 2017  ·  26Comments  ·  Source: pods-framework/pods

I have a Pod setup with a File / Image / Video field.

When a user is adding content in the CPT, and they upload a PDF into that field, the URL generated shows a .jpg extension on the file instead of a .PDF (thus displaying the jpg thumbnail in the browser when clicked, rather than linking to the PDF)

Ex: the file I want to display is
DMB-170119_17-000154-01-08.pdf

but the URL generated ends with
DMB-170119_17-000154-01-08-pdf.jpg

This only happens for PDF’s that have been uploaded within WP 4.7, where a thumbnail has been generated. PDF’s uploaded prior to 4.7 (that still have the generic WP gray icon for a PDF file) have the correct .pdf file extension in the URL.

TemplateMagic Tags Reproduced Bug

All 26 comments

Forgot screenshots. Here is my Pod field setup, Pod template, and some of the output.

voila_capture 2017-03-08_05-52-35_pm2
voila_capture 2017-03-08_05-53-35_pm
voila_capture 2017-03-08_05-59-21_pm

Looks like we need a better handler for non-image links to attachment files.

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

Right now _src and _src.{size} go through the pods_image_url() function.

I don't mean to be a pest, just wondering if there's any movement on this. I'm not a plugin developer myself, was just directed here from the WP forums to get some attention on it.

No progress on a fix for this, we've been hard at work on preparing Pods 2.7 for beta. I'll add this to my list to return to when I get a spare moment in the coming days.

@portlandian you might be able to use the Workaround in #3376 of passing the ID of the attached file into a function and using https://codex.wordpress.org/Function_Reference/wp_get_attachment_url against it, ie:

{@test_result_pdf.ID,wp_get_attachment_url}

@portlandian
Just wondering, why aren't you just using {@test_result_pdf}?
This returns the PDF url when I test it here. There is no need to append ._src or anything.

Terms like full or large are all image types related, they are just shown because it's a general Pods file field. You don't need them for field types other than images.

@sc0ttkclark
Thank you for a timely reply and I'll look forward to 2.7

@jimtrue
Thank you for the workaround. I wasn't aware of it. Fortunately I won't need since...

@JoryHogeveen
Only because I wasn't aware that would work. I refer solely to http://pods.io/docs/build/using-magic-tags/ whenever I use the templates, and I never saw that in the section about the tags to get file URLs. If it's there and I missed it, my bad, but perhaps addressing non-image files in that section might be a good idea. I've changed my template to use that tag and now it works. Issue resolved.

You guys are great!

@portlandian Glad to hear you got it working!

perhaps addressing non-image files in that section might be a good idea.

@jimtrue Might be a good idea indeed! :)

Good point, but yeah one would think @_src would get just get the file URL. Basically by not using either, just using the tag itself for the file, you get the 'file output' as normal. I'm not sure that would work if you had multiple files and needed to [each image_file][/each] through them, because at that point, there is no 'tag' to call for the URL other than {@_src}, so we still need to address and fix that output. This is still a bug.

Specifically from Scott's Notes:
Looks like we need a better handler for non-image links to attachment files.

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

Right now _src and _src.{size} go through the pods_image_url() function.

@jimtrue
Very good point about the each loops. #4111 fixes this.

@sc0ttkclark Note: I've made the PR against 2.x.

Oh and @jimtrue .
Comment in the PR (might be something for the docs)

When using shortcodes with PDF attachments ._src returns an image since WP 4.7.
With this fix it will return the PDF url.
Getting PDF generated images (WP 4.7) images is still possible using ._src.image_size or ._img.

Noted!! I'll add them to both old and new docs

This has been fixed as of #4111

@JoryHogeveen @pglewis Unfortunately this is still broken. I can confirm that {@_src} is still providing the link to the regenerated thumbnail's for PDFs.

Please check out the conversation in this ticket from: https://github.com/pods-framework/pods/issues/4580#issuecomment-354883021 downward.

This seems to be related to the host creating thumbnails of PDF's. My Local by Flywheel wasn't doing it, so it was properly linking to the PDF files, but on WPEngine (which does generate thumbnails), the {@_src} tag is pointing _only_ to the image thumbnail, not the PDF. Very annoying.

@brian-milnes provided a very good workaround that gets right to the correct PDF, so maybe it's something in our handler for _img and _src is the issue:

We did a workaround using
{@ID,wp_get_attachment_url}

If it's an environment thing we should fist create a similar environment to replicate.
I know WP Engine has it's own must-use plugin for example.
Can we make a list for this?

@JoryHogeveen I think the problem might be that we're still going through the 'image' handler for {@_src}; I'm not sure why WordPress would be putting preference over the thumbnail views for a PDF over the PDF itself, but maybe this is one of those cases where we need a {@_file} tag instead, if {@_src} is routed through pods_image_url. We need a way to route them to the get_attachment_url.

I'm good with making a list, just don't know on this one if it makes sense to create a new tag just for file attachments (because I'm guessing we'd run into this with other files as well) or if we need to make _src {@_src} smarter.

My gut feeling: {@_img}, _img and any _src.size should be returning the image thumbnails. _src should always return the file URL.

@sc0ttkclark Thoughts?

Oh and on the test environment, yes, we have one with themer.pods.io or we can spin up another one on our pods.io WPEngine host if that helps @JoryHogeveen

Now the correct link #4964 - is a good example too!

hum now it seems neither {@_src} nor {@permalink} work in an [each] :/

@quasel Provide your template example? I do this all the time and have several right now that are working perfectly.

Just to confirm, image handlers have changed in the last few versions. Is this an active issue?
@quasel Do you have a quick test available to check?

Just to confirm, image handlers have changed in the last few versions. Is this an active issue?
@quasel Do you have a quick test available to check?

This is still an issue as of 2.7.22, I've updated my template code /w the workaround for the time being but it's still attempting to link thumbnails for PDFs.

but it's still attempting to link thumbnails for PDFs.

@zushiba What do you mean with "attempting"? Can you share a use-case which would be incorrect output?

but it's still attempting to link thumbnails for PDFs.

@zushiba What do you mean with "attempting"? Can you share a use-case which would be incorrect output?
I have a multi-file upload field, it's used by my users to upload PDF documents which are then listed to a page via the following template.

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

Upon uploading 2 PDF's today one of my users discovered that when their PDF was uploaded, the resulting link on the page went to the .jpg thumbnail of the PDF, not the actual PDF. I was able to confirm that the PDFs were being uploaded to the server, and in the dashboard interface for the pod item it was linking to the right file, but the link itself was going to the jpg thumbnail.

Issue fixed in #5854
If users would like to test this patch that would be great!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

garypaul picture garypaul  ·  7Comments

Kpudlo picture Kpudlo  ·  4Comments

sundco picture sundco  ·  5Comments

Ramoonus picture Ramoonus  ·  5Comments

wpstudio picture wpstudio  ·  6Comments