Hi,
Unfortunately, allowing HTML in these fields poses a security risk through cross-site scripting (XSS), which was discovered a few months back (check the forum; there’s an extensive thread about this issue and feedback from users) and made the entire plugin unavailable to download. My options were to limit HTML usage or ditch the entire plugin so nobody could download it anymore.
I had to comply with limiting HTML, which is why your code doesn’t render as expected. But I do agree: there should be a better compromise.
In case you don’t know, adding HTML directly into the “Edit post” page in the meta box is still possible. Maybe that’s enough until I’ve balanced out security vs. usability.
If you give me a more detailed explanation of how you use(d) to add HTML (where, what fields, what HTML), I could include it in the test for the next version and try to have these pass.
Thanks for your fast reply. O.K. a security issue. That’s a pitty 🙁
I really used the HTML to show font awesome symbols (<i class= “fa fa-envelope-open></i> (for open discussion) or fa fa-youtube-play (for a YouTube video). Those font awesome symbols have been very informative for the user… if you like you can check some pages of my site “airvox.ch” – it would really be great to be able to use font awesome symbols in the subtitle with the “i” tag… thank you very much for further investigating. 🙂
It’d be easy to allow certain tags, i.e. <i> for Font Awesome icons. Forum rules don’t allow me to give you the code snippet to do just that, unfortunately.
However, I have to draw a line somewhere. The <script> tag is not the only one that can be abused. But at this point, I’m considering opening the <i> tag unless I find a more reliable solution that doesn’t make my plugin end up on a blacklist again 😉
BTW: AfD sucks. Muss einmal gesagt werden :p