Replacing & with & without changing all {{ }} to {! !}

I’ve got a request from a client that apparently uses a lot of & in their titles and they are getting frustrated by the fact that its showing up as &amp. Obviously, this is because I used {{ }} instead of {!! !!}. I’ve changed it in the specific places they’ve asked, but now they’ve asked me to switch everything over to use {!! !!} despite my advising them not to.

Is there a safe way to do this? Can I create a blade function or hook somewhere to find/replace &with & ? Or do I just need to into my views and replace all the {{ }} with {!! !!}?


I don’t think there’s anything clever you can do here. However, it’s important to make sure that you aren’t using {!! !!} entirely on its own. Be sure to escape data in some way like {!! esc_html($text) !!}.


Who has access to this field? Just your client, or is it public facing?

If it’s just your client I see no reason to run every field through {{ }}, unless you are really worried you client will try to XSS attack their own site.

1 Like

Thanks for the replies! I’ll probably go with the {!! esc_html($text) !!} method.

As far as who has access, yea its pretty much all being echoed from wordpress post fields and ACF custom fields. I figured if their site was hacked it, could it not help there too? Or are XSS attacks just from user input fields? If its not likely to get an XSS from data fields straight from a wordpress posts, should I just be using {!! !!} by default?

Anywhere can be vulnerable to XSS, but it is mainly user input.
My general rule is if it’s an attribute, use {{ }}. If it’s normal text content inside of an element, I use {!! esc_html($data) !!}.

But in general, default to {{ }}.

Thanks that’s helpul too!

Hmm. I wonder if there’s a clean way to pre-escape a bunch of those fields in the Controller? That would simplify the templates a bit and centralize some of the escaping/code hardening into one function.

Yes, you could definitely escape the data in the controller before using it in templates.

However, I always stick to escaping where I output the data as its a WordPress standard to do so.

It also means you’ll have 1 raw variable that can be reused and manipulated in different ways before being effected by escaping it.

This topic was automatically closed after 42 days. New replies are no longer allowed.