Sorry to hijack this post, but I didn’t want to start yet another on the subject.
I have several sites that will be affected by this update and I am trying to find a concise and absolute answer to my question.
I’ve read the ACF 6.2.5 Security Release post several times and a lot of the comments and replies, most of which seem very ambigious, and I’m still not 100% sure I fully understand how to fix the incoming issues. So I’m hoping if I ask a concise and speficic question, I might get a concise answer.
On the majority of the sites my ACF data is called using echo get_field()
, echo get_sub_field()
, or more recently storing get_field()
as a variable and then accessing the data via the variable, eg. echo $variable_name['field_name'];
.
There are several instances where <iframe>
or <script>
tags are present on these sites, eg. third-party CRM integrations, Google Analytics, etc. Obviously I need these to continue working as they do at present.
There area a few unique places where I have used the_field()
or the_sub_field()
to output some <iframe>
or <script>
tags, most commonly this is used to output Google Analytics code in the <head>
.
My question is, do I simply need to change any instance of the_field()
and the_sub_field()
to echo get_field()
and echo get_sub_field()
? Or is there more I need to do?
I initally thought that was the case after reading:
…if you’re confident you can trust every user registered on your site with contributor or higher access—we recommend you use
echo get_field()
to output this unsafe HTML to ensure it’s not filtered.
But I have since seen some replies in the comments and this week’s Chat Friday Q&A that have made me question what I thought was a simple change, like:
Q: Does the escaping only happen if we use the ACF shortcode, but not if we use something like the_field or get_field?
A:: In 6.2.5, this only happens for the ACF shortcode, but in a future release (likely 6.2.7), it will also happen when using the_field or get_field. However, ACF 6.2.5 displays a warning when the_field or get_field are being used in a way that could output unsafe HTML. The warning message is included to give you a chance to get ahead of this change.
The mention of get_field()
being problematic in the future was not something I’d seen until then.
Would anyone care to clarify?
For anyone finding this via Google, the problem should now have been fixed in version 6.0.7, released today.
In fact, I’ve just tried it on a third site that I’ve been asked to make a change to and it’s doing it on there too; top button is problematic, botton button is fine.
Well it seems that suggestion there, to use the bottom button instead of the top button inside the flexible field to add child fields, is resolving the issue as far as being able to carry on working, but it’s not a permanent fix.
Also just to note, if using the top button the added field has a placeholder label of ‘New Field’ and a placeholder name of ‘new_field’ along with the ‘acfcloneindex’ key, instead of the expected empty fields with usual generated key when using the bottom button.
I’d be happy to supply the JSON file if you want to replicate it yourself?
No, nothing showing in the console.
I’ve also tried disabling all other plugins and it still happens.
Interestingly I’ve just turned on field keys and the one I’ve just added has a key of “acfcloneindex”.
This seems to be where the problem lies, it’s adding that field key and that’s resulting in the placement/label/name not being saved and the new field being added to the end of the repeater. Presumably because it doesn’t know where else it should be?
I’ve tried several different names and labels, same problem persists.
Is there a workaround for this yet?
Removing the option was a bad move, preselecting the “Convert into HTML” and allowing a choice for no formatting (along with the br/p options) would have been much more sensible.
We have clients entering raw HTML into textareas and there seems to be no way of preventing this, unless I’ve missed something?
Thanks
Oh wow, how embarrassing.
It was a long day yesterday and I seem to have missed the ‘s’ off the end of “award(s)_logos”…
Sorry to bother you and thank you for your help! 🙂
Welcome to the Advanced Custom Fields community forum.
Browse through ideas, snippets of code, questions and answers between fellow ACF users
Helping others is a great way to earn karma, gain badges and help ACF development!
We use cookies to offer you a better browsing experience, analyze site traffic and personalize content. Read about how we use cookies and how you can control them in our Privacy Policy. If you continue to use this site, you consent to our use of cookies.