Support

Account

Register Login

Home › Forums › General Issues › Question about updates coming in 6.2.7

Solved

Question about updates coming in 6.2.7

  • I inherited several sites created years ago. The developer did not use esc_html, esc_attr, or esc_url when outputting the_field(). I’m hoping I won’t have to manually escape all instances (hundreds) of the_field() when 6.2.7 releases, because it appears that will now be handled automatically.

    Is that correct? I’m sure hoping so. That would save me many, many hours of work.

  • This is only the case if the developer used the_field() and the_sub_field() to output field values. It is not the case if the developer used get_field() and get_sub_field().

  • Hi John,

    Thanks for your reply. Just to be sure I understand, if the developer did this:

    <?php if (get_sub_field('right_heading')) : ?> <h2><?php the_sub_field('right_heading'); ?></h2> <?php endif; ?>

    then 6.2.7 will properly escape the H2 element? However if the developer did this:

    <?php if (get_sub_field('right_heading')) : ?> <h2><?php echo get_sub_field('right_heading'); ?></h2> <?php endif; ?>

    then it will not escape the H2 element. Is that correct?

  • Yes

  • Thank you John.

  • I have a similar situation. Would I correct this:

    <?php if( have_rows('page_content') ): ?>
	<?php while( have_rows('page_content') ): the_row(); ?>
		<?php if( get_row_layout() == 'page_content' ): ?>
			<div class="training">	
			<?php the_sub_field('page_description_100'); ?>
			</div>
			<br>
		<?php endif; ?>
	<?php endwhile; ?>
<?php endif; ?>

    By using this?

    <?php if( have_rows('page_content') ): ?>
	<?php while( have_rows('page_content') ): the_row(); ?>
		<?php if( get_row_layout() == 'page_content' ): ?>
			<div class="training">
			<?php echo esc_html( the_sub_field('page_description_100') ); ?>
			</div>
			<br>
		<?php endif; ?>
	<?php endwhile; ?>
<?php endif; ?>

    The notice is still visible in the dashboard. (I’m using the classic editor with some CF7 and YouTube in the WYSIWYG field.)

    Thanks in advance!

  • If you’re using the_field() or the_sub_field() no changes are needed to escape values, see the announcement https://www.advancedcustomfields.com/blog/acf-6-2-5-security-release/.

  • Hi John,

    One further question. What, if anything, will happen if the_field() is already escaped? Like:

    <h3 class="modal-headline">"<?php esc_html( the_field('headline') ); ?>"</h3>

    Will wp_kses() be added to an already escaped element like this?:

    wp_kses( esc_html( the_field('headline') ) );

    Will that cause any problems?

  • Hi.

    I am only using the shortcode [acf field="field_name"] but the ACF message in WP backend says:

    field_name () – rendered via acf_shortcode

    What should I do or at least what do I have to check?

  • @banacan

    No, will act as though it was
    esc_html( wp_kses( the_field('headline') ) );

  • @austriadesign there is nothing that can be done to prevent ACF from escaping values when using the ACF shortcode.

    If you have values in these fields that you don’t want to be cleaned then you will need to build your own shortcode that uses get_field() to get the value and echo it to bypass ACF.

  • @hube2 So all shortcodes will broke in the next update, right? I also use the function to enable the new behavior with

    add_filter( 'acf/the_field/escape_html_optin', '__return_true' );

    But all shortcodes still work as it is only text based or did I misunderstand stgh?

  • It will have no effect on text based fields. This will only cause an issue if you have HTML or script tags in the field value that would be affected by wp_kses()

  • That‘s what I‘ve read and understand. But I don‘t know why I get this warning with info of one special custom field I am using with simply a text/date value … maybe I should create a support ticket?

  • I have not seen these warnings myself.

    What page are you on when you see the warning?
    Do these warnings appear on the page that you’re editing?
    Can you tell me the contents of the field that is giving the warning?

  • Warning is only shown in the backend but not in front end

  • ACF PRO — ACF now automatically escapes unsafe HTML when rendered by the_field or the ACF shortcode. We’ve detected the output of some of your fields will be modified by this change. Learn how to fix. Hide details

    datum_beginn () – rendered via acf_shortcode

  • A date field should not be causing an issue. What is the return format for the date field?

  • date format is ‚d.‘ as I only need the first numeric day of the month.

  • as in ‚d.'

    I think you might want to contact support about this because it might be an error. If there is an ' in the formatting this might be changed to &apos; It it is a curly single quote that could also me altered to an html entity when escaped. This minor change could be triggering the warning.

    I say this because there was another reported case where & in the field content was triggering the warning.

  • Oh sorry, the quote is only for this post. Date format is set correctly on the website.

  • 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?

  • Yes, you just need to change the_field() to echo get_field() and the_sub_field() to echo get_sub_field() I was told by the developers that it will not affect get_field() or get_sub_field().

  • Thank you @hube2. I noticed this indeed makes my forms work. Also, if I have a wysiwyg field and I get it like the_sub_field it will work without errors but only if I don’t have any formatting. As soon as I actively align the text left, right or justify i get errors like below. If I call the field with echo get_sub_field these errors don’t show up:

    Detected Potentially Unsafe HTML Modification
#0 /home/client1/web/client1website.nl/public_html/wp-includes/class-wp-hook.php(324): print_backtrace_for_unsafe_html_removal('...', '...', Array, false)
#1 /home/client1/web/client1website.nl/public_html/wp-includes/class-wp-hook.php(348): WP_Hook->apply_filters(NULL, Array)
#2 /home/client1/web/client1website.nl/public_html/wp-includes/plugin.php(517): WP_Hook->do_action(Array)
#3 /home/client1/web/client1website.nl/public_html/wp-content/plugins/advanced-custom-fields-pro/includes/api/api-template.php(942): do_action('...', '...', '...', Array, false)
#4 /home/client1/web/client1website.nl/public_html/wp-content/themes/client1/page.php(108): the_sub_field('...')
#5 /home/client1/web/client1website.nl/public_html/wp-includes/template-loader.php(106): include('...')
#6 /home/client1/web/client1website.nl/public_html/wp-blog-header.php(19): require_once('...')
#7 /home/client1/web/client1website.nl/public_html/index.php(17): require('...')

    Can I expect any impact on performance when calling all fields with echo get_field / echo get_sub_field?

  • There will be no change in performance between get_field() and the_field()

Viewing 25 posts - 1 through 25 (of 28 total)
1 2

You must be logged in to reply to this topic.