SVG files are not being uploaded to AWS S3

WordPress does not support the SVG mime type to be uploaded to the Media Library, so WP Offload Media does not offload them either.

You’ll need to enable uploading of SVGs to the Media Library, or tell WP Offload Media to offload them regardless.

https://github.com/deliciousbrains/wp-amazon-s3-and-cloudfront-tweaks/blob/96d9fc03ffcfdc1d2e77b0a1a53891e6e1a76e30/amazon-s3-and-cloudfront-tweaks.php#L387

Hi @ianmjones

I had already enabled it to allow me to upload svg in WordPress.
and yesterday I configured the wp-amazon-s3-and-cloudfront-tweaks plugin. But it still doesn’t work. Thats why I thinks is a bug

I configured the plugin in this way:
At amazon-s3-and-cloudfront-tweaks.php
first uncomment line 85
and second on line 387 I added
`
function allowed_mime_types ($ types) {
$ types [‘svg’] = ‘image / svg + xml’;
$ types [‘svgz’] = ‘image / svg + xml’;
$ types [‘doc’] = ‘application / msword’;
$ types [‘json’] = ‘application / json’;
return $ types;
}`

@garcia05mg I think MIME types don’t have any spaces between each portion, so shouldn’t the above instead be:

function allowed_mime_types ( $types ) {
	$types['svg'] = 'image/svg+xml';
	$types['svgz'] = 'image/svg+xml';
	$types['doc'] = 'application/msword';
	$types['json'] = 'application/json';
	return $types;
}

Although if this is just a formatting issue when posting you can disregard this comment.

Even with that change however, you might still run into the same issue I am having. In the most recent update, the function

‘wp_update_attachment_metadata’

aborts attempting to upload files to s3 if no additional resized images are generated when it makes this check (on line 1064 in ‘classes/amazon-s3-and-cloudfront.php’):

// Protect against updates of partially formed metadata.
if ( wp_attachment_is_image( $post_id ) && empty( $data['sizes'] ) ) {
	return $data;
}

You could probably try replacing the above code (again, at line 1064 in ‘classes/amazon-s3-and-cloudfront.php’) with something like this:

// Protect against updates of partially formed metadata.
$mime_type = get_post_mime_type( $post_id );
if ( wp_attachment_is_image( $post_id ) && empty( $data['sizes'] ) && $mime_type != "image/svg+xml" ) {
	return $data;
}

and see if you can upload svg files then.

WP Offload Media Lite 2.3.1 has been released with a fix.

I’ve updated to v.2.3.1 and applied the filter specified in https://github.com/deliciousbrains/wp-amazon-s3-and-cloudfront-tweaks/blob/96d9fc03ffcfdc1d2e77b0a1a53891e6e1a76e30/amazon-s3-and-cloudfront-tweaks.php#L387

svg images are uploaded to my webserver wp-content/uploads/ but aren’t uploaded to s3. So in-turn the image url does not get re-written when viewing the page. All other image formats work as expected.

@ianmjones Yep I have still with the problem.

Thanks for the bug report, I’ve been able to reproduce the problem and will see if I can find a fix.

For WP Offload Media customers reading this, you can still offload the Media Library item with the “Copy to Bucket” row/bulk actions in the Media Library, or the “Offload Remaining” button in WP Offload Media’s settings page.

Unfortunately there’s currently no workaround for WP Offload Media Lite that I can think of.

I was experiencing the same issue across multiple websites I maintain.

After version 2.3.0, WP Offload Media Lite now skips offload for any attachments that do not have a sizes attribute.

https://github.com/deliciousbrains/wp-amazon-s3-and-cloudfront/blob/master/classes/amazon-s3-and-cloudfront.php#L1068

Since SVGs do not have a sizes attribute you can work around this by adding a filter like this that adds a sizes array to SVGs:

add_filter('wp_update_attachment_metadata', function($data, $id){
  if (get_post_mime_type($id) != 'image/svg+xml') return $data;
  $data['sizes'] = [
    'large' => [
      'width'  => 0,
      'height' => 0,
      'file'   => basename(get_attached_file($id))
    ]
  ];
  return $data;
}, 10, 2);

I hope this helps others while @ianmjones finds a fix.

Fixed in WP Offload Media & WP Offload Media Lite 2.3.2.

thank you @ianmjones I can confirm for me – this is now working using 2.3.2

Thank you @ianmjones

this is now working