Code Monkey home page Code Monkey logo

safe-svg's Introduction

Safe SVG

Enable SVG uploads and sanitize them to stop XML/SVG vulnerabilities in your WordPress website.

Support Level Release Version WordPress tested up to version GPL-2.0-or-later License Dependency Review E2E test PHP Compatibility PHPCS PHPUnit

Overview

Safe SVG is the best way to Allow SVG Uploads in WordPress!

It gives you the ability to allow SVG uploads whilst making sure that they're sanitized to stop SVG/XML vulnerabilities affecting your site. It also gives you the ability to preview your uploaded SVGs in the media library in all views.

Current Features

  • Sanitised SVGs - Don't open up security holes in your WordPress site by allowing uploads of unsanitised files.
  • SVGO Optimisation - Runs your SVGs through the SVGO tool on upload to save you space. This feature is disabled by default but can be enabled by adding the following code: add_filter( 'safe_svg_optimizer_enabled', '__return_true' );
  • View SVGs in the Media Library - Gone are the days of guessing which SVG is the correct one, we'll enable SVG previews in the WordPress media library.
  • Choose Who Can Upload - Restrict SVG uploads to certain users on your WordPress site or allow anyone to upload.

Initially a proof of concept for #24251.

SVG Sanitization is done through the following library: https://github.com/darylldoyle/svg-sanitizer.

SVG Optimization is done through the following library: https://github.com/svg/svgo.

Requirements

Installation

Install through the WordPress directory or download, unzip and upload the files to your /wp-content/plugins/ directory.

Frequently Asked Questions

Can we change the allowed attributes and tags?

Yes, this can be done using the svg_allowed_attributes and svg_allowed_tags filters. They take one argument that must be returned. See below for examples:

add_filter( 'svg_allowed_attributes', function ( $attributes ) {

    // Do what you want here...

    // This should return an array so add your attributes to
    // to the $attributes array before returning it. E.G.

    $attributes[] = 'target'; // This would allow the target="" attribute.

    return $attributes;
} );


add_filter( 'svg_allowed_tags', function ( $tags ) {

    // Do what you want here...

    // This should return an array so add your tags to
    // to the $tags array before returning it. E.G.

    $tags[] = 'use'; // This would allow the <use> element.

    return $tags;
} );

Support Level

Stable: 10up is not planning to develop any new features for this, but will still respond to bug reports and security concerns. We welcome PRs, but any that include new features should be small and easy to integrate and should not include breaking changes. We otherwise intend to keep this tested up to the most recent version of WordPress.

Changelog

A complete listing of all notable changes to Safe SVG are documented in CHANGELOG.md.

Contributing

Please read CODE_OF_CONDUCT.md for details on our code of conduct, CONTRIBUTING.md for details on the process for submitting pull requests to us, and CREDITS.md for a listing of maintainers of, contributors to, and libraries used by Safe SVG.

Like what you see?

Work with us at 10up

safe-svg's People

Contributors

bmarshall511 avatar cadic avatar darylldoyle avatar dependabot[bot] avatar dhanendran avatar dkotter avatar fabiankaegy avatar faisal-alvi avatar ggutenberg avatar gsarig avatar iamdharmesh avatar jayedul avatar jeffpaul avatar joehoyle avatar kadamwhite avatar kmgalanakis avatar mallardduck avatar mehidi258 avatar mehulkaklotar avatar peterwilsoncc avatar psorensen avatar ravinderk avatar roborourke avatar sdmtt avatar sidsector9 avatar sksaju avatar szepeviktor avatar tobeycodes avatar zamanq avatar zodiac1978 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

safe-svg's Issues

Run E2E tests on the zip generated by "Build release zip" action.

Is your enhancement related to a problem? Please describe.

We are currently running E2E tests by installing dependencies and building plugin files. This is not the most accurate plugin build that will be shipped during the release. To make E2E tests more accurate and match the plugin build with the release build generated by our deploy action, we should generate a plugin build with the "build zip" action. Running E2E tests on this build will give us more accurate results.

PR for reference: 10up/autoshare-for-twitter#206

Designs

No response

Describe alternatives you've considered

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct

Optimise already uploaded SVG images

Is your enhancement related to a problem? Please describe.

Optimize existing SVGs when someone triggers a batch regenerate of images, with WP-CLI or a third-party plugin. That way we wouldn't have to build a settings page for that, or a specific mechanism from scratch and the implementation should be quicker.
The challenge with the optimizer is that being a JS tool, it cannot utilize the standard PHP hooks so it would take some testing/investigation to see how this could best work.

For more context refer: #79

Designs

No response

Describe alternatives you've considered

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct

Undefined variable: viewbox_width in safe-svg.php#L507

Describe the bug

Today I imported a large about of files and SVG's from a prod-site to a local-site.
During that process the plugin gave some warnings. Most of them where:

Notice: Undefined variable: viewbox_width in /Users/username/local-sites/domain/app/public/wp-content/plugins/safe-svg/safe-svg.php on line 507

safe-svg.php#L507

Steps to Reproduce

Unknown. I assume it's because one or more svg's is missing a viewbox attribute.

Screenshots, screen recording, code snippet

Screenshot 2022-04-13 at 15 28 36(private information obfuscated)

safe-svg.php#L507

Environment information

Device: MacBook Pro M1
OS: macOS Monterey 12.3.1
Browser: Chrome 100.0.4896.75 (Official Build) (arm64)

WordPress information

`

wp-core

version: 5.9.3
site_language: nl_NL
user_language: nl_NL
timezone: Europe/Amsterdam
permalink: /%postname%/
https_status: true
multisite: false
user_registration: 0
blog_public: 1
default_comment_status: undefined
environment_type: production
user_count: 6
dotorg_communication: true

wp-paths-sizes

wordpress_path: /home/customer/www/domain.tld/public_html
wordpress_size: 52,16 MB (54696619 bytes)
uploads_path: /home/customer/www/domain.tld/public_html/wp-content/uploads
uploads_size: 266,52 MB (279462198 bytes)
themes_path: /home/customer/www/domain.tld/public_html/wp-content/themes
themes_size: 118,94 MB (124716088 bytes)
plugins_path: /home/customer/www/domain.tld/public_html/wp-content/plugins
plugins_size: 79,97 MB (83857959 bytes)
database_size: 41,70 MB (43728896 bytes)
total_size: 559,29 MB (586461760 bytes)

wp-active-theme

name: PRIVATE/OBFUSCATED
version: 1.0.3
author: Pronamic
author_website: https://www.pronamic.eu/
parent_theme: none
theme_features: core-block-patterns, block-templates, widgets-block-editor, automatic-feed-links, html5, title-tag, custom-logo, align-wide, menus, post-thumbnails, editor-style, widgets
theme_path: /home/customer/www/domain.tld/public_html/wp-content/themes/theme
auto_update: Uitgeschakeld

wp-themes-inactive (2)

Twenty Twenty-One: version: 1.5, author: the WordPress team, Auto-updates uitgeschakeld
WedWiki: version: 1.0.79, author: Pronamic, Auto-updates uitgeschakeld

wp-mu-plugins (1)

InfiniteWP - Client Loader: author: Revmakx, version: (undefined)

wp-plugins-active (15)

ACF Content Analysis for Yoast SEO: version: 3.0.1, author: Thomas Krรคftner, ViktorFroberg, marol87, pekz0r, angrycreative, Team Yoast, Auto-updates uitgeschakeld
Advanced Custom Fields PRO: version: 5.12.2, author: Delicious Brains, Auto-updates uitgeschakeld
Akismet Anti-Spam: version: 4.2.2, author: Automattic, Auto-updates uitgeschakeld
Gravity Forms: version: 2.6.1, author: Gravity Forms, Auto-updates uitgeschakeld
InfiniteWP - Client: version: 1.9.6, author: Revmakx, Auto-updates uitgeschakeld
Members: version: 3.1.7, author: MemberPress, Auto-updates uitgeschakeld
Post Types Order: version: 1.9.8, author: Nsp Code, Auto-updates uitgeschakeld
Pretty Links: version: 3.2.4, author: Pretty Links, Auto-updates uitgeschakeld
Pronamic Client: version: 1.9.4, author: Pronamic, Auto-updates uitgeschakeld
SiteGround Optimizer: version: 7.0.9, author: SiteGround, Auto-updates uitgeschakeld
SiteGround Security: version: 1.2.7, author: SiteGround, Auto-updates uitgeschakeld
SVG Support: version: 2.4.2, author: Benbodhi, Auto-updates uitgeschakeld
User Switching: version: 1.5.8, author: John Blackbourn & contributors, Auto-updates uitgeschakeld
Yoast SEO: version: 18.5.1, author: Team Yoast, Auto-updates uitgeschakeld
Yoast SEO Premium: version: 18.3, author: Team Yoast, Auto-updates uitgeschakeld

wp-plugins-inactive (1)

Casino Features: version: 1.0.0, author: Author Name, Auto-updates uitgeschakeld

wp-media

image_editor: WP_Image_Editor_GD
imagick_module_version: Niet beschikbaar
imagemagick_version: Niet beschikbaar
imagick_version: Niet beschikbaar
file_uploads: File uploads is turned off
post_max_size: 256M
upload_max_filesize: 256M
max_effective_size: 256 MB
max_file_uploads: 20
gd_version: 2.2.5
gd_formats: GIF, JPEG, PNG, WebP, BMP, XPM
ghostscript_version: 9.27

wp-server

server_architecture: Linux 3.12.18-clouder0 x86_64
httpd_software: Apache
php_version: 7.4.28 64bit
php_sapi: cgi-fcgi
max_input_variables: 3000
time_limit: 120
memory_limit: 768M
max_input_time: 120
upload_max_filesize: 256M
php_post_max_size: 256M
curl_version: 7.66.0 OpenSSL/1.1.1n-fips
suhosin: false
imagick_availability: false
pretty_permalinks: true
htaccess_extra_rules: true

wp-database

extension: mysqli
server_version: 5.7.32-35-log
client_version: mysqlnd 7.4.28
max_allowed_packet: 33554432
max_connections: 500

wp-constants

WP_HOME: undefined
WP_SITEURL: undefined
WP_CONTENT_DIR: /home/customer/www/domain.tld/public_html/wp-content
WP_PLUGIN_DIR: /home/customer/www/domain.tld/public_html/wp-content/plugins
WP_MEMORY_LIMIT: 40M
WP_MAX_MEMORY_LIMIT: 768M
WP_DEBUG: false
WP_DEBUG_DISPLAY: true
WP_DEBUG_LOG: false
SCRIPT_DEBUG: false
WP_CACHE: false
CONCATENATE_SCRIPTS: undefined
COMPRESS_SCRIPTS: undefined
COMPRESS_CSS: undefined
WP_ENVIRONMENT_TYPE: Ongedefinieerd
DB_CHARSET: utf8
DB_COLLATE: undefined

wp-filesystem

wordpress: writable
wp-content: writable
uploads: writable
plugins: writable
themes: writable
mu-plugins: writable

`

Code of Conduct

  • I agree to follow this project's Code of Conduct

Future plans for composer package

Hey, great to see 10up taking on maintenance here! I was wondering what if any plans you might have for the future in terms of this plugin being on packagist.org. Will you be updating the name and resubmitting?

Also I noticed that 1.9.10 seems like it shouldn't really be a patch release if there are breaking changes with regards to WP and PHP version support. Not suggesting removing that tag of course but wanted to note it could cause problems for people using a loose enough version constraint.

Release version 2.0.1

Describe your question

This issue is for tracking changes for the 2.0.1 release. Target release date: 19 April 2022.

Release steps

  • Branch: Starting from develop, cut a release branch named release/2.0.1 for your changes.
  • Version bump: Bump the version number in readme.txt and safe-svg.php if it does not already reflect the version being released.
  • Changelog: Add/update the changelog in CHANGELOG.md and readme.txt.
  • Props: Update CREDITS.md with any new contributors, confirm maintainers are accurate.
  • New files: Check to be sure any new files/paths that are unnecessary in the production version are included in .distignore.
  • Readme updates: Make any other readme changes as necessary. README.md is geared toward GitHub and readme.txt contains WordPress.org-specific content. The two are slightly different.
  • Merge: Make a non-fast-forward merge from your release branch to develop (or merge the Pull Request), then do the same for develop into trunk (git checkout trunk && git merge --no-ff develop). trunk contains the stable development version.
  • Test: While still on the trunk branch, test for functionality locally.
  • Push: Push your trunk branch to GitHub (e.g. git push origin trunk).
  • Release: Create a new release, naming the tag and the release with the new version number, and targeting the trunk branch. Paste the changelog from CHANGELOG.md into the body of the release and include a link to the closed issues on the milestone. The release should now appear under releases.
  • SVN: Wait for the GitHub Action to finish deploying to the WordPress.org repository. If all goes well, users with SVN commit access for that plugin will receive an emailed diff of changes.
  • Check WordPress.org: Ensure that the changes are live on https://wordpress.org/plugins/safe-svg/. This may take a few minutes.
  • Close milestone: Edit the milestone with release date (in the Due date (optional) field) and link to GitHub release (in the Description field), then close the milestone.
  • Punt incomplete items: If any open issues or PRs which were milestoned for 2.0.1 do not make it into the release, update their milestone to 2.1.0 or Future Release.

Code of Conduct

  • I agree to follow this project's Code of Conduct

Add a GH Actions summary

Is your enhancement related to a problem? Please describe.

Update the plugin to use the GH Actions Report summary used in 10up/cypress-wp-utils#63. It's a very nice presentation of the test results.

Designs

No response

Describe alternatives you've considered

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct

Request: Filter to disable SVG block registration

Is your enhancement related to a problem? Please describe.

Thanks for the excellent plugin. I was wondering if it'd be possible to get a filter to disable registration of the SVG block and category? The simplicity of the plugin is one of it's most attractive features.

Also, it might be worth a separate bug report, but the block registration as-is is enqueueing the frontend assets on every page of my site despite not using the block. Not sure if you're able to reproduce?

Designs

No response

Describe alternatives you've considered

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct

HTTP 500 error in combination with Gutenberg plugin when website logo is an SVG file with custom dimensions

Describe the bug

With activated Gutenberg plugin, when an SVG file is selected as the website logo AND the size of it is altered (effectively: once it is set to an explicit value) in the block's options, the website fails to load but only shows an HTTP 500 error instead.

Steps to Reproduce

  1. Use a block-theme (I guess any block theme; i could reproduce with twenty twenty-two).
  2. In the full page editor (Gutenberg), choose an SVG file as the website logo.
  3. Set a custom image width in the block options of the logo.
  4. Save the theme.
  5. Navigate to the website.
  6. An error message will appear.

Expected behavior

The page should display without error.

Screenshots

grafik

Environment information

  • Device: PC with Linux
  • OS: Gentoo Linux
  • Browser and version: Mozilla FIrefox 95.0.1 (64-bit)

WordPress information

Site Health info: ` ### wp-core ###

version: 5.9-beta4-52422
site_language: de_CH_informal
user_language: de_CH_informal
timezone: Europe/Berlin
permalink: /%year%/%monthnum%/%day%/%postname%/
https_status: false
multisite: false
user_registration: 0
blog_public: 0
default_comment_status: open
environment_type: production
user_count: 1
dotorg_communication: true

wp-paths-sizes

wordpress_path: /home/manuel/public_html/wordpress-beta
wordpress_size: 49.20 MB (51591651 bytes)
uploads_path: /home/manuel/public_html/wordpress-beta/wp-content/uploads
uploads_size: 50.72 kB (51937 bytes)
themes_path: /home/manuel/public_html/wordpress-beta/wp-content/themes
themes_size: 31.04 MB (32552997 bytes)
plugins_path: /home/manuel/public_html/wordpress-beta/wp-content/plugins
plugins_size: 18.80 MB (19713278 bytes)
database_size: 3.92 MB (4112384 bytes)
total_size: 103.02 MB (108022247 bytes)

wp-active-theme

name: Twenty Twenty-Two (twentytwentytwo)
version: 1.0
author: the WordPress team
author_website: https://wordpress.org/
parent_theme: none
theme_features: core-block-patterns, widgets-block-editor, post-thumbnails, responsive-embeds, editor-styles, html5, automatic-feed-links, block-templates, wp-block-styles, editor-style
theme_path: /home/manuel/public_html/wordpress-beta/wp-content/themes/twentytwentytwo
auto_update: Deaktiviert

wp-themes-inactive (12)

empowerment: version: 0.0.1-dev, author: Manuel Friedli, Automatische Aktualisierungen deaktiviert
Twenty Eleven: version: 3.9, author: the WordPress team, Automatische Aktualisierungen deaktiviert
Twenty Fifteen: version: 3.0, author: the WordPress team, Automatische Aktualisierungen deaktiviert
Twenty Fourteen: version: 3.2, author: the WordPress team, Automatische Aktualisierungen deaktiviert
Twenty Nineteen: version: 2.1, author: WordPress-Team, Automatische Aktualisierungen deaktiviert
Twenty Seventeen: version: 2.8, author: dem WordPress-Team, Automatische Aktualisierungen deaktiviert
Twenty Sixteen: version: 2.5, author: the WordPress team, Automatische Aktualisierungen deaktiviert
Twenty Ten: version: 3.5, author: the WordPress team, Automatische Aktualisierungen deaktiviert
Twenty Thirteen: version: 3.4, author: the WordPress team, Automatische Aktualisierungen deaktiviert
Twenty Twelve: version: 3.5, author: the WordPress team, Automatische Aktualisierungen deaktiviert
Twenty Twenty: version: 1.8, author: WordPress-Team, Automatische Aktualisierungen deaktiviert
Twenty Twenty-One: version: 1.4, author: the WordPress team, Automatische Aktualisierungen deaktiviert

wp-plugins-active (2)

Gutenberg: version: 12.2.0, author: Gutenberg Team, Automatische Aktualisierungen aktiviert
Safe SVG: version: 1.9.9, author: Daryll Doyle, Automatische Aktualisierungen aktiviert

wp-plugins-inactive (1)

Akismet Anti-Spam: version: 4.2.1, author: Automattic, Automatische Aktualisierungen aktiviert

wp-media

image_editor: WP_Image_Editor_GD
imagick_module_version: Nicht verfรผgbar
imagemagick_version: Nicht verfรผgbar
imagick_version: Nicht verfรผgbar
file_uploads: File uploads is turned off
post_max_size: 8M
upload_max_filesize: 2M
max_effective_size: 2 MB
max_file_uploads: 20
gd_version: bundled (2.1.0 compatible)
gd_formats: GIF, JPEG, PNG, BMP
ghostscript_version: 9.55.0

wp-server

server_architecture: Linux 5.15.11-gentoo x86_64
httpd_software: Apache
php_version: 8.0.12 64bit
php_sapi: apache2handler
max_input_variables: 1000
time_limit: 30
memory_limit: 128M
admin_memory_limit: 256M
max_input_time: 60
upload_max_filesize: 2M
php_post_max_size: 8M
curl_version: 7.79.1 OpenSSL/1.1.1l
suhosin: false
imagick_availability: false
pretty_permalinks: true
htaccess_extra_rules: false

wp-database

extension: mysqli
server_version: 10.5.10-MariaDB-log
client_version: mysqlnd 8.0.12
max_allowed_packet: 16777216
max_connections: 151

wp-constants

WP_HOME: undefined
WP_SITEURL: undefined
WP_CONTENT_DIR: /home/manuel/public_html/wordpress-beta/wp-content
WP_PLUGIN_DIR: /home/manuel/public_html/wordpress-beta/wp-content/plugins
WP_MEMORY_LIMIT: 40M
WP_MAX_MEMORY_LIMIT: 256M
WP_DEBUG: false
WP_DEBUG_DISPLAY: true
WP_DEBUG_LOG: false
SCRIPT_DEBUG: false
WP_CACHE: false
CONCATENATE_SCRIPTS: undefined
COMPRESS_SCRIPTS: undefined
COMPRESS_CSS: undefined
WP_ENVIRONMENT_TYPE: Nicht definiert
DB_CHARSET: utf8mb4
DB_COLLATE: undefined

wp-filesystem

wordpress: writable
wp-content: writable
uploads: writable
plugins: writable
themes: writable

`

Additional context

PHP error log:
[Fri Dec 31 00:56:41.903692 2021] [php:error] [pid 4376] [client 127.0.0.1:48564] PHP Fatal error:  Uncaught DivisionByZeroError: Division by zero in /home/manuel/public_html/wordpress-beta/wp-content/plugins/gutenberg/build/block-library/blocks/site-logo.php:20
Stack trace:
#0 /home/manuel/public_html/wordpress-beta/wp-includes/class-wp-hook.php(309): {closure}()
#1 /home/manuel/public_html/wordpress-beta/wp-includes/plugin.php(189): WP_Hook->apply_filters()
#2 /home/manuel/public_html/wordpress-beta/wp-includes/media.php(992): apply_filters()
#3 /home/manuel/public_html/wordpress-beta/wp-includes/media.php(1029): wp_get_attachment_image_src()
#4 /home/manuel/public_html/wordpress-beta/wp-includes/general-template.php(1093): wp_get_attachment_image()
#5 /home/manuel/public_html/wordpress-beta/wp-content/plugins/gutenberg/build/block-library/blocks/site-logo.php(26): get_custom_logo()
#6 /home/manuel/public_html/wordpress-beta/wp-content/plugins/gutenberg/lib/compat.php(132): gutenberg_render_block_core_site_logo()
#7 /home/manuel/public_html/wordpress-beta/wp-includes/class-wp-block.php(255): {closure}()
#8 /home/manuel/public_html/wordpress-beta/wp-includes/class-wp-block.php(241): WP_Block->render()
#9 /home/manuel/public_html/wordpress-beta/wp-includes/class-wp-block.php(241): WP_Block->render()
#10 /home/manuel/public_html/wordpress-beta/wp-includes/class-wp-block.php(241): WP_Block->render()
#11 /home/manuel/public_html/wordpress-beta/wp-includes/blocks.php(883): WP_Block->render()
#12 /home/manuel/public_html/wordpress-beta/wp-includes/blocks.php(921): render_block()
#13 /home/manuel/public_html/wordpress-beta/wp-content/plugins/gutenberg/build/block-library/blocks/template-part.php(132): do_blocks()
#14 /home/manuel/public_html/wordpress-beta/wp-content/plugins/gutenberg/lib/compat.php(132): gutenberg_render_block_core_template_part()
#15 /home/manuel/public_html/wordpress-beta/wp-includes/class-wp-block.php(255): {closure}()
#16 /home/manuel/public_html/wordpress-beta/wp-includes/class-wp-block.php(241): WP_Block->render()
#17 /home/manuel/public_html/wordpress-beta/wp-includes/class-wp-block.php(241): WP_Block->render()
#18 /home/manuel/public_html/wordpress-beta/wp-includes/blocks.php(883): WP_Block->render()
#19 /home/manuel/public_html/wordpress-beta/wp-includes/blocks.php(921): render_block()
#20 /home/manuel/public_html/wordpress-beta/wp-content/plugins/gutenberg/build/block-library/blocks/template-part.php(132): do_blocks()
#21 /home/manuel/public_html/wordpress-beta/wp-content/plugins/gutenberg/lib/compat.php(132): gutenberg_render_block_core_template_part()
#22 /home/manuel/public_html/wordpress-beta/wp-includes/class-wp-block.php(255): {closure}()
#23 /home/manuel/public_html/wordpress-beta/wp-includes/blocks.php(883): WP_Block->render()
#24 /home/manuel/public_html/wordpress-beta/wp-includes/blocks.php(921): render_block()
#25 /home/manuel/public_html/wordpress-beta/wp-content/plugins/gutenberg/lib/compat/wordpress-5.9/block-template.php(217): do_blocks()
#26 /home/manuel/public_html/wordpress-beta/wp-content/plugins/gutenberg/lib/compat/wordpress-5.9/template-canvas.php(12): gutenberg_get_the_template_html()
#27 /home/manuel/public_html/wordpress-beta/wp-includes/template-loader.php(106): include('...')
#28 /home/manuel/public_html/wordpress-beta/wp-blog-header.php(19): require_once('...')
#29 /home/manuel/public_html/wordpress-beta/index.php(17): require('...')
#30 {main}
  thrown in /home/manuel/public_html/wordpress-beta/wp-content/plugins/gutenberg/build/block-library/blocks/site-logo.php on line 20

The problem lies in the Gutenberg plugin, in the following code (gutenberg/build/block-library/blocks/site-logo.php, lines 15ff.):

function gutenberg_render_block_core_site_logo( $attributes ) {
        $adjust_width_height_filter = function ( $image ) use ( $attributes ) {
                if ( empty( $attributes['width'] ) || empty( $image ) ) {
                        return $image;
                }
                $height = (float) $attributes['width'] / ( (float) $image[1] / (float) $image[2] );
                return array( $image[0], (int) $attributes['width'], (int) $height );
        };

        add_filter( 'wp_get_attachment_image_src', $adjust_width_height_filter );

        $custom_logo = get_custom_logo();

        remove_filter( 'wp_get_attachment_image_src', $adjust_width_height_filter );

Apparently, $image[1] and $image[2] are both unset (or false), which results in a division by zero, but only if the width was manually altered (and therefore $attributes['width'] is not empty.

They get set to false by the Safe SVG plugin (safe-svg/safe-svg.php, lines 226ff.):

        /**
         * Filters the image src result.
         * Here we're gonna spoof the image size and set it to 100 width and height
         *
         * @param array|false $image Either array with src, width & height, icon src, or false.
         * @param int $attachment_id Image attachment ID.
         * @param string|array $size Size of image. Image size or array of width and height values
         *                                    (in that order). Default 'thumbnail'.
         * @param bool $icon Whether the image should be treated as an icon. Default false.
         *
         * @return array
         */
        public function one_pixel_fix( $image, $attachment_id, $size, $icon ) {
            if ( get_post_mime_type( $attachment_id ) == 'image/svg+xml' ) {
                $image['1'] = false;
                $image['2'] = false;
            }

            return $image;
        }

A trivial fix would be to set $image[1] and $image[2] to 100 instead of false, but I have no idea what (possibly negative) side effects that could cause.
I guess it also depends on the order in which the filters are registered (gutenberg-first vs. safe-svg-first).
Lastly, a fix could also be made in the Gutenberg plugin: only perform the calculation if $image[1] and $image[2] are both set to non-zero numerical values. But I assume it is very unusual for these values to be 0 in the first place, so I wouldn't count on the Gutenberg developers to be overly enthusiastic about implementing such a fix in their plugin.

Setup Cypress for E2E testing

Is your enhancement related to a problem? Please describe.

See overall concept in the OSBP guide and example setups on Simple Podcasting, Restricted Site Access, and 10up/ElasticPress#2446.

Describe the solution you'd like

  • add base GitHub Action
  • add .wp-env.json
  • add base docker files
  • update package.json / package lock files
  • add cypress tests
  • remove any WP Acceptance components

Designs

n/a

Describe alternatives you've considered

n/a

Additional context

https://github.com/10up/cypress-wp-setup/ && https://github.com/10up/cypress-wp-utils will be helpful in getting this spun up and some initial test commands to leverage.

Meta flood for zero-sizes

Describe the bug

The easiest way to remove thumbnail generation of a image size is to set the width and height to 0.
This is an example of wp_get_additional_image_sizes() values:

array (
  '1536x1536' => 
  array (
    'width' => 0,
    'height' => 0,
    'crop' => 0,
  ),
  '2048x2048' => 
  array (
    'width' => 0,
    'height' => 0,
    'crop' => 0,
  ),
  'medium_large' => 
  array (
    'width' => 0,
    'height' => 0,
    'crop' => 0,
  ),
  'woocommerce_gallery_thumbnail' => 
  array (
    'width' => 0,
    'height' => 0,
    'crop' => 0,
  ),
  'shop_catalog' => 
  array (
    'width' => 0,
    'height' => 0,
    'crop' => 0,
  ),
  'shop_single' => 
  array (
    'width' => 0,
    'height' => 0,
    'crop' => 0,
  ),
  'shop_thumbnail' => 
  array (
    'width' => 0,
    'height' => 0,
    'crop' => 0,
  ),
);

WordPress skips generation of such thumbnails. The plugin generates thumbnail metadata, where width and height can be 0.

This behavior results in unexpected behavior when using thumbnails. For example, structured data generation plugins can use zero-sizes for thumbnails.

This behavior is related #23

Steps to Reproduce

  1. Disable image size by simply step:
	add_image_size( 'medium_large', 0, 0, 0 );
  1. Upload the SVG image
  2. See generated metadata for attachment

Screenshots, screen recording, code snippet

No response

Environment information

No response

WordPress information

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct

Remove plugin page "Upgrade" action link

Is your enhancement related to a problem? Please describe.

The Upgrade action link on the WordPress plugins page links here: https://wpsvg.com/?utm_source=plugin-list&utm_medium=upgrade-link&utm_campaign=plugin-list&utm_content=action-link

According to that page:

My spare time is completely full at the moment and as such WP SVG is no longer on sale to the public. Those with current licences can continue to use it and will be supported, but no new licences will be sold for the time being.

Since it's no longer for sale you don't need an Upgrade link.

Designs

N/A

Describe alternatives you've considered

N/A

Code of Conduct

  • I agree to follow this project's Code of Conduct

Safe-SVG v2.1.0 should not enqueue frontend stylesheet and JavaScript if Gutenberg block is not used

Is your enhancement related to a problem? Please describe.

The new version 2.1.0, which adds a Gutenberg block, enqueues the following files in the frontend of the website, even if this block is not used:

  • safe-svg-block-frontend.css
  • safe-svg-block-frontend.js

This is also mentioned in #80 (comment)

The JS file is even empty (!). As a web agency focused on the performance of our websites, we keep an eye on every single CSS and JS file loaded in the frontend. Please do not enqueue CSS and JS files for unused functionality. Especially in a plugin, which previously only provided backend functionality (and we will still only use it for that).

Right now we have to add the following code to all of our websites using this plugin to dequeue these assets:

wp_dequeue_style('safe-svg-block-frontend');
wp_deregister_script('safe-svg-block-script');

Designs

No response

Describe alternatives you've considered

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct

Add PHPCS and PHP8 Compatibility.

Is your enhancement related to a problem? Please describe.

Add PHPCS and PHP8 Compatibility

Designs

No response

Describe alternatives you've considered

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct

Test against WordPress 5.8

Is your enhancement related to a problem? Please describe.
Now that WordPress 5.8 is released, we'll want to test Safe SVG to see if any incompatibility issues arise.

Describe the solution you'd like

  • test Safe SVG on WordPress 5.8
  • open issues for any incompatibilities noted in testing
  • resolve issues identified in testing
  • bump "tested up to" version
  • if code changes needed due to incompatibilities, ship a plugin release, otherwise use "Plugin asset/readme update" action to update "tested up to" version on .org repo

Designs
n/a

Describe alternatives you've considered
none

Additional context
none

Consider adding an inline SVG Gutenberg block

Is your enhancement related to a problem? Please describe.

Attempting to add an SVG onto a page/post with the image block presents all sorts of issues. The core image block expects images to have an intrinsic size even without width & height attributes, as the block uses an extra wrapper div to set the width/height in the editor. This situation leads to all sorts of weirdness with the size of the SVG in the editor vs the front end, as well as often making the image disappear if you select an alignment, or even just remove focus from the block.

Image block with no settings changed, no alignment, selected:
Screen Shot 2022-01-13 at 3 36 08 PM

Same as above, block no longer selected:
Screen Shot 2022-01-13 at 3 36 47 PM

Block set to align center makes image 0 width again:
Screen Shot 2022-01-13 at 3 38 18 PM

On the front end, with no alignment set, the width and height attributes are added, which is a different width than the default width while block is selected from screenshot number 1 above.
Screen Shot 2022-01-13 at 3 39 47 PM

Describe the solution you'd like

As the image block seems to be fundamentally unable to handle SVG images, and only with this plugin can you upload SVGs anyways, I propose that the plugin include a custom block for outputting an SVG markup directly.

In places that aren't the block editor, we've used this plugin to allow for SVG uploads and then output the markup in theme code, but we don't have a way of doing that without creating a custom block anyways.

Designs

Describe alternatives you've considered

If it's possible to add support for handling the SVG in the core image block better, perhaps that would be a better route, but I'm not sure if that is feasible and maintainable.

Additional context

Cannot set SVG as Logo with WP Customizer

Hello there,

I've setup this plugin on a site in order to enable SVG images as the site logo. Upon attempting to set the logo as an SVG in the customizer I wasn't seeing the 'Skip Crop' button and the 'Crop' button fails with an error.

The crop button failing is expected - fully understand that WP won't have the brains to crop an SVG image. However I would totally expect to see a "Skip Crop" button for SVG images and if possible disable the "Crop" button.

I've managed to pull together some changes that allows the "Skip Crop" button to be visible and functional for setting site logo. I'll shoot over a PR with those changes.

Best,
Dan

Save Image Metadata

Is there any reason why you skip the wp_generate_attachment_metadata filter?
It seems like it would be a sensible place to get the width and height of the svg and set it as metadata to the image?

You could then remove get_image_tag and wp_get_attachment_image_attributes entirely.
You could also remove the call to svg_dimensions in the wp_prepare_attachment_for_js filter.

It seems to be a massive performance hit to re-open and parse the svg file every time, instead as saving it as a built-in media metadata.

I can prepare a PR if interested.

Extra space in Featured Image

Describe the bug

When adding an SVG as a Featured Image, there is extra padding that appears above the featured image.

This seems to be related to some CSS that is added to this plugin.

Steps to Reproduce

  1. Go to any page.
  2. Add an SVG as a Featured Image
  3. Note the extra space.

Screenshots, screen recording, code snippet

Without the plugin enabled:
Screen Shot 2022-05-17 at 8 58 09 AM

With the plugin enabled:
Screen Shot 2022-05-17 at 8 57 39 AM

The problematic code in question:

/**
 * Fix for Gutenberg not showing featured images correctly.
 */
img.components-responsive-wrapper__content[src$=".svg"] {
    position: relative;
}

Environment information

  • WordPress 5.9.3
  • Chrome 101.0.4951.64

WordPress information

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct

Update Support Level from Active to Stable

Is your enhancement related to a problem? Please describe.

Once the following are completed:

  • #68
  • #69
  • review old wpsvg "pro" repo for any other functionality to port into free plugin

... we can then work to update the support level for this plugin from Active to Stable as we can generally consider the optimal feature set of the plugin complete. Tasks to complete this change:

Designs

n/a

Describe alternatives you've considered

n/a

Code of Conduct

  • I agree to follow this project's Code of Conduct

Test against WordPress 5.9

Is your enhancement related to a problem? Please describe.
Now that WordPress 5.9 is released, we'll want to test Safe SVG to see if any incompatibility issues arise.

Describe the solution you'd like

  • test Safe SVG on WordPress 5.9
  • open issues for any incompatibilities noted in testing
  • resolve issues identified in testing
  • bump "tested up to" version
  • if code changes needed due to incompatibilities, ship a plugin release, otherwise use "Plugin asset/readme update" action to update "tested up to" version on .org repo

Designs
n/a

Describe alternatives you've considered
none

Additional context
Related: #13.

SVG height and width attributes

Hi @darylldoyle

What are your thoughts on trying to assign the default height and width attributes based on the image size used in the wp_get_attachment_image() function?

echo wp_get_attachment_image( $svg_id, [78, 78], true, [
     'class' => 'img-fluid',
     'alt' => 'icon',
] );

For example, when I use the above in my template with your plugin activated my SVG is loaded with the height and width attributes set to the images default size. I, however, would like the height and width to be 78x78.

I ended up using the following filter in my theme to work around the issue... but i think this would be worth considering incorporating into the plugin.

add_filter( 'wp_get_attachment_image_attributes', 'wwc_fix_direct_image_output', 11, 3 );
function wwc_fix_direct_image_output( $attr, $attachment, $size = 'thumbnail' ) {

	// If we're not getting a WP_Post object, bail early.
	// @see https://wordpress.org/support/topic/notice-trying-to-get-property-id/
	if ( ! $attachment instanceof WP_Post ) {
		return $attr;
	}

	$mime = get_post_mime_type( $attachment->ID );
	if ( 'image/svg+xml' === $mime ) {
		$default_height = 100;
		$default_width  = 100;

		$size = image_downsize($attachment->ID, $size);
		
		if (is_array($size) && sizeof($size) >= 3) {
			$attr['height'] = $size[2];
			$attr['width']  = $size[1];
		}
	}

	return $attr;
}```

SVGO Optimisation

Is your enhancement related to a problem? Please describe.

Port in from Pro version

Designs

No response

Describe alternatives you've considered

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct

Release version 2.1.1

This issue is for tracking changes for the 2.1.1 release. Target release date: 05 April 2023.

Release steps

  • Branch: Starting from develop, cut a release branch named release/2.1.1 for your changes.
  • Version bump: Bump the version number in readme.txt, safe-svg.php, package.json and package-lock.json if it does not already reflect the version being released. In safe-svg.php update both the plugin "Version:" property and the plugin SAFE_SVG_VERSION constant.
  • Changelog: Add/update the changelog in CHANGELOG.md and readme.txt.
  • Props: Update CREDITS.md with any new contributors, confirm maintainers are accurate.
  • New files: Check to be sure any new files/paths that are unnecessary in the production version are included in .distignore.
  • Readme updates: Make any other readme changes as necessary. README.md is geared toward GitHub and readme.txt contains WordPress.org-specific content. The two are slightly different.
  • Merge: Make a non-fast-forward merge from your release branch to develop (or merge the pull request), then do the same for develop into trunk, ensuring you pull the most recent changes into develop first (git checkout develop && git pull origin develop && git checkout trunk && git merge --no-ff develop). trunk contains the stable development version.
  • Push: Push your trunk branch to GitHub (e.g. git push origin trunk).
  • Compare trunk to develop to ensure no additional changes were missed.
  • Test the pre-release ZIP locally by downloading it from the Build release zip action artifact and installing it locally. Ensure this zip has all the files we expect, that it installs and activates correctly and that all basic functionality is working.
  • Release: Create a new release, naming the tag and the release with the new version number, and targeting the trunk branch. Paste the changelog from CHANGELOG.md into the body of the release and include a link to the closed issues on the milestone. The release should now appear under releases.
  • SVN: Wait for the GitHub Action to finish deploying to the WordPress.org repository. If all goes well, users with SVN commit access for that plugin will receive an emailed diff of changes.
  • Check WordPress.org: Ensure that the changes are live on https://wordpress.org/plugins/safe-svg/. This may take a few minutes.
  • Close milestone: Edit the milestone with release date (in the Due date (optional) field) and link to GitHub release (in the Description field), then close the milestone.
  • Punt incomplete items: If any open issues or PRs which were milestoned for 2.1.1 do not make it into the release, update their milestone to 2.2.0 or Future Release.

WordPress image sizes for SVG

Describe the bug

When inserting SVG to the post, or using wp_get_attachment_image() function with custom image size ('large', 'medium', 'thumbnail', etc.) we always receive the full SVG src (which is normal) and incorrect (full-size or square) image dimensions in width and height attributes.

Steps to Reproduce

Displaying SVG programmatically

$att_id = 454;
echo wp_get_attachment_image( $att_id, 'full' );
echo wp_get_attachment_image( $att_id, 'medium' );

Both resulting images have the same width and height. Expected to have 300x152 for medium size.

<img width="406" height="206" src=/wp-content/uploads/2022/03/image.svg" class="attachment-full size-full" alt="" loading="lazy">
<img width="406" height="206" src=/wp-content/uploads/2022/03/image.svg" class="attachment-medium size-medium" alt="" loading="lazy">

Adding SVG in Block Editor

Regardless of the selected Image Size in the Block Properties, the Image Dimensions remain the same (full size) and the resulting image still have full dimensions in width and height attributes. Expected to have width="300" height="152" in this example

<figure class="wp-block-image size-medium"><img width="406" height="206" src="/wp-content/uploads/2022/03/image.svg" alt="" class="wp-image-454"></figure>

Adding SVG in Classic Editor

The image width and height attributes respect the selected size (medium) but represent the square 300x300. Expected to have the height="152"

<img class="alignnone wp-image-454 size-medium" role="img" src="/wp-content/uploads/2022/03/image.svg" alt="" width="300" height="300" />

Environment information

Previous release Safe SVG 1.9.9
(or develop with merged fix/23)

Code of Conduct

  • I agree to follow this project's Code of Conduct

Two bug fixes relating to image dimensions

I see you're possibly releasing a new version shortly, so I thought I'd highlight two bug fixes that really need to be in it. Given the plugin hasn't been updated in ages, I've been hacking them into versions I install, so don't want them to go back to being broken on upgrade.

a) https://wordpress.org/support/topic/1-9-9-doesnt-return-correct-width-and-height/

A missing string cast causes dimensions to be lost from some SVGs.

b) https://wordpress.org/support/topic/square-svgs-are-totally-broken-in-chrome/

A bug with srcsets breaks square SVGs entirely in Chrome.

Undefined $file['tmp_name']

Describe the bug

When I submit a form from another extension, there is an empty file entry.
I have an error generated by safe-svg because there is an undefined variable.

In function check_for_svg :

$wp_filetype = wp_check_filetype_and_ext( $file['tmp_name'], $file['name'] );

If I add this code before, it's working !

if ( ! isset( $file['tmp_name'] ) || ! isset( $file['name'] ) ) {
    return $file;
}

Steps to Reproduce

Maybe create a form with empty file input.

Screenshots, screen recording, code snippet

No response

Environment information

No response

WordPress information

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct

Release version 2.0.0

Describe your question

This issue is for tracking changes for the 2.0.0 release. Target release date: 6 April 2022.

Release steps

  • Branch: Starting from develop, cut a release branch named release/2.0.0 for your changes.
  • Version bump: Bump the version number in readme.txt and safe-svg.php if it does not already reflect the version being released.
  • Changelog: Add/update the changelog in CHANGELOG.md and readme.txt.
  • Props: Update CREDITS.md with any new contributors, confirm maintainers are accurate.
  • New files: Check to be sure any new files/paths that are unnecessary in the production version are included in .distignore.
  • Readme updates: Make any other readme changes as necessary. README.md is geared toward GitHub and readme.txt contains WordPress.org-specific content. The two are slightly different.
  • Merge: Make a non-fast-forward merge from your release branch to develop (or merge the Pull Request), then do the same for develop into trunk (git checkout trunk && git merge --no-ff develop). trunk contains the stable development version.
  • Test: While still on the trunk branch, test for functionality locally.
  • Push: Push your trunk branch to GitHub (e.g. git push origin trunk).
  • Release: Create a new release, naming the tag and the release with the new version number, and targeting the trunk branch. Paste the changelog from CHANGELOG.md into the body of the release and include a link to the closed issues on the milestone. The release should now appear under releases.
  • SVN: Wait for the GitHub Action to finish deploying to the WordPress.org repository. If all goes well, users with SVN commit access for that plugin will receive an emailed diff of changes.
  • Check WordPress.org: Ensure that the changes are live on https://wordpress.org/plugins/safe-svg/. This may take a few minutes.
  • Close milestone: Edit the milestone with release date (in the Due date (optional) field) and link to GitHub release (in the Description field), then close the milestone.
  • Punt incomplete items: If any open issues or PRs which were milestoned for 2.0.0 do not make it into the release, update their milestone to 2.1.0 or Future Release.

Code of Conduct

  • I agree to follow this project's Code of Conduct

Slow load times due to svg_dimensions

Describe the bug

Some time ago I opened this issue regarding the performance of this plugin (also see this related issue). Basically when we have a lot of SVGs on a page populated by a Gutenberg block callback function, the load time for the page can be very long due to multiple calls to the svg_dimensions function. At the time the issue was not resolved so I edited the plugin as described to avoid overuse of the svg_dimensions function.

Now that this plugin is being developed again, could it be modified to include a filter to avoid this operation. You can see how I created the filter in my edited version of the plugin here. Alternatively, the performance issues could be addressed in some other way. Then I could stop using my custom version.

Steps to Reproduce

Create a page with a ton of SVGs that get populated using a custom Gutenberg block callback function. See this comment for more info.

Screenshots, screen recording, code snippet

See this image

Environment information

not relevant

WordPress information

This bug was reported 2 years ago so I was on an older version of WP then but I doubt the WP version is relevant.

Code of Conduct

  • I agree to follow this project's Code of Conduct

Test against WordPress 6.0

Is your enhancement related to a problem? Please describe.
Now that WordPress 6.0 is released, we'll want to test Safe SVG to see if any incompatibility issues arise.

Describe the solution you'd like

  • test Safe SVG on WordPress 6.0
  • open issues for any incompatibilities noted in testing
  • resolve issues identified in testing
  • bump "tested up to" version
  • if code changes needed due to incompatibilities, ship a plugin release, otherwise use "Plugin asset/readme update" action to update "tested up to" version on .org repo

Designs
n/a

Describe alternatives you've considered
none

Additional context
Related: #22, #13.

Update enshrined/svg-sanitize and bump PHP minimum version to 7.0

Is your enhancement related to a problem? Please describe.

The original issue can be found here #12 (PHP 8.0: libxml_disable_entity_loader function is deprecated)

Describe the solution you'd like

enshrined/svg-sanitize lib already has added support for PHP 8.0. So, need to update lib to add that support to the wp plugin.
enshrined/svg-sanitize requires minimum PHP 7.0. So, need to bump PHP minimum version to 7.0 with upgrade notice as per @jeffpaul 's comment here

we'll want to clearly call that out in the changelog and in an upgrade notice in the readme.txt file. Anyone running a lower PHP version should be blocked by WP core in attempting to update but we should still clearly call out the change so folks are aware.

Designs
n/a

Describe alternatives you've considered

Additional context

Noting here for giving credit to https://github.com/amdd-tim for raising original PR and issue.(#12)

Add a "Build release zip" GitHub Action

Is your enhancement related to a problem? Please describe.

A new Action is released: https://github.com/10up/action-wordpress-plugin-build-zip/. This is already set up in a few PRs: Insert Special Characters, Autoshare for Twitter and Simple Podcasting. As an example, you can see/download the Simple Podcasting zip here.

Please go ahead and create the same in this repository.

Designs

No response

Describe alternatives you've considered

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct

Fatal error with minimum supported WordPress version

Describe the bug

The plugin uses WordPress core function which is not compatible with currently declared Requires at least: 4.0:

wp_get_additional_image_sizes() safe-svg.php:328

This function was introduced in 4.7:
https://github.com/WordPress/WordPress/blob/f4a871189a34e5a8d7aa1bb322aa5d32128e79ff/wp-includes/media.php#L9-L18

/**
 * Retrieve additional image sizes.
 *
 * @since 4.7.0
 *
 * @global array $_wp_additional_image_sizes
 *
 * @return array Additional images size data.
 */
function wp_get_additional_image_sizes() {

Steps to Reproduce

  1. Install WordPress prior to 4.7
  2. Activate Safe SVG
  3. Try to upload SVG image
  4. Upload fails with Fatal error
Fatal error: Uncaught Error: Call to undefined function wp_get_additional_image_sizes() in /var/www/html/wp-content/plugins/safe-svg/safe-svg.php:328
Stack trace:
#0 /var/www/html/wp-includes/plugin.php(214): safe_svg->skip_svg_regeneration(Array, 14)
#1 /var/www/html/wp-admin/includes/image.php(204): apply_filters('wp_generate_att...', Array, 14)
#2 /var/www/html/wp-admin/includes/media.php(345): wp_generate_attachment_metadata(14, '/var/www/html/w...')
#3 /var/www/html/wp-admin/includes/ajax-actions.php(1854): media_handle_upload('async-upload', '13', Array)
#4 /var/www/html/wp-admin/async-upload.php(46): wp_ajax_upload_attachment()
#5 {main} thrown in /var/www/html/wp-content/plugins/safe-svg/safe-svg.php on line 328

Screenshots, screen recording, code snippet

No response

Environment information

No response

WordPress information

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct

Slope attribute stripped on upload

I've built a simple filter for adding a semi transparent drop shadow to shapes in an SVG, works great locally but when I uploaded it to my WordPress site with your plugin installed I noticed it removed the slope attribute from feFuncA element.

Uploaded Code:

<filter id="f2" x="0" y="0" width="200%" height="200%">
      <feOffset result="offOut" in="SourceAlpha" dx="5" dy="5" />
      <feGaussianBlur result="blurOut" in="offOut" stdDeviation="5" />
      <feComponentTransfer in="blurOut" result="alphaOut">
        <feFuncA type="linear" slope="0.2"/>
      </feComponentTransfer>
      <feBlend in="SourceGraphic" in2="alphaOut" mode="normal" result="shadow" />
</filter>

Code from SVG on Site:

<filter id="f2" x="0" y="0" width="200%" height="200%">
	<feOffset result="offOut" in="SourceAlpha" dx="5" dy="5"></feOffset>
	<feGaussianBlur result="blurOut" in="offOut" stdDeviation="5"></feGaussianBlur>
	<feComponentTransfer in="blurOut" result="alphaOut">
		<feFuncA type="linear"></feFuncA>
	</feComponentTransfer>
	<feBlend in="SourceGraphic" in2="alphaOut" mode="normal" result="shadow"></feBlend>
</filter>

Here is a gist for the full SVG image:
https://gist.github.com/bobsmith1981/b54af9259370fba821bdc5027ffedef2#file-velpeo-svg-logo

Here is a version missing the slope:
http://cdn.velpeo.com/wp-content/uploads/2018/09/30152059/large-square-icon-minimal-01.svg

It would be beneficial if you could use `safe-svg` for `wp_kses` and other similar purposes.

Is your enhancement related to a problem? Please describe.

I am using svg in my widget (custom HTML block) and sanitizing the content with wp_kses. However, it strips down the svg markup.

It would be nice if safe-svg could provide a helper function for such use cases. It wouldn't necessarily need to hook into wp_kses_allowed_html, but it would be helpful if I could use the sane defaults provided by this plugin.

wp_kses( $input, \enshrined\svgSanitize\Sanitizer\kses_extended_ruleset() ) or such would be the use.

Designs

No response

Describe alternatives you've considered

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct

Release version 2.0.2

This issue is for tracking changes for the 2.0.2 release. Target release date: 27 June 2022.

Release steps

  • Branch: Starting from develop, cut a release branch named release/2.0.2 for your changes.
  • Version bump: Bump the version number in readme.txt and safe-svg.php if it does not already reflect the version being released.
  • Changelog: Add/update the changelog in CHANGELOG.md and readme.txt.
  • Props: Update CREDITS.md with any new contributors, confirm maintainers are accurate.
  • New files: Check to be sure any new files/paths that are unnecessary in the production version are included in .distignore.
  • Readme updates: Make any other readme changes as necessary. README.md is geared toward GitHub and readme.txt contains WordPress.org-specific content. The two are slightly different.
  • Merge: Make a non-fast-forward merge from your release branch to develop (or merge the Pull Request), then do the same for develop into trunk (git checkout trunk && git merge --no-ff develop). trunk contains the stable development version.
  • Test: While still on the trunk branch, test for functionality locally.
  • Push: Push your trunk branch to GitHub (e.g. git push origin trunk).
  • Release: Create a new release, naming the tag and the release with the new version number, and targeting the trunk branch. Paste the changelog from CHANGELOG.md into the body of the release and include a link to the closed issues on the milestone. The release should now appear under releases.
  • SVN: Wait for the GitHub Action to finish deploying to the WordPress.org repository. If all goes well, users with SVN commit access for that plugin will receive an emailed diff of changes.
  • Check WordPress.org: Ensure that the changes are live on https://wordpress.org/plugins/safe-svg/. This may take a few minutes.
  • Close milestone: Edit the milestone with release date (in the Due date (optional) field) and link to GitHub release (in the Description field), then close the milestone.
  • Punt incomplete items: If any open issues or PRs which were milestoned for 2.0.2 do not make it into the release, update their milestone to 2.1.0 or Future Release.

Release version 2.0.3

This issue is for tracking changes for the 2.0.3 release. Target release date: 01 Sept 2022.

Release steps

  • Branch: Starting from develop, cut a release branch named release/2.0.3 for your changes.
  • Version bump: Bump the version number in readme.txt, safe-svg.php, package.json and package-lock.json if it does not already reflect the version being released. In safe-svg.php update both the plugin "Version:" property and the plugin SAFE_SVG_VERSION constant.
  • Changelog: Add/update the changelog in CHANGELOG.md and readme.txt.
  • Props: Update CREDITS.md with any new contributors, confirm maintainers are accurate.
  • New files: Check to be sure any new files/paths that are unnecessary in the production version are included in .distignore.
  • Readme updates: Make any other readme changes as necessary. README.md is geared toward GitHub and readme.txt contains WordPress.org-specific content. The two are slightly different.
  • Merge: Make a non-fast-forward merge from your release branch to develop (or merge the Pull Request), then do the same for develop into trunk (git checkout trunk && git merge --no-ff develop). trunk contains the stable development version.
  • Test: While still on the trunk branch, test for functionality locally.
  • Push: Push your trunk branch to GitHub (e.g. git push origin trunk).
  • Release: Create a new release, naming the tag and the release with the new version number, and targeting the trunk branch. Paste the changelog from CHANGELOG.md into the body of the release and include a link to the closed issues on the milestone. The release should now appear under releases.
  • SVN: Wait for the GitHub Action to finish deploying to the WordPress.org repository. If all goes well, users with SVN commit access for that plugin will receive an emailed diff of changes.
  • Check WordPress.org: Ensure that the changes are live on https://wordpress.org/plugins/safe-svg/. This may take a few minutes.
  • Close milestone: Edit the milestone with release date (in the Due date (optional) field) and link to GitHub release (in the Description field), then close the milestone.
  • Punt incomplete items: If any open issues or PRs which were milestoned for 2.0.3 do not make it into the release, update their milestone to 2.1.0 or Future Release.

Release version 2.1.0

Describe your question

This issue is for tracking changes for the 2.1.0 release. Target release date: 16 MAR 2023.

Release steps

  • Branch: Starting from develop, cut a release branch named release/2.1.0 for your changes.
  • Version bump: Bump the version number in readme.txt, safe-svg.php, package.json and package-lock.json if it does not already reflect the version being released. In safe-svg.php update both the plugin "Version:" property and the plugin SAFE_SVG_VERSION constant.
  • Changelog: Add/update the changelog in CHANGELOG.md and readme.txt.
  • Props: Update CREDITS.md with any new contributors, confirm maintainers are accurate.
  • New files: Check to be sure any new files/paths that are unnecessary in the production version are included in .distignore.
  • Readme updates: Make any other readme changes as necessary. README.md is geared toward GitHub and readme.txt contains WordPress.org-specific content. The two are slightly different.
  • Merge: Make a non-fast-forward merge from your release branch to develop (or merge the pull request), then do the same for develop into trunk, ensuring you pull the most recent changes into develop first (git checkout develop && git pull origin develop && git checkout trunk && git merge --no-ff develop). trunk contains the stable development version.
  • Push: Push your trunk branch to GitHub (e.g. git push origin trunk).
  • Compare trunk to develop to ensure no additional changes were missed.
  • Test the pre-release ZIP locally by downloading it from the Build release zip action artifact and installing it locally. Ensure this zip has all the files we expect, that it installs and activates correctly and that all basic functionality is working.
  • Release: Create a new release, naming the tag and the release with the new version number, and targeting the trunk branch. Paste the changelog from CHANGELOG.md into the body of the release and include a link to the closed issues on the milestone. The release should now appear under releases.
  • SVN: Wait for the GitHub Action to finish deploying to the WordPress.org repository. If all goes well, users with SVN commit access for that plugin will receive an emailed diff of changes.
  • Check WordPress.org: Ensure that the changes are live on https://wordpress.org/plugins/safe-svg/. This may take a few minutes.
  • Close milestone: Edit the milestone with release date (in the Due date (optional) field) and link to GitHub release (in the Description field), then close the milestone.
  • Punt incomplete items: If any open issues or PRs which were milestoned for 2.1.0 do not make it into the release, update their milestone to 2.2.0 or Future Release.

Code of Conduct

  • I agree to follow this project's Code of Conduct

Better handling of invalid PHP versions

Describe the bug

In #82, which was released in 2.1.0, we bumped the minimum PHP version to 7.4. We got some reports on WordPress.org of sites running a version of PHP less than 7.4 getting fatal errors.

In theory, WordPress should prevent plugin updates (or installs) when an environment doesn't meet the minimum requirements (in this case, the PHP version). Reading that linked thread, sounds like potentially an issue with auto-updates or an issue with another plugin (Shield and iThemes Sync are the two mentioned ones). I was not able to reproduce any issue myself with auto-updates, the only way I could force an update was using WP-CLI (reported issue).

That said, the fatal error here comes from composer. Composer loads a platform check that triggers an error if requirements aren't met. This is not an ideal way to handle these errors, as it brings the entire site down. We should look to add better error handling for the hopefully rare situations where someone updates to an incompatible version.

Steps to Reproduce

  1. Setup an environment running PHP 7.3
  2. Download version 2.1.0 of Safe SVG and manually install that in the environment
  3. Note the fatal error you'll get

Screenshots, screen recording, code snippet

No response

Environment information

No response

WordPress information

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct

Choose Who Can Upload

Is your enhancement related to a problem? Please describe.

Port in from Pro version

Designs

No response

Describe alternatives you've considered

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct

Upgrade to 1.9.8 version

Hi there,
I did install your plugin through composer but I am not able to update it your last version.

- The requested package darylldoyle/safe-svg ^1.9.8 exists as darylldoyle/safe-svg[1.9.4, 1.9.5, 1.9.6, 1.9.7, dev-master] but these are rejected by your constraint.

NPM archive related scripts include node_modules and vendor files in zip.

Describe the bug

When building an archive using the NPM archive and postarchive scripts, the node_modules and vendor folders are included in the zip file.

In local testing, this created a 69.6 MB zip file.

Steps to Reproduce

  1. Check out develop branch.
  2. Run npm i; composer i; npm run build;
  3. Run npm run archive -- observe the node and vendor folders are included in the zip
  4. Run npm run postarchive
  5. Run cd safe-svg; ls
  6. Observe the unzipped files also include the node_modules and vendor folders

Screenshots, screen recording, code snippet

No response

Environment information

  • Device: macbook pro 2020
  • OS: macOS 12.6.2

WordPress information

N/A

Code of Conduct

  • I agree to follow this project's Code of Conduct

All wp-cli commands break since v2.1.0

Describe the bug

All wp-cli commands fail with safe-svg >= v2.1.0 installed due to call to undefined function SafeSvg\Blocks\setup().

This is the full error message:

Fatal error: Uncaught Error: Call to undefined function SafeSvg\Blocks\setup() in /Users/marco/repos/valet/lumiere-starter-theme/wp-content/plugins/safe-svg/safe-svg.php:151
Stack trace:
#0 /Users/marco/repos/valet/lumiere-starter-theme/wp-includes/class-wp-hook.php(308): SafeSvg\safe_svg->setup_blocks('')
#1 /Users/marco/repos/valet/lumiere-starter-theme/wp-includes/class-wp-hook.php(332): WP_Hook->apply_filters(NULL, Array)
#2 /Users/marco/repos/valet/lumiere-starter-theme/wp-includes/plugin.php(517): WP_Hook->do_action(Array)
#3 /Users/marco/repos/valet/lumiere-starter-theme/wp-settings.php(623): do_action('init')
#4 phar:///opt/homebrew/Cellar/wp-cli/2.7.1/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Runner.php(1336): require('/Users/marco/re...')
#5 phar:///opt/homebrew/Cellar/wp-cli/2.7.1/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Runner.php(1254): WP_CLI\Runner->load_wordpress()
#6 phar:///opt/homebrew/Cellar/wp-cli/2.7.1/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Bootstrap/LaunchRunner.php(28): WP_CLI\Runner->start()
#7 phar:///opt/homebrew/Cellar/wp-cli/2.7.1/bin/wp/vendor/wp-cli/wp-cli/php/bootstrap.php(78): WP_CLI\Bootstrap\LaunchRunner->process(Object(WP_CLI\Bootstrap\BootstrapState))
#8 phar:///opt/homebrew/Cellar/wp-cli/2.7.1/bin/wp/vendor/wp-cli/wp-cli/php/wp-cli.php(32): WP_CLI\bootstrap()
#9 phar:///opt/homebrew/Cellar/wp-cli/2.7.1/bin/wp/php/boot-phar.php(11): include('phar:///opt/hom...')
#10 /opt/homebrew/Cellar/wp-cli/2.7.1/bin/wp(4): include('phar:///opt/hom...')
#11 {main}
  thrown in /Users/marco/repos/valet/lumiere-starter-theme/wp-content/plugins/safe-svg/safe-svg.php on line 151

Steps to Reproduce

  1. Install and activate safe-svg v2.1.0 or above.
  2. Run any wp-cli command in the terminal.

Screenshots, screen recording, code snippet

No response

Environment information

  • Device: MacBook Pro 2021
  • OS: macOS 12.6.3

WordPress information

Site Health info: ### wp-core ###

version: 6.2
site_language: en_US
user_language: en_US
timezone: Europe/Zurich
permalink: /%postname%/
https_status: true
multisite: false
user_registration: 0
blog_public: 0
default_comment_status: undefined
environment_type: production
user_count: 1
dotorg_communication: true

wp-paths-sizes

wordpress_path: /Users/marco/repos/valet/lumiere-starter-theme
wordpress_size: loading...
uploads_path: /Users/marco/repos/valet/lumiere-starter-theme/wp-content/uploads
uploads_size: loading...
themes_path: /Users/marco/repos/valet/lumiere-starter-theme/wp-content/themes
themes_size: loading...
plugins_path: /Users/marco/repos/valet/lumiere-starter-theme/wp-content/plugins
plugins_size: loading...
database_size: loading...
total_size: loading...

wp-active-theme

name: Lumiere Theme (lumiere-starter-theme)
version: 3.2.0
author: Marco Luzi
author_website: (undefined)
parent_theme: none
theme_features: widgets-block-editor, automatic-feed-links, title-tag, post-thumbnails, editor-styles, html5, editor-style, menus
theme_path: /Users/marco/repos/valet/lumiere-starter-theme/wp-content/themes/lumiere-starter-theme
auto_update: Disabled

wp-themes-inactive (3)

Twenty Twenty-One: version: 1.8, author: the WordPress team, Auto-updates disabled
Twenty Twenty-Three: version: 1.1, author: the WordPress team, Auto-updates disabled
Twenty Twenty-Two: version: 1.4, author: the WordPress team, Auto-updates disabled

wp-plugins-active (6)

Advanced Custom Fields PRO: version: 6.1.3, author: WP Engine, Auto-updates disabled
Ghost Kit: version: 2.25.0, author: Ghost Kit Team, Auto-updates disabled
Loco Translate: version: 2.6.4, author: Tim Whitlock, Auto-updates disabled
Safe SVG: version: 2.1.1, author: 10up, Auto-updates disabled
Simple Custom Post Order: version: 2.5.6, author: Colorlib, Auto-updates disabled
Yoast SEO: version: 20.3, author: Team Yoast (latest version: 20.4), Auto-updates disabled

wp-media

image_editor: WP_Image_Editor_GD
imagick_module_version: Not available
imagemagick_version: Not available
imagick_version: Not available
file_uploads: File uploads is turned off
post_max_size: 512M
upload_max_filesize: 512M
max_effective_size: 512 MB
max_file_uploads: 20
gd_version: 2.3.3
gd_formats: GIF, JPEG, PNG, WebP, BMP, AVIF, XPM
ghostscript_version: not available

wp-server

server_architecture: Darwin 21.6.0 arm64
httpd_software: nginx/1.23.3
php_version: 8.1.17 64bit
php_sapi: fpm-fcgi
max_input_variables: 1000
time_limit: 30
memory_limit: 512M
max_input_time: 60
upload_max_filesize: 512M
php_post_max_size: 512M
curl_version: 7.88.1 (SecureTransport) OpenSSL/1.1.1t
suhosin: false
imagick_availability: false
pretty_permalinks: true

wp-database

extension: mysqli
server_version: 10.11.2-MariaDB
client_version: mysqlnd 8.1.17
max_allowed_packet: 16777216
max_connections: 151

wp-constants

WP_HOME: undefined
WP_SITEURL: undefined
WP_CONTENT_DIR: /Users/marco/repos/valet/lumiere-starter-theme/wp-content
WP_PLUGIN_DIR: /Users/marco/repos/valet/lumiere-starter-theme/wp-content/plugins
WP_MEMORY_LIMIT: 40M
WP_MAX_MEMORY_LIMIT: 512M
WP_DEBUG: true
WP_DEBUG_DISPLAY: false
WP_DEBUG_LOG: true
SCRIPT_DEBUG: true
WP_CACHE: false
CONCATENATE_SCRIPTS: undefined
COMPRESS_SCRIPTS: undefined
COMPRESS_CSS: undefined
WP_ENVIRONMENT_TYPE: Undefined
DB_CHARSET: utf8
DB_COLLATE: undefined

wp-filesystem

wordpress: writable
wp-content: writable
uploads: writable
plugins: writable
themes: writable

Code of Conduct

  • I agree to follow this project's Code of Conduct

Regenerate metadata

Is your enhancement related to a problem? Please describe.

The plugin generates thumbnail data for the current theme. A theme change or other circumstances will change the thumbnail sizes used. For example, themes use post-thumbnail. Thumbnail size metadata will contain outdated data.
For traditional image types, there is a choice of thumbnail regeneration plugins. The regeneration of thumbnail sizes for SVG remains an open question.

Designs

No response

Describe alternatives you've considered

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct

Bump WordPress and PHP minimums

Bump WP & PHP Minimums to the following

  • WordPress to 5.7
  • PHP to 7.4
  • Remove any no-longer-needed conditional code for older version support.
  • Take a look at adjusting our testing matrices, if applicable.
  • Bump the minimums in plugin documentation and header fields.

Release version 1.9.10

Describe your question

This issue is for tracking changes for the 1.9.10 release. Target release date: 21 February 2022.

Release steps

  • Branch: Starting from develop, cut a release branch named release/1.9.10 for your changes.
  • Version bump: Bump the version number in readme.txt and safe-svg.php if it does not already reflect the version being released.
  • Changelog: Add/update the changelog in CHANGELOG.md and readme.txt.
  • Props: Update CREDITS.md with any new contributors, confirm maintainers are accurate.
  • New files: Check to be sure any new files/paths that are unnecessary in the production version are included in .distignore.
  • Readme updates: Make any other readme changes as necessary. README.md is geared toward GitHub and readme.txt contains WordPress.org-specific content. The two are slightly different.
  • Merge: Make a non-fast-forward merge from your release branch to develop (or merge the Pull Request), then do the same for develop into trunk (git checkout trunk && git merge --no-ff develop). trunk contains the stable development version.
  • Test: While still on the trunk branch, test for functionality locally.
  • Push: Push your trunk branch to GitHub (e.g. git push origin trunk).
  • Release: Create a new release, naming the tag and the release with the new version number, and targeting the trunk branch. Paste the changelog from CHANGELOG.md into the body of the release and include a link to the closed issues on the milestone. The release should now appear under releases.
  • SVN: Wait for the GitHub Action to finish deploying to the WordPress.org repository. If all goes well, users with SVN commit access for that plugin will receive an emailed diff of changes.
  • Check WordPress.org: Ensure that the changes are live on https://wordpress.org/plugins/safe-svg/. This may take a few minutes.
  • Close milestone: Edit the milestone with release date (in the Due date (optional) field) and link to GitHub release (in the Description field), then close the milestone.
  • Punt incomplete items: If any open issues or PRs which were milestoned for 1.9.10 do not make it into the release, update their milestone to 2.0.0 or Future Release.

Code of Conduct

  • I agree to follow this project's Code of Conduct

Add Unit tests

Is your enhancement related to a problem? Please describe.

Add unit tests.

  • Setup PHPUnit
  • Add tests
  • Setup GH Action for run unit tests.

Designs

No response

Describe alternatives you've considered

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.