lewiscowles1986 / wordpresssvgplugin

WordPress SVG Plugin

Enable SVG Uploads WordPress Plugin

This plugin enables SVG uploads in WordPress Media Library with very little overhead.

Installation

Download and extract the zip file or clone this repo to your WordPress plugins directory.

After an upgrade to 2.x it may be necessary to download and re-upload your SVG media files so that the grid works. This is because we now use simple XML to retrieve the width & height of the SVG.

Requirements

• WordPress 4.4 or higher (advised to use latest)
• PHP 7.1 or higher (EOL versions may work, but you should still run this on latest stable)
  • PHP 7.3 is the minimum to run the tests due to phpunit 9

Updates

Automatic updates are supported via GitHub Updater.

Feedback

Please feel free to suggest improvements, report conflicts, and/or make suggestions for hooks to integrate with third-party plugins.

Goals

• Install / start container / VM for each release since
• Download from GitHub & install plugin
• Use browser automation to test (details)

wordpresssvgplugin's Issues

Add SVG Metadata (if available) to upload

So it looks like regular SVG's can have their dimensions uploaded with the media via the wp_update_attachment_metadata hook. See https://wordpress.stackexchange.com/questions/255687/set-media-metadata-i-e-dimensions-field-on-svg-file-after-extracting-it-wit

SVG's in gutenberg & some plugins cause issues in admin UI

CSS selector for SVG's too greedy.

On a positive note deactivating the css rule seems to work just fine for new SVG uploads. For older SVG uploads remediation needs to take place to extract dimensions,

getshifter.io test-site warning

Themes need support to style CSS in an SVG inclusive way

Basically unless your theme supports styling for SVG's, the editor and final output might not be great. This is here just in-case we get issues like 1px x 1px SVG's or SVG's with height and width not constrained. It's not the job of this plugin to fix your theme, just enable the use of SVG's on the platform. More work is needed, and we'll happily accept PR's for docs on how you did this for theme-X

Incomplete release history

Need to establish formal release process to use GitHub to track releases

• Historical releases from 1.0 (if possible not sure if first few iterations imported via snapshot from legacy Gist)
• Script to version bump after passing CI (potentially separating into 2 files for ease of parsing)

Excerpt view for posts broken if emojii's exist

If this plugin is active, and I visit the url {websiteurl}/wp-admin/edit.php?mode=excerpt with any post having an emojii. This happens

If I disable this plugin. I see this

Use case
As any user that can view the admin back-end. So that I can see as many posts as necessary, it would be nice if this plugin did not alter default WordPress behaviour for displaying the post listing.

Formal CI Frontend suite needed

Need a formal CI suite that allows me to install this plugin, then test various behaviours

• Install / start container / VM for each release since April 2015 (Aim to adjust this to 18-month window as needed)
• Download from GitHub & install plugin
• Use browser automation to test
  • Upload using new UI
  • Upload using fallback UI
  • Image present for Grid Media View
  • Image present for detail Media View
  • Image present upon Attachment Modal View
  • Image present upon admin-ui post entry for image file
  • Image able to be added to page / post / CPT as featured image via UI

Add more tests as needed...

Releases and Small Request

Greetings,

This is a great and no-nonsense plugin - I use it on several sites.

A couple of small, personal requests:

• Would you remove the // forced crop STFU line? I use this in production. 😏 I remove it myself, but I have some automation scripts that pull it automatically.
• It appears that there have been several changes/fixes since the 1.6.4 release version. Would you mind doing a new release (1.6.5 or whatever appropriate) when you feel it is ready?

Thank you,
Daniel

Distribution

To push this forward there are a few points

• change owner? #8
• plugin repository submission?
• contributors update? #22
• guide RE: github updater please

Github updater folder structure

As per comments on #8 there seems to be some incompatibility with GitHub updater. Adjust folder structure accordingly.

Stance on SVG sanitation

• Use something outside of WordPress to check ALL your assets for vulns.
• Don't weigh down WP
• Don't irresponsibly use third-party assets
• Don't leave it to something that's job is to help you author a web presence to also provide security.
• It's your site; only you have the potential to hurt others and your ventures by not being responsible
• just be careful and responsible with what you upload.

Separate repo?

Should this be moved to a separate org (I'm thinking moving to my business org)?

Not working 4.7.2

Shows general error of "This type of file is not allowed due to security measures".

All I did was clone the repo and put the folder into wp-content/plugins.

[BUG] Version 2.1.3 causes PHP Fatal Error

Describe the bug

Bump from version 2.1.2 -> 2.1.3 causes PHP Fatal Error. Same behaviour on three different sites.

The Context

PHP Fatal error: Uncaught Error: Class 'lewiscowles\Plugins\EnableSVG\lewiscowles\WordPress\Compat\FileTypes\SVGSupport' not found in /var/www/html/wp-content/plugins/enable-svg-uploads/index.php:42

Stack trace:
#0 /var/www/html/wp-settings.php(391): include_once()
#1 phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Runner.php(1237): require('/var/www/html/w...')
#2 phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Runner.php(1158): WP_CLI\Runner->load_wordpress()
#3 phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Bootstrap/LaunchRunner.php(23): WP_CLI\Runner->start()
#4 phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/bootstrap.php(74): WP_CLI\Bootstrap\LaunchRunner->process(Object(WP_CLI\Bootstrap\BootstrapState))
#5 phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/wp-cli.php(27): WP_CLI\bootstrap()
#6 phar:///usr/local/bin/wp/php/boot-phar.php(11): include('phar:///usr/loc...')
#7 /usr/local/bin/wp(4): include('phar:///usr/loc...')
#8 {main}
thrown in /var/www/html/wp-content/plugins/enable-svg-uploads/index.php on line 42

To Reproduce

Steps to reproduce the behaviour:
Install latest version of plugin

Expected behaviour

Expectation is that plugin would work. Rolling back to version 2.1.2. eliminates problem.

SVG size information when available, not used

1.9.1 release added getting information from an SVG about it's size. Currently the plugin has no way to use that information when overriding svg output

Release Management

Alongside #5 would be just super to have

• Tests
• CI
• CD with release updating & auto-bump / draft of release per-accepted-commit

[BUG] Build Broken

Describe the bug

CI Does not pass for the latest release

The Context

• WordPress Version: N/A
• Other plugins: N/A
• Theme: N/A
• URL: https://github.com/Lewiscowles1986/WordPressSVGPlugin/runs/7195014903?check_suite_focus=true

To Reproduce

Steps to reproduce the behaviour:

1. Try running the CI workflow (release works)

Expected behaviour

A Passing test-suite (nothing materially changed)

Screenshot

N/A

Desktop (please complete the following information):

• OS: linux
• Browser: N/A
• Version: N/A (see CI)

Additional context

This is likely from not pinning dependencies enough. To be honest it doesn't affect the plugin, so lazy-bones in me would rather someone else fixed it 😏

Automated test-suite (preferably with badge)

Would be nice to have something

• download this code into a working WordPress
• resolve any dependencies
• run some browser-automation testing
• bundle with dependencies as a staged release

Separate Extension Rectification

https://github.com/Lewiscowles1986/WordPressSVGPlugin/blob/master/index.php#L83,L85

This is too detail oriented for a library with purpose to bring SVG support to WordPress. It also currently throws a warning in some PHP configurations as mentioned in #23.

Separate implementation to external dependency, possibly using composer autoloading.

This will also require a different release or upload format if using composer (bundled with frozen deps), and would benefit from #5 for all parts as well as #25

PHP5 Support

This plugin is only tested with PHP 5.6, and will deprecate support for that as soon as Docker official PHP, or Dreamhost shared hosting deprecates PHP5.6 support (whichever comes soonest)

Direct File Access

Because the file index.php both defines a class and instantiates that class in one file, direct URL access results in an error.

WordPress by design puts all theme and plugin files in a public folder.

Would be good to clean up the plugin to allow direct file access without PHP errors and warnings.

WordPress 4.7.1 Breaks

Well done WP core team... it's likely related to PDF works for media, need to dig in but

• Uploads broken (likely some new mechanism)
• Media UI broken (likely template strings problem)

jQuery errors breaks form notification settings page when using Gravity Forms

With the plugin enabled, getting lots of Uncaught ReferenceError: jQuery is not defined on any Gravity Forms form notification settings page.

Example notification settings page for as for is eg wp-admin/admin.php?page=gf_edit_forms&view=settings&subview=notification&id=1

All other Gravity Forms settings pages are OK.

Doesn't work for some setups...

https://wordpress.org/support/topic/upload-not-working-18/#post-8677921

mentions specifically

• ACF Pro
• Download monitor

Limit CSS Scope?

Some plugins/themes are irresponsible in WP Admin and do not give proper SVG dimensions (else they are overridden by !important). Example where the menu SVG icon is huge:

This particular example has been fixed in the latest WPB Page Builder, however, I had noticed it in other themes/plugins that use SVG. It's been awhile, but I remember it being a huge deal with the Jupiter theme... Several of the theme's SVGs were massive.

• Can we limit the scope of the width: 100% !important; height: auto !important; CSS in the admin, perhaps at least to #wpbody? This wouldn't fix the Jupiter issue, but it would fix all menu icon issues. I'm not sure how to limit it further because you want SVGs to display for any custom field (such as ACF, Carbon Fields, etc) that might be used...
• Do we need !important? Else, perhaps injecting as external CSS with a high priority in the page head so that other !important CSS can override it?

I can install Jupiter in a local VM and try it to see if I can reproduce a situation that can be looked at, but I will have to wait until I have time. It may have been fixed in the latest release - I just mentioned that one because I remembering it being a "huge" deal. If it is broken, I can send you appropriate testing materials, if desired.

Interoperability

Plugin currently runs a little dumb. If another existing plugin is present that compliments this plugin or provides plugin functionality, this plugin should attempt not to be hostile.

• hook / data pull of registered plugins with actions?
• action with control points to allow other plugins to control a set of boolean feature-flags?

Admin URL is canned

See #12 and #13