Hey guys,
Christian provided me with this great script last year that displays the file names of files attached to posts instead of the link (see ticket: https://toolset.com/forums/topic/display-the-caption-or-file-name-of-uploaded-attachment-files/ ). It usually works really great – except that there are some rare times it doesn't, and I just can't figure out why. Do you want to have a look at it?
The best is to go to
hidden link
which is an archive page. You can see that the top entry and another few (like "RS 6-2021 Unterrichtsbetrieb ab dem 15. März 2021" further down) replace the file name of EVERY attachment with the title of the post.
Let me know if you need access to the backend.
Thanks in advance!
Jannis
Hi, I can take a look and see why these edge cases are failing. I'll need access to the backend, and I should probably make a clone of your site using the Duplicator plugin so I can run tests locally. If that's okay, please provide login credentials in the private reply fields here.
I can see why the script is not working as expected in these cases and explain why, but I'm not sure I'll be able to provide a solid solution given the state of the database. Let me explain. When you save a file in a Types custom field, Types saves the URL of that file in the database as the custom field value.
For example, in the case of this post:
hidden link
The custom field file URLs are:
hidden link
and
hidden link
You can see those URLs in the postmeta table under the key "wpcf-anhang_rundschreiben" for post ID 7798. The custom shortcode we implemented looks for the attachment post in the database post table with a GUID value identical to that file URL. That allows us to find the caption or title associated with this file in the Media Library. However, in your database, the attachment post GUIDs are not identical to the file URLs:
File URL: hidden link
Attachment post GUID: hidden link
and
File URL: hidden link
Attachment post GUID: hidden link
You can see that the file URLs and their related attachment post GUIDs are not identical. It looks like the GUIDs were manipulated somehow, perhaps with a SQL script or some other 3rd -party process. So when the custom code looks for the matching attachment post in the posts table by querying on GUID, it finds no attachment post with an identical GUID, and the problem you're seeing on the front-end occurs.
The solution is not simple, unfortunately, since Types does not store an attachment ID when it stores custom field values, it simply stores the URL of the file. If that URL is not identical to the relevant attachment post's GUID attribute, there is not a simple way to determine which attachment post is related to that postmeta file, which means finding the media item's title or caption is not simple. We could update the script to look for the file name only, but that would not always be accurate - for example if two files have the same filename but are stored in different upload directories.
Alternatively, you could modify the GUID of each attachment post to match the URL of the actual file, but I'm not sure how that would affect other 3rd-party systems used to store these files. Modifying GUID values in the database is generally unadvised in a WordPress environment. You mentioned redirects, so I'm not sure how those might be impacted. I welcome feedback here, to see if there is some common ground or another approach that makes sense.
Thanks for the exhaustive reply, that explains the problem. There is no easy fix, but there is probably a way to avoid it, I need to try it out.
It has to do with the way the attachments are being uploaded. I use the Real Media Library and the Real Physical Media plugin in order to upload and keep the files in certain folders (real, not virtual) in order to give them better protection. The problem should not appear when I choose the folder I want to upload the file first, and the upload it, instead of uploading it first and moving it afterwards. This lets Real Physical Media create the redirect that confuses Toolset. This also explains why this happens only sometimes.
Thanks again!
My issue is resolved now. Thank you!
