Automattic's war on SVG is madness in an era of high DPR displays. It's not difficult to fix with the Safe SVG plugin (or with code, if you prefer), however, I feel like the ability to upload SVGs should be a stock feature.
Holy truth my friend! As for me it coul'd be also known as end of .png era! SVG always look better, Always if needed had to upload them manually and hardcode from link.
I am not sure if that was a good idea. I mean SVGs are great i really like them, but the issue is that they are not images but structured data files with a plethora of possible security issues. So i only display such SVGs that i have built personally or inspected each and every letter of it. But never allow any user to upload their own SVG which i can not trust.
"ClassicPress is a modified and enhanced version of WordPress that serves the business website market."
I rescind this petition.
@Peter B: If You don't want allow user to upload svg, make it by permission, i mean more like everybody puts own logo to theme, Often vector logo is converted to .png in this case instead of svg. If library don't support .svg You must replace header in child theme and hard code in template this .svg then it shows...
Also cutting logos to pixels for retina formats are work for dummies instead of one scallable vector graphic
@Daniel Hendricks: I am not sure you understand how these petitions work. They don't "belong" to the person that started them. Once created, they become a proposal that others, who are sufficiently interested, my comment upon. So you can't "rescind" a petition. Other people can continue to comment on this one and/or vote for it as they wish.
I don't understand why you would want to rescind it anyway. Surely you don't expect every proposal you make to be accepted unconditionally by everyone who comments. ClassicPress is committed to a transparent decision-making process. That means that people are free to disagree with one another just as much as they are free to agree with one another.
@Tim Kaye -
<blockquote>Once created, they become a proposal that others, who are sufficiently interested, my comment upon. So you can't "rescind" a petition.</blockquote>
I understand that. Everyone is free to continue to discuss the disadvantages of native SVG support. Perhaps I should have said that I am backing out of the debate rather than rescind. The value of vectors is not a debate in my mind. I understand that opinions vary.
<blockquote>I don't understand why you would want to rescind it anyway. Surely you don't expect every proposal you make to be accepted unconditionally by everyone who comments.</blockquote>
If the group doesn't like SVGs, that's fine (you certainly are not alone). However, asking for native support from folks who feel that PNG/JPG are good enough and don't see value in SVG is an exercise in futility. It's almost 2019, we have devices with ever-increasing resolution and there is a continued push for lean & accelerated mobile pages, but you are free to continue to solely use raster images.
Fortunately, rasters are already supported and Ma.tt agrees with you. It was worth a shot, the Safe SVG plugin (and others) continue to be very solid options, and of course, it's not difficult to link to unsupported file types outside of Media Library.
@Daniel Hendricks: I still don't think you get it. You write, for example:>If the group doesn't like SVGs, that's fine (you certainly are not alone).
Who says "the group" doesn't like SVGs? On this thread, you have one commenter who has expressed disagreement with your suggestion, and one commenter who clearly agrees with you. You also have 11 votes for this petition, one of which is from me.
Like you, I use a ton of SVGs on my sites, and I make them all myself, so there is no danger involved. Like you, I think it's ridiculous that I have to install a plugin or write code to enable me to upload and use them. I do, however, recognize that Peter B has raised a legitimate concern. And the ClassicPress committee has already taken a vote that we will pursue a security-first approach. But it is possible to reconcile all this.
So I would modify this petition so that SVGs are supported by default when uploaded by administrators (i.e. tie this to the manage_options capability). That way, there is no enhanced risk, while people like you and I can upload and use SVGs to our heart's content without the need for a plugin.
<blockquote>So I would modify this petition so that SVGs are supported by default when uploaded by administrators (i.e. tie this to the manage_options capability).</blockquote>
To further this and Dominiq's point, perhaps enabling/disabling this ability could be a <a href="https://petitions.classicpress.net/posts/136/new-settings-submenu-security">Security</a> setting (checkbox?), maybe with a possibility to allow by role and/or capability.
Point being, I feel like there are options, with no need to throw the baby out with the bathwater. As another example, there is always the risk that users may upload copyrighted images off of Getty or GIS, resulting in a very unpleasant letter from their attorneys. It shouldn't mean that all images should be banned entirely (?).
>To further this and Dominiq's point, perhaps enabling/disabling this ability could be a Security setting (checkbox?), maybe with a possibility to allow by role and/or capability.
That's one option. Others would be to provide a filter or use a constant on the wp-config.php file, so that the capability could be extended to other roles or users very explicitly and by someone who presumably knew what s/he was doing. I'm not sure which of these options would be best.
But like everything else mentioned (including your note about constants), perhaps it could be an option just like ALLOW_UNFILTERED_UPLOADS provides.
So, something like ALLOW_SVG_UPLOADS ..
Yes to both of those suggestions!
I'm voting for this petition because correctly implemented SVG support is something I'd really like to see, but in this case there are very good reasons why WordPress has not adopted SVG uploads. Required reading before doing anything here: https://core.trac.wordpress.org/ticket/24251
SVGs are not just images, they are full-blown XML applications, with all the capabilities and risks that implies.
> 1. Name me a Fortune 500 web site that doesn't use SVG.> 2. I have thousands of SVGs that I have created. If you have a place that I can send them, I challenge you to find a security threat.
This is missing the point due to lack of understanding of the issues involved.
Only Administrator level users can be allowed to upload unsanitized SVG files. Otherwise, an Author level user who can upload files can craft a malicious SVG with code that will allow them to compromise other Administrator accounts (upgrade their own privileges on the site).
Ok, once the security issues with uploading SVGs at all are solved... how do we display them on a page? There are a lot of trade-offs to be made here too, and you'll either end up with a solution that doesn't work for everyone, or an explosion of options, with all-new code that needs to be tested and refined.
There are other trade-offs to consider too. Again I'm all for including SVG support, and all of this is solvable given infinite time and skill, but it is a deceptively hard change.
> Automattic's war on SVG is madness in an era of high DPR displays
I am not sure where this came from, Automattic makes extensive use of SVG files in almost all their products, and WordPress uses them in several places too.
In general it is a good idea to do a bit of research about an idea before jumping to conclusions like this. Chances are, if there is an idea that seems obvious like this, someone has already proposed it to WordPress, and the best thing to do to move the discussion forward is to look into that history.
I think there is some crossover between this proposal and the proposal for WebP support, since inserting inline SVGs into posts, in my mind, would be a part of a comprehensive push for SVG support.
> I think there is some crossover between this proposal and the proposal for WebP support
Agreed, in particular the idea to convert image embeds into shortcodes would open up a lot of flexibility for handling more complicated formats.
If shortcodes for images are implemented, they still must show images in the visual tab. Similar to how Youtube links are displayed/embedded in the visual editor.
YouTube is done slightly differently, with the Embed API, but it would need an interface like we currently have with galleries.
+1 SVGs a really important. A permission-controlled upload (which is per default just enabled / set for administrators) would be enough. The admin can decide form himself (and the security for his own website), who can upload SVGs and who cannot.
But, just for technically uninformed people, it would be great to show a second notification (explaining about the security risk) if he tries to enable this permission for Subscribers / Default Users. I guess this role should never receive this ability (I mean, on which website are you able to upload SVGs, except Graphic / Design pages), but everyone should make this decision themselves.
This proposal, and the overly angry comments, and the amount of up votes, are another embarrassing thread for ClassicPress and betray the immaturity and lack of consideration that is involved in the project thus far...
If you all want ClassicPress to be blacklisted from every web host out there, go ahead with adding this foolish feature.
> I mean SVGs are great i really like them, but the issue is that they are not images but structured data files with a plethora of possible security issues
> Only Administrator level users can be allowed to upload unsanitized SVG files.
Not good enough, a CMS Core needs guaranteed security.
A quick Google search reveals every major CMS blocks SVG uploads by default and they have to be manually allowed:
>This proposal, and the overly angry comments, and the amount of up votes, are another embarrassing thread for ClassicPress and betray the immaturity and lack of consideration that is involved in the project thus far...
You seem to be taking the opinions of a few people here as the opinion of the project as a whole. This is not the case, and situations like this one have already been carefully considered and planned for.
https://www.classicpress.net/democracy/#democracy-conduct says "Be good to one another, take criticism well and follow the democratic process", but https://www.classicpress.net/democracy/#democracy-exceptions says "Decisions and actions required to address security issues" are exempt from the democratic process.
In this case, the decision and action is that this isn't getting in until/unless the security issues can be definitively solved.
> > Only Administrator level users can be allowed to upload unsanitized SVG files.>> Not good enough, a CMS Core needs guaranteed security.
This point is worth discussing further. What is the difference between unfiltered_html, which administrators already have, and the ability to upload SVGs?
@James My apologies, I know I'm arriving late. Based on the strong comments, it seemed like a strongly worded response was appropriate since nobody cited references. It does seem like many features are being hurried based on the input of just a few people received during a rather narrow time frame.
The exception rule in Democracy would seem to be designed to improve security such as reacting to zero day vulnerabilities -- not for new features?
> This point is worth discussing further. What is the difference between unfiltered_html, which administrators already have, and the ability to upload SVGs?
Also there is already an unfiltered_uploads filter to allow any MIME types, which is disabled by default and can be specified by web hosts.
So considering future compatibility with page builders and yes, even Gutenberg for those users who want to install it with ClassicPress, I'd suggest maybe:
deprecating unfiltered_html (mostly effects Classic Editor)
allowing add-on page builders to decide re: raw HTML blocks, etc which forces a reduction in security to be a conscious choice, of sorts...
retaining support for unfiltered_uploads or instead, consider a replacement filter where web hosts can define a list of allowed file extensions
This present more consistent logic: that the Core CMS is secure by default but an Admin-level user can choose to enable raw HTML snippets by installing add-on plugins like a page builder or even a Shortcode manager plugin. And by default, a strict list of allowed MIME types, but an Admin-level user can either enable unfiltered uploads or their web host can choose to do so. From a web hosting perspective, dangerous file types are a bigger concern than raw HTML because their firewalls like ModSec etc can still analyze the raw HTML if needed but if a malware Flash file gets uploaded it's a bigger concern, so this logic would empower sysadmins to retain a bit more control over MIME type security...