Archived topic
SVG Sprite with Generateblocks icon function
5 replies · Started by Alexander on September 25, 2020
Hello GP-Team,
I am using Generatepress 3.0 beta2 and the latest GP Premium RC with Generateblocks on a site that I am currently working on.
Previously I was using an SVG sprite sheet for a handful of icons that are being used throughout the site like so:
<svg class="mysvgicon"> <use xlink:href="/wp-content/themes/mytheme/svg/si-sprite.svg#si-entypo-brush"></use></svg>
Now I am trying to do the same with the icon option in Generateblocks but my code seems to fall victim to sanitization.
What would be a good way of getting this to work?
Also, do you recommend using the Generateblocks Headline block for paragraphs over the default Wordpress paragraphs?
Thanks in advance!
Hi there,
The GB Icon field will only accept an inline SVG - you cannot use xlink:href at this time. That maybe something we review in the future but that method doesn't have the best browser support....
Paragraphs - no we recommend you use a Paragraph block. Reserve using the Headline Block when you need to create a different styled element to those the Customizer body/heading typography provides.
Hello David,
that is too bad. It would be great if this could be supported in a future version.
I noticed that xlink is being depreciated and the recommended way of linking is now plain href.
Browser support seems OK with the exception of IE naturally but can be worked around with something like https://github.com/jonathantneal/svg4everybody
I believe that a saw a post by Tom in the past with some code that lets you bypass the sanitization (could not find it again via search now). Since I am the only person that will be working on/having publishing rights on the site, do you think this would be a feasible option?
Theres this article which covers the WP sanitization:
https://docs.generateblocks.com/article/fix-svg-icons-not-saving/
Not aware of anything that excludes DomPurify from the code.
Ill pass this on to Tom.
There is no way around DOMPurify at this time. Not sure if we'll work that in, but it's worth looking to see if we can allow this sort of implementation safely.
That would be great. I do think that having a cache-able spritesheet does have benefits and support for it seems quite good with some exceptions.
