XF 1.4 Any way to fix attachments not having an extension?

psTubble27

Well-known member
RSS, Facebook and other such things don't recognize xenforo's links to attached images as true images. I'm surprised I haven't seen more discussion abut this. Is there any way to get the full, standard old-fashioned links to the attached image (with extensions at the end)? Can we use .htaccess, or retrieve the URL of images in some other way?

One thought I had was to use the image proxy which curiously enough preserves the image extension. But that's of course for external [ img ], not the internal [ attach ].

Another was to find some sort of a rewrite plugin (I don't want to alter the database in any way). Would the [bd] Image plugin help, @xfrocks ?

Any other thoughts on how to get at just the pure images in the attachments?
 
Last edited:
XenForo's attachment storage system explicitly denies direct linking of full-sized attachments in part so that it can enforce viewing permissions for the logged in user.

Any solution would have to be an addon that extends the attachment route handler at the very least. I don't suggest rewriting the storage system. You can probably use rewrites to abstract the underlying extensionless URLs if you wish.

You probably shouldn't do this. Requiring a specific file extension to identify an image resource doesn't really work, and adapting an RSS feed to accommodate a specific reader is not good either. And I question the use case since XenForo's outgoing feed does not inline image attachments to begin with. Maybe the reader is trying to convert image hyperlinks into inline images, but such a conversion wouldn't be appropriate if guests don't have permission to view the attachment in question.
 
Thanks so much. It was just a question of permissions, in that I forgot that Facebook (and RSS) see attachments using visitor permissions. There was no problem with how the XF system serves up image attachments.
 
There is one issue with the way xenForo serves image attachments as far as Facebook is concerned. If you attempt to post a thread on Facebook that contains an attachment, Facebook is unable to pull the post attachment as a thumbnail. I have to assume Facebook's source parser that pull the first few images as options for your Facebook post image must be looking specifically for image src paths with extensions that it is familiar with.

This also becomes an issue with the social media management tool Hootsuite, which works in such a similar way as to seem like it's using the same parser as Facebook.

For our sites, any of the news related threads that we specifically push out through media sites have to have their attachment images hosted elsewhere rather then as thread attachments just so they can be included as thumbnails in the media (Facebook) posts. This is not at all ideal.

I'm hoping to look into an add-on to reverse the attachment routing from "attachments/[filename]_[extension].[id]/" to "attachments/[id]_[filename].[extension]" .
Using route filters alone it is easy to specify a new route of "attachments/{name:digit}.{name:string}" and we can even add a nonsense extension like "attachments/{name:digit}.{name:string}.jpg" however we still end up with a final URL that ends with a forward slash like this "attachments/[id]_[filename]_[extension].jpg/" .. That trailing ".jpg/" will likely not be compatible with Facebook either..
 
Just a quick update, I was able to solve my problem with a fairly basic fix.. Just by appending a fake extension and a question mark (query string marker) to the attachments route it achieved what we are looking for. Facebook posts will now pickup the attachment. It is also backward compatible in that the old attachment URLs still work.

Here's what I did:

a) create a new route filter with the following:
Find Route: attachments/{name:string}.{name:digit}
Replace With: attachments/{name:string}.{name:digit}.jpg?
Uncheck "Incoming URL cenversion only"
Check "Enabled"

b) I added the following block to our nginx configuration to stop the media file caching since now we have a URL that would trigger this:
Code:
  location ~* attachments/.*\.jpg$ {
    try_files $uri $uri/ /index.php?$uri&$args;
  }
Note that this might not be necessary for you.
 
b) I added the following block to our nginx configuration to stop the media file caching since now we have a URL that would trigger this:
Code:
  location ~* attachments/.*\.jpg$ {
    try_files $uri $uri/ /index.php?$uri&$args;
  }
Note that this might not be necessary for you.

Why did you want to disable media file caching for these images?
 
Just a quick update, I was able to solve my problem with a fairly basic fix.. Just by appending a fake extension and a question mark (query string marker) to the attachments route it achieved what we are looking for. Facebook posts will now pickup the attachment. It is also backward compatible in that the old attachment URLs still work.

Here's what I did:

a) create a new route filter with the following:
Find Route: attachments/{name:string}.{name:digit}
Replace With: attachments/{name:string}.{name:digit}.jpg?
Uncheck "Incoming URL cenversion only"
Check "Enabled"

b) I added the following block to our nginx configuration to stop the media file caching since now we have a URL that would trigger this:
Code:
  location ~* attachments/.*\.jpg$ {
    try_files $uri $uri/ /index.php?$uri&$args;
  }
Note that this might not be necessary for you.

Thanks for posting this. We now have CloudFlare caching attachments that are only visible to guests with this route filter.
 
Back
Top Bottom