Darin Kotter

@nekojonez Thanks for the report and the fix! Will get this merged in shortly and it will go out with the next release.

@fesarlis Thanks for raising this. Can you provide an example of a redirect that isn’t working so we can test and fix that? Thanks!

@shirtguy72 Thanks for the question! Yes, if all you use Safe SVG for is to upload SVGs, once those are uploaded, you can remove the plugin and those files will still be there and accessible. You won’t be able to upload new SVGs or use the SVG block but otherwise things will be fine.

@neo2k23 Thanks for the question! Version 2.2.6 is the latest released version and that does include the security fix mentioned. The update from 6 days ago was just bumping the WordPress tested up to version in preparation for the WordPress 6.7 release (can see that change here: https://plugins.trac.www.ads-software.com/changeset?new=3184097%40safe-svg%2Ftrunk%2Freadme.txt&old=3143072%40safe-svg%2Ftrunk%2Fread). These sorts of bumps don’t require an actual release, which is why the version number hasn’t changed since 2.2.6 in August

Interesting… I’ve never seen or heard of that before, it should only occur if installing straight from GitHub.

What version of Safe SVG are you running?

And do you have access to see the code that was installed? If so, would be interested to know if you’re seeing the vendor directory there, in particular the vendor/autoload.php file? The error message should only show if either that file is missing or if that file can’t be read. If the file is there, that means the server can’t read the file which I’m guessing would be a server configuration issue.

@amandadeleoglobalrefuge Thanks for the question. This isn’t something that is currently supported

@sergeyf1 Thanks for the question! This is a known limitation and does require additional configuration for this to work. When a site is behind something like Cloudflare, the IP addresses we look at won’t be accurate. We used to try and support this in the plugin but unfortunately this can lead to security issues with spoofing of HTTP Headers (can see https://github.com/10up/restricted-site-access/issues/195 for some of those details).

Because of that, we removed that feature in order to be more secure. That functionality still exists though and can be manually turned on through the use of a few filters. See our README for full details.

In short, you’ll need to use the rsa_trusted_headers filter to add whatever header your CDN uses to pass in the client IP address (I believe that is HTTP_CF_CONNECTING_IP for Cloudflare). For additional security hardening, you can also use the rsa_trusted_proxies filter to set the IP addresses your proxy uses, which allows us to only trust those additional headers if a request is coming straight from the proxy (eliminating any risk of spoofing).

@kraai Thanks for the question. Where did you install Safe SVG from? You should only get that message if you installed directly from somewhere like Github but shouldn’t show if you installed from the plugin repository here on www.ads-software.com.

In essence that warning is there in case someone installs this plugin directly from Github, they need to run some build commands in order to get all the plugin assets built. But we build all those files directly when the plugin ships to www.ads-software.com

By default WP-CLI will run commands from the root site. If you’re on a multisite, you need to pass in the global parameter --url to set the site. See https://make.www.ads-software.com/cli/handbook/references/config/#global-parameters for more details

plugin generated a fatal error earlier during an update

Curious if you remember what version you were on prior to the update? Were you going from 2.2.5 to 2.2.6 or were you on an older version? Would be great to try and reproduce on our end to see if there’s an issue there we should fix.

@markhowellsmead In looking at the error message provided, seems the plugin is installed twice. I’m seeing both safe-svg and safe-svg_old as mentioned directories. Curious if in testing the upgrade you kept the old plugin around and active? If so, that would cause the error you’re seeing and is expected. I’d suggest removing the old plugin or at least deactivating it to avoid this problem

Thanks for the question. I’ve not heard or seen that URL before and just verified that it isn’t included in any of our source code, so this shouldn’t be coming from this particular plugin. Curious how this was flagged? Could it be coming from something else?

Does Safe SVG sanitize images that are already in the media library

It does not, sanitization only happens when an svg is uploaded.

IF NOT, how do I get Safe SVG to sanitize those as well

There currently isn’t a built-in way to handle this though it has been requested in the past and is something we’ve considered for a future roadmap. At the moment, the only way to achieve this is to write a custom script (using something like WP-CLI) that can find all existing svg files and then run those through our sanitization functions.

There isn’t a built-in way to automatically convert across all sites but you can use our WP-CLI command (wp convert-to-blocks start) to accomplish this. Basically you’d need to get a list of all sites and then run that command for each of them

The only setting for Safe SVG is choosing which user roles can upload SVGs. There isn’t a stand-alone settings page for this but it lives on the Settings > Media settings page