Chrome downloads PNG files, instead of displaying them

Yes it’s because theme/ plugin authors aren’t specifying the correct mime type. You should contact the theme/ plugin author with the issue.

Feedback – change the code to detect the mime type based upon the file when serving them rather than relying upon what was specified with the svn checkin.

Many of us in our own web apps do that already to solve exactly this type of issue (as well as preventing malicious software intentionally uploaded with the wrong mime type)

Or the plugin authors can level up and start doing it the right way. ??

https://www.ads-software.com/support/topic/bug-wordpresorg-site?replies=10#post-6316401

It is not an either or.

Sorry if this wasn’t clear, but this is site feedback for the folks who run www.ads-software.com, not the WordPress software, so themes and plugins have nothing to do with this.

On plugin screenshot pages, there are PNG images reduced in size to fit the page and linked to the full-size image. When clicked, the full-size image is downloaded, rather than opened in the browser.

I hope this is now clearer.

You were clear.

When clicked, the full-size image is downloaded, rather than opened in the browser.

See https://make.www.ads-software.com/plugins/2014/03/20/plugin-screenshots-downloading/ for why that is. It is something that happens when the plugin authors upload via SVN incorrectly.

The author can fix that easily enough.

From what I see, the HTML contains a link to a PNG image with a version, which should be handled as per the web server settings (but isn’t, apparently). Where is this mime type being stored?

They are using the mime type that the svn client sends for the file when the plugin author uploads it.

If you don’t specify the mime type when adding non text files to svn, it uses a generic binary mime type that Chrome and FireFox rightfully interpret as a download.

IE apparently does further analysis of the file (either by extension or looking at the beginning) and handles it as an image, IE is famous for compensating for incorrect mime types which has caused issues in the past.

Plugin authors should specify the correct mime type but reality is this will always be a problem as long as they use SVN so in my humble opinion for the benefit of the user, the server should compensate when the plugin author doesn’t.

Not sure why they aren’t letting apache serve it selecting mime type by extension, but they may have a good reason.

Are you saying that when the file is uploaded, it’s converted? If not, where is the mime type stored?

Maybe the server can be configured to compensate only for images in the plugins area or perhaps only for screenshots? Files seems to be stored at ps.w.org/PLUGIN/assets/screenshot-1.png?rev=REV, which should be possible to match.

mime type the server sends has nothing to do with the actual file. You can send application/pdf with a WebM if you want. Won’t work in the browser but you can send it.

With SVN when you upload a binary file without specifying the mime type, most clients will choose application/octet-stream when they tell the SVN server what kind of file it is.

SVN treats text different than binary, because with text files it keeps a record of diffs between commits. So the client tells the SVN server an image is application/octet-stream so it does not treat it as a text file.

SVN mime types were never intended as a means of telling a web server what to send, so clients don’t bother with further identification as they just don’t need to. Not for the purpose of mime types within the context of SVN – which simply is revision control.

But www.ads-software.com uses those mime types to determine what mime type to send in the http header from a web server, and that results in the issue that exists.

For example, if a file’s svn:mime-type property is set to a non-text MIME type (generally, something that doesn’t begin with text/, though there are exceptions), Subversion will assume that the file contains binary—that is, not human-readable—data. One of the benefits that Subversion typically provides is contextual, line-based merging of changes received from the server during an update into your working file. But for files believed to contain binary data, there is no concept of a “line”. So, for those files, Subversion does not attempt to perform contextual merges during updates. Instead, any time you have locally modified a binary working copy file that is also being updated, your file is renamed with a .orig extension, and then Subversion stores a new working copy file that contains the changes received during the update, but not your own local modifications, at the original filename. This behavior is really for the protection of the user against failed attempts at performing contextual merges on files that simply cannot be contextually merged.

Also, if the svn:mime-type property is set, then the Subversion Apache module will use its value to populate the Content-type: HTTP header when responding to GET requests. This gives a crucial clue about how to display a file when perusing your repository with a web browser.

https://svnbook.red-bean.com/en/1.2/svn.advanced.props.html

Okay so they are probably using the svn apache module and changing this would require patching that module so what I would like it to do for the benefit of joe user isn’t likely to happen.

I take that back – further reading it would be easy for them to fix this for the end user.

<Location /whatever>
    ModMimeUsePathInfo on
</Location>

ModMimeUsePathInfo apache module lets apache determine and send the mime type.

So www.ads-software.com can fix this for the end user.

Well done, @alicewonderfull. Not being a plugin developer, I didn’t realize how these pages were being served.

I supposed the location configuration will work, as long as it doesn’t interfere with uploading and merging files.

www.ads-software.com admins, can you chime in, please?

www.ads-software.com admins, can you chime in, please?

I don’t think my posting this will change anything in this topic or put it to bed but they already did chime in. ??

This is a link to what Otto (Tech Ninja here among other things) wrote about it.

This is (again) a link to what the plugin team wrote about it on the plugin make/blog.

Plugin Screenshots Downloading?

tl;dr The plugin author needs to use SVN with the correct mime types.

Yes, a hack on the server level may fix it but that’s a bandaid. The problem remains that the images are being sent with the wrong mime type. It’s technically doable but forcing the web server (it’s nginx but that doesn’t really matter) to make corrections isn’t the way to get the to the source of the problem.

Jan, I don’t think that’s satisfactory. Those who need to make a change are the plugin developers, but those who get the crap user experience are the rest of us.

It looks like site admins have the power to change this and I see no reason not to do this.