Support » Plugin: SVG Support » WP 4.7.1 Kills SVG

  • Resolved bpisystems

    (@bpisystems)


    Update the WP install to 4.7.1 yesterday.

    Today, went in to upload a modified SVG file for use on the site. WP is throwing an error stating:

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

    I’ve DELETED the plugin, reinstalled, and tested again with the same results.

    This feels more like an issue brought on by the WP update than with the plugin though I have no way to TS the issue.

    The current SVGs on the site display normally. I used scp to drop in an updated version of an existing file into wp-content. While it displays on the admin side, the page itself fails to display the svg image.

    Hope that helps to narrow down where this might be going sideways.

Viewing 15 replies - 1 through 15 (of 49 total)
  • Plugin Author Benbodhi

    (@benbodhi)

    Hello,

    Thanks for your support and sorry for the inconvenience!

    SVG Support (plugin) has been tested up to 4.8-alpha-39758 as of just now and I do not see this issue.

    Please try deactivating all other plugins and revert to a standard WP theme, then try uploading another SVG file. You should find that it works. Then reactivate everything one by one, testing after each single activation… this will lead you to the conflict.

    If it does not work while using standard WP theme with no other plugins, then the SVG file itself is no good.

    I hope this helps.

    I also installed a clean version of 4.7.1 and my SVG’s are not uploading too.. also with your solution. (Got one in my theme also – maybe the same, but it was worth to give it a try)

    I replicated the same issue. When i turned off all plugins and switched to the 2017 theme the message changed to the following:
    “This file type is not allowed. Please try another.”

    The .svg is fine, as its actually the one im currently using as a logo just fine 😉

    Note: I don’t have the Plugin, core support for svg Upload seems to have been broken by 4.7.1

    • This reply was modified 3 years, 1 month ago by freakpants.
    • This reply was modified 3 years, 1 month ago by freakpants.

    Same here. It’s because they modified wp-includes/functions.php in 4.7.1 and file validations changed (in a more secure way). A workaround for this is:

    1. Edit wp-includes/functions.php
    2. In line 2330 change:

    if ($real_mime !== $type ) {

    for:

    if ($real_mime != ‘image/svg+xml’ && $real_mime !== $type ) {

    Not a nice solution but a workaround while waiting for a real plugin solution (if still possible).

    Thanks for the additions to the issue. Saved me a little effort going through the proposed steps and confirms my suspicions that 4.7.1 broke support for SVG.

    Not sure there’s much you can do on the Plugin side. We may have to wait for an intermediate work-around until 4.7.2 is released.

    Thanks for the bit of code. I’ll roll that out and check the results.

    Plugin Author Benbodhi

    (@benbodhi)

    Hi everyone,

    I have rolled my testing site back to 4.7.1 and have replicated the issue.
    I will look into a workaround.
    Strange, it works fine in 4.8 alphas so I totally missed this version not working.

    Looking into it as we speak. Changing core files is definitely not recommended.

    WP uses a lot of old school (horrifying) bindings, in its PHP 4 like awful code. Plugins interacts with WP by replacing those bindings in most of cases. Don’t lose hope 😛

    Yep, it’s just a workaround to continue working while you find the real solution 🙂 BTW thank you for your work!

    Plugin Author Benbodhi

    (@benbodhi)

    Thanks @shamank, staying hopeful 🙂

    I don’t have any issues with a couple of lines of code and good commenting. It’s easy to roll back if it doesn’t work.

    In this case, it didn’t work. I cleared the browser cache to ensure the new code base was pulled in and the same error was thrown.

    Diff between alpha 4.8 and 4.7.1 might reveal the issue if they haven’t gone hog wild on development changes.

    Just imagine if the entire code base was moved to Phalcon ….

    Found the change that did it (i think):
    https://github.com/WordPress/WordPress/commit/52897df8cdb2ab97f3ebd4c4704e38c1fd684f15

    Apparently exif_imagetype was so far not being used to determine the “real mime” type.
    Considering that http://php.net/manual/en/function.exif-imagetype.php doesnt list SVG, im not surprised actually using that function breaks svg.

    Plugin Author Benbodhi

    (@benbodhi)

    After rolling my test install back to 4.7.1 and then forward again to the latest alpha, it still does not allow upload. I’m scouring their changes to mime type handling in 4.7.1, it looks like they’ve implemented a “real” mime type check to make sure the file is what it says it is about 7 hours ago, so I’m sure I will find a solution soon.

    Since I use GIT to preserve all my sites, including those in WP, I realized what they did. Maybe the Mime header of the file you are uploading is not exactly “image/svg+xml” (mine was). You can force every file by replacing with:

    if (true || $real_mime !== $type ) {

    This is VERY BAD, but it will work in the meanwhile if you are the only one working in your site, or you can inspect the contents of $real_mime and add the exception like I did before.

    FILE DIFF in 4.7.1:

    diff –git a/wp-includes/functions.php b/wp-includes/functions.php
    index 8593e8c..2ae482f 100755
    — a/wp-includes/functions.php
    +++ b/wp-includes/functions.php
    @@ -2254,7 +2254,7 @@ function wp_check_filetype( $filename, $mimes = null ) {
    * If it’s determined that the extension does not match the file’s real type,
    * then the “proper_filename” value will be set with a proper filename and extension.
    *
    – * Currently this function only supports validating images known to getimagesize().
    + * Currently this function only supports renaming images validated via wp_get_image_mime().
    *
    * @since 3.0.0
    *
    @@ -2278,14 +2278,15 @@ function wp_check_filetype_and_ext( $file, $filename, $mimes = null ) {
    return compact( ‘ext’, ‘type’, ‘proper_filename’ );
    }

    – // We’re able to validate images using GD
    – if ( $type && 0 === strpos( $type, ‘image/’ ) && function_exists(‘getimagesize’) ) {
    + // Validate image types.
    + if ( $type && 0 === strpos( $type, ‘image/’ ) ) {

    // Attempt to figure out what type of image it actually is
    – $imgstats = @getimagesize( $file );
    + $real_mime = wp_get_image_mime( $file );

    – // If getimagesize() knows what kind of image it really is and if the real MIME doesn’t match the claimed MIME
    – if ( !empty($imgstats[‘mime’]) && $imgstats[‘mime’] != $type ) {
    + if ( ! $real_mime ) {
    + $type = $ext = false;
    + } elseif ( $real_mime != $type ) {
    /**
    * Filters the list mapping image mime types to their respective extensions.
    *
    @@ -2302,10 +2303,10 @@ function wp_check_filetype_and_ext( $file, $filename, $mimes = null ) {
    ) );

    // Replace whatever is after the last period in the filename with the correct extension
    – if ( ! empty( $mime_to_ext[ $imgstats[‘mime’] ] ) ) {
    + if ( ! empty( $mime_to_ext[ $real_mime ] ) ) {
    $filename_parts = explode( ‘.’, $filename );
    array_pop( $filename_parts );
    – $filename_parts[] = $mime_to_ext[ $imgstats[‘mime’] ];
    + $filename_parts[] = $mime_to_ext[ $real_mime ];
    $new_filename = implode( ‘.’, $filename_parts );

    if ( $new_filename != $filename ) {
    @@ -2315,8 +2316,20 @@ function wp_check_filetype_and_ext( $file, $filename, $mimes = null ) {
    $wp_filetype = wp_check_filetype( $new_filename, $mimes );
    $ext = $wp_filetype[‘ext’];
    $type = $wp_filetype[‘type’];
    + } else {
    + $type = $ext = false;
    }
    }
    + } elseif ( function_exists( ‘finfo_file’ ) ) {
    + // Use finfo_file if available to validate non-image files.
    + $finfo = finfo_open( FILEINFO_MIME_TYPE );
    + $real_mime = finfo_file( $finfo, $file );
    + finfo_close( $finfo );
    +
    + // If the extension does not match the file’s real type, return false.
    + if ($real_mime != ‘image/svg+xml’ && $real_mime !== $type ) {
    + $type = $ext = false;
    + }
    }

    /**
    @@ -2335,6 +2348,38 @@ function wp_check_filetype_and_ext( $file, $filename, $mimes = null ) {
    }

    /**
    + * Returns the real mime type of an image file.
    + *
    + * This depends on exif_imagetype() or getimagesize() to determine real mime types.
    + *
    + * @since 4.7.1
    + *
    + * @param string $file Full path to the file.
    + * @return string|false The actual mime type or false if the type cannot be determined.
    + */
    +function wp_get_image_mime( $file ) {
    + /*
    + * Use exif_imagetype() to check the mimetype if available or fall back to
    + * getimagesize() if exif isn’t avaialbe. If either function throws an Exception
    + * we assume the file could not be validated.
    + */
    + try {
    + if ( is_callable( ‘exif_imagetype’ ) ) {
    + $mime = image_type_to_mime_type( exif_imagetype( $file ) );
    + } elseif ( function_exists( ‘getimagesize’ ) ) {
    + $imagesize = getimagesize( $file );
    + $mime = ( isset( $imagesize[‘mime’] ) ) ? $imagesize[‘mime’] : false;
    + } else {
    + $mime = false;
    + }
    + } catch ( Exception $e ) {
    + $mime = false;
    + }
    +
    + return $mime;
    +}
    +
    +/**
    * Retrieve list of mime types and file extensions.
    *
    * @since 3.5.0

    Problem is actually this line:

    $mime = image_type_to_mime_type( exif_imagetype( $file ) );

    exif_imagetype for svg returns false (since it doesnt support svg). image_type_to_mime_type then also returns false.

Viewing 15 replies - 1 through 15 (of 49 total)
  • The topic ‘WP 4.7.1 Kills SVG’ is closed to new replies.