ACF blocks using `acf_inline_toolbar_editing_attrs()` and `acf_inline_text_editing_attrs()` spill internal attributes over into frontend markup

Open
  • Is something wrong?
#1,021 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
52/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Quiet
Tech stack
php
Domain
frontend, web-dev

Research direction

Start with acf_inline_toolbar_editing_attrs() and acf_inline_text_editing_attrs(), then reproduce the markup in both the block editor and frontend using the provided PHP example. Compare the generated attributes and the acf_is_block_editor() behavior. Done means internal inline-editing attributes appear only in the block editor without removing them there.

Written by the indexing model from the issue text.

Description

Describe the bug
When using acf_inline_toolbar_editing_attrs() and acf_inline_text_editing_attrs(), it works as expected in the block editor: all of the html attributes ACF uses are there:

<div data-acf-inline-fields-uid="block_...description2" data-acf-inline-fields="[{...}]" role="button" tabindex="0" class=" text-black/80 prose text-lg" style="pointer-events: all;">...</div>

However, there is no guard against exposing this on the frontend too, making the somewhat sensitive internal ACF info, field names etc. visible to potential malicious actors.

It also messed up screen reader support, as it inserts role="button" and tabindex="0" to divs and other elements that should not be labeled as such.

I believe this to be a regression as this didn't use to happen.

Messed up markup in devtools

To Reproduce

  1. Create an ACF Block using the Blocks V3 API and add a wysiwyg field or another unrenderable field in the new inline editing experience
  2. Use acf_inline_toolbar_editing_attrs() or acf_inline_text_editing_attrs() to surface an unsupported attribute which would normally require opening the sidebar or expanded editor, like so:
<div <?= acf_inline_toolbar_editing_attrs( [ 'description1' ] ); ?> class=" text-black/80 prose text-lg">
    <?= wp_kses_post( get_field( 'description1' ) ?? '' ); ?>
</div>
  1. Examine the markup generated in the block editor and frontend portions
  2. See the issue

Expected behavior
There should be a guard to only show these in the block editor. I wrote my own:

function helper_acf_inline_toolbar_attrs( array $fields, array $args = array() ): string
{
	if ( ! acf_is_block_editor() )
		return '';
	return acf_inline_toolbar_editing_attrs( $fields, $args );
}

However, i found that the acf_is_block_editor() function isn't 100% reliable and sometimes fails, fully removing the inline toolbar attributes, but that's probably a separate bug report. But it means that i cannot use it as it breaks, and haven't found a suitable workaround. If someone more knowledgeable in ACF could recommend me what guard method to use instead that works 100% that would solve my issue, however i believe this should be fixed in ACF itself.

Version Information:

  • WordPress Version: 7.0.2
  • PHP Version: 8.4
  • ACF Version: ACF Pro 6.8.5
  • Browser: Firefox(Zen Browser) 152.0.6
Dominant language
PHP
Stars
947
Forks
198
No merged PRs in 30d

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from AdvancedCustomFields/acf

All issues in AdvancedCustomFields/acf

Similar issues

More PHP issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.