Upload not working!

https://github.com/Lewiscowles1986/WordPressSVGPlugin can be used as a reference for how to fix. Essentially we fake mime as application/svg+xml and then remap that to image/svg+xml after that check to bypass WordPress being a PITA

Thanks for the pointer, @lewiscowles – I tried your plugin, but it was still giving me a “couldn’t upload because security” warning when uploading SVGs. I’m not sure if this is because your plugin doesn’t explicitly set the number of arguments for the filter? However, after tinkering with a very similar solution, that seems to be what fixed it for me.

To manually update the SaveSVG plugin while waiting for an update:

1. Add the following to the __construct() function:

add_filter('wp_check_filetype_and_ext', array($this, 'fix_mime_type_svg'), 10, 4);

2. Beneath the allow_svg($mimes) function, add the following:

public function fix_mime_type_svg($data=null, $file=null, $filename=null, $mimes=null) {
	
	global $wp_version;
	
	if ( $wp_version !== '4.7.1' ) {
		return $data;
	}
	
	$filetype = wp_check_filetype( $filename, $mimes );
	
	return [
		'ext'             => $filetype['ext'],
		'type'            => $filetype['type'],
		'proper_filename' => $data['proper_filename']
	];
	
}

Note that this hack specifically targets WP version 4.7.1; if you’re having issues with a different version, you should either modify the $wp_version check or remove it altogether.

• This reply was modified 7 years, 10 months ago by indextwo. Reason: Missed some code formatting
• This reply was modified 7 years, 10 months ago by indextwo. Reason: Missed s'more code formatting

Thanks, @indextwo!
Your code works great here!

@indextwo did you try running it vanilla? That’s where I’m running my tests and where I’m manually verifying the plugin mods are working. Perhaps if it’s not working you have some other cruft on the system. I’d love to get more information on what is not working.

I ran a debug suite against your code above and it doesn’t work using this plugin in vanilla simply because the GD test wipes out the values. Of course I’m happy to run anything that works, but it has to work on a vanilla install.

@lewiscowles Nope, it was a production site – I wasn’t aware of the issue until a client mentioned they couldn’t upload an SVG.

I didn’t have Safe SVG installed; I was using my own code to add image/svg+xml to the allowed MIME types array with add_filter('upload_mimes'). However, it looks like a core bug is currently stopping this from working (reference) – it seems to interfere with some other non-image filetypes as well.

I initially tried folding your code into my own, changing the incoming MIME type to application/svg+xml and then switching it to image/svg+xml via the wp_check_filetype_and_ext filter/function (which I didn’t know about before now!), but it didn’t work. Then I took out my own code and installed your plugin, and it still didn’t work. For a trifecta, I disabled your plugin, and added the same code to the Safe SVG plugin, but still no joy.

As I said, I suspect it may be something to do with the fact that your filter call doesn’t state the number of arguments – mine wasn’t working until I explicitly added the priority and arguments. But it may well have been something else. The site is running 4 custom plugins, plus ACF Pro and Download Monitor.

TBH as it works on vanilla single site and multisite for now it’s wontfix / user_setup_issue as I wouldn’t be able to verify at which point it’s failing.

The upload enabling is as you’ve mentioned the smallest parts of the plugin to add application/svg+xml for the svg extension so it bypasses image checks, then to use the filter function to switch back. The first part is important as otherwise the ext is lost through GD check.

I’m going to push an update today with the priorities for all hooks and number of function args for all filters and tag a new release; I’d love if you could test again, and to know the PHP version and OS you are running under (I know centos sometimes gives weird behaviour without # args). I’ll understand if you don’t want to be installing lots of plugins, iterating checks from random’s on the internet to live client sites. (maybe testing in a VVV?)

The thing to be careful on with unfiltered uploads is that there is no point where even a coder in a local env should enable that; the thing about using Fileinfo is it makes the average case incur load cost for the edge case (svg). Open to alternatives that solve these problems; I’ll try expanding tests to include ACF Pro & Download monitor at some point.

GH Issue raised: https://github.com/Lewiscowles1986/WordPressSVGPlugin/issues/6
SO Thread: https://wordpress.stackexchange.com/questions/252143/svg-files-not-uploading-since-most-recent-wp-update/253157#253157

Well, it’s not unfiltered uploads (and I’m definitely not enabling that!), but I did realise my mistake in just whitelisting the SVG MIME type without some kind of sanitising (despite the extreme difficulty of such); henceforth I’ll be using Safe SVG, once the WP core issue is fixed properly.

I’ll try to give your updated plugin a go at some point. For reference, the site the issue was reported on is running PHP 5.4x on nginx; however, my local dev environment is Apache running PHP7, both running the packaged version of GD, and both with the exact same responses.

If I get a chance, I’ll test your plugin with everything else deactivated and see if it makes a difference.

It stopped working for me as well…

Were you able to update it? I don’t see a newer version yet.

Tx!

• This reply was modified 7 years, 10 months ago by callunairis.

Hi All,

Sorry for the delay. I’ve just got back into the country from my holiday, will look at this issue ASAP!

Hi, any news? Did you managed to take a look?

@lewiscowles This has come again with another client. I took the opportunity to try your latest update, but it still didn’t work for me. I even went so far as to disable every other plugin and switch the theme to TwentySeventeen, but the SVG upload still fails with:

Sorry, this file type is not permitted for security reasons.

The site in question had been automatically updated to WP 4.7.2 last night, and I don’t know if there have been any core updates with regard to the SVG/mime issue (I haven’t read the release notes yet). Server specs are the same as above. Tried with multiple SVGs from different sources, just in case, but got the same error every time.

I don’t know what to say; I’ve similarly just updated to 4.7.2; I’m using Twenty Seventeen; I’ve uploaded the latest version of the plugin; I have a number of plugins installed it works…

• ACF to REST API
• Advanced Custom Fields
• Better REST API Featured Images
• SVG Upload
• Transients Manager
• WooCommerce
• WordPress Importer

At this point I can only guess that it’s somehow related to the core GD check, but I have no idea how. I’m totally confused, because I can totally see the logic of how your code works to combat the core image-check problem, but I have no idea how it’s _not_ working for us.

Weirdly enough, I have another, much larger project with a bunch more plugins (including WooCommerce, AWS & S3 CloudFront, ACF, and about 8 completely custom ones)… and SVG uploads work without issue there. I don’t know if that’s to do with one of the other plugins, or my own code (the SVG handling is slightly different, but I don’t know how I could have possibly inadvertently and preemptively ‘fixed’ it).

I’m going to do some more digging and see if I can get to the bottom of this.

I’ve issued a patch as some digging using vagrant led to a weird issue where en_US had the problem but en_GB didn’t. Essentially sometimes for whatever reason (can’t be bothered to dig in more) the debugger shows [‘ext’] is empty, so now we force it and don’t worry about overriding the type any more. Let’s see how long it takes for core team to issue a patch breaking again (it is beginning to feel like malicious intent)

Ha – I never, ever would have thought to look in that direction. I’ve gotten totally wrapped up in another, totally separate core issue that’s killing my dev work right now (https://core.trac.www.ads-software.com/ticket/39722#ticket), but that does make total sense; the ‘bigger’ site is explicitly en_GB, but others are just default en_US installs.

I’ll update again and let you know!