jkilbride

Thanks, David! I’ll give that a try.

@mamunur34
No, I did not add a cronjob myself. The situation I described was the default setup.

@wfalaa I run dedicated servers, so technically I am my web host.

This might be plausible, if it didn’t keep re-occurring. But this is the 2nd time it’s happened. It might happen every time, I don’t know. I don’t always catch the upgrade notice before the automatic upgrade happens. For it to keep occurring, the files would have to be changing permissions every time. Bad permissions before a manual upgrade -> good permissions for the auto update -> bad permissions again -> etc… I have never changed permissions on any files. To me, it points to some kind of difference in the way manual and automatic upgrades are handled.

Honestly, I don’t really care. It’s a free product and it works great. I wanted to bring this to your attention and post it here, in case anyone else was having the same issue. I just won’t try to manually upgrade anymore.

@mross55 Sorry, I use nginx, so htaccess files have no effect on my config.

Just to follow up…

While my attempts to manually upgrade failed, it looks like the automated upgrade succeeded. So, go figure. I have no idea why there would be a difference between manual and automated upgrades, but my system is running v7.1.4 now.

Thanks.

@otto42:

Thank you for your reply.

I completely understand the limitations of browser based implementations like the file upload dialog. I’m not looking at this as a security measure or a foolproof way to stop unwanted files from being uploaded. I’m more concerned about UX/UI and consistency for the users – and not having them upload a large (video) file only to find out it isn’t supported. As I said, anyone who steps around this basic precaution, by selecting “All Files”, or tries to spoof the upload file type will have to be caught by the server. I agree, there’s no way to prevent this.

However, the normal browser file input does have an “accept” attribute. So, even the basic uploader which doesn’t use javascript should be able to filter files in the same way.

Thanks for the pointers to the fileinfo extension and getimagesize function. I believe I have those available, but I will double-check.

I will take a look at posting a ticket to the core bug tracker. I haven’t used Trac or svn in a long time, so I’ll have to play with it. I’m more familiar with git/github. I’ll leave this open for a bit longer and if there are no further replies I will close it.

If the file can’t be selected in the file dialog, then it’s certainly not “uploaded to the servers temp folder and tested on.” Also, “[i]n reality WordPress is creating an AJAX process talking to the server where the upload is and returning information on the validity of the file” — I don’t know where you’re getting this. Can you point to a code example where this actually happens? Again, if you can’t select the file in the file dialog, how does WordPress test it’s validity with the server?

Overall, I think you’re missing my point.

1. I’m not suggesting files that are uploaded should not be tested on the server. That would be dumb. All I’m saying is that files that can be filtered out in the browser by extension or mime type, should be filtered out in the browser.
2. I’m aiming this at the typical WordPress user, not at someone who is actively trying to spoof an upload. People spoofing uploads is the reason why you would never remove the file checking done by the server.
3. If there are other hooks for handling file upload mime types, I haven’t been able to find them. Every example I’ve seen uses the upload_mimes filter.
4. The thing that’s frustrating, and the reason I brought this up, is that it does work in some of the file dialogs. Some of the file dialogs respect the upload_mimes filter and only let you select file types that are explicitly allowed. My simple question is: why don’t they all work this way?

I’m trying to be as clear as possible about this. Maybe it’s not coming across that way. It’s possible that this is the wrong place to bring this up. Maybe it belongs in a bug report or feature request?

The problem I’m trying to fix is to avoid uploading files that shouldn’t be uploaded in the first place. If WordPress has the ability to prevent uploads at the browser — which it obviously does, because it works that way in some instances — then it should do so. It’s a waste of time, bandwidth, and server resources to allow files to be uploaded, only to have them throw an error once they reach the server. And since some of the file dialogs already respect the upload_mimes filter, it should be straightforward to add this functionality to all of them.

While I understand that the file dialog is browser + OS specific, I am not changing my browser and OS when testing this stuff. So, with the same browser and OS, the file dialog interface is different on different pages in the admin. That’s pretty much the definition of inconsistent. Also, I wouldn’t characterize the interfaces as only being a bit different. One prevents uploads from happening for disallowed mime-types. The other uploads the file and then tasks the server with rejecting disallowed mime-types. From a software / programming perspective, that’s a big difference.

Finally, standardization is good. Why wouldn’t you want these interfaces to be standardized? It’s confusing otherwise. When I setup my upload_mimes filter and tested it for the first time, it seemed to work great. The only file types I was able to select in the file dialog were those that I had allowed. Later, when I tried uploading from a different interface, I was able to select all file types. I had to think to myself, “Wait a second… that worked differently before. What’s going on?” I thought maybe I had done something wrong. After that, I went through each different way a file could be uploaded to the Media Library and found the inconsistencies I detailed above. If all the uploading interfaces worked the same (at least, for the same OS and browser combinations), we could avoid that type of confusion for other people.

Hi @cybr,

Great, thank you!

You can try the community supported “fixed” version of w3tc:

https://github.com/szepeviktor/w3-total-cache-fixed

Bug fixes and updates usually happen much quicker there.

Yeah, this is getting pretty annoying. Combined with the general lack of features in the free version — I have to login to GA to see decent stats anyway — it may be time to move on.

Nice little monster logo, but otherwise… meh.

When I view the media library as a grid and click “Add New”, the grid remains and the upload progress bar appears at the bottom of the grid — which is typically out of view without scrolling down.

When I view the media library as a list and click “Add New”, the list disappears and the upload progress bar is visible just below the drag and drop upload area.

So, either the grid should disappear when uploading, like the list does, or the upload progress bar for the grid should appear in the first box rather than under the grid.

Wordpress 4.9.4
PHP 7.1.15