AdvancedCustomFields / AdvancedCustomFields/acf

WYSIWYG 'visual' tab in sidebar breaks when switching sidebar tabs

Open
#904 9 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
PHP
Stars
945
Forks
197
PR merge metrics
No merged PRs in 30d

Description

Describe the bug
When using an ACF WYSIWYG field in a sidebar metabox, the WYSIWYG editor breaks when you switch from the 'Page' tab to the 'Block' tab and back again.

To Reproduce
Steps to reproduce the behavior:

  1. Create an ACF WYSIWYG field and set it to show up in the sidebar. Code example is below to generate a basic WYSIWYG field.
  2. Create a new page in the Gutenberg editor
  3. Note you can interact with your WYSIWYG field, enter content, etc.
  4. Switch your tab in the top right from 'Page' to 'Block' then switch it back to 'Page'
  5. The WYSIWYG is no longer usable in the 'visual' view. You can switch to 'text' and change stuff, but the 'visual' is white with no text visible and not usable.

Expected behavior
The WYSIWYG should be usable no matter what tabs you switch to. It's not just when I manually switch from 'Page' to 'Block' and then back to 'Page'. When you add a block to a page, the editor will automatically switch the tab for you to 'Block'. Sometimes I'll be messing around with blocks then decide I need to go back to the 'Page' tab and edit my wysiwyg and it's broken.

Code

add_action( 'acf/include_fields', function() {
	if ( ! function_exists( 'acf_add_local_field_group' ) ) {
		return;
	}

	acf_add_local_field_group( array(
	'key' => 'group_6622e9af5e220',
	'title' => 'Test Sidebar WYSIWYG',
	'fields' => array(
		array(
			'key' => 'field_6622e9afb3cec',
			'label' => 'Test Sidebar WYSIWYG',
			'name' => 'test_sidebar_wysiwyg',
			'aria-label' => '',
			'type' => 'wysiwyg',
			'instructions' => '',
			'required' => 0,
			'conditional_logic' => 0,
			'wrapper' => array(
				'width' => '',
				'class' => '',
				'id' => '',
			),
			'default_value' => '',
			'tabs' => 'all',
			'toolbar' => 'full',
			'media_upload' => 1,
			'delay' => 0,
		),
	),
	'location' => array(
		array(
			array(
				'param' => 'post_type',
				'operator' => '==',
				'value' => 'page',
			),
		),
	),
	'menu_order' => 0,
	'position' => 'side',
	'style' => 'default',
	'label_placement' => 'top',
	'instruction_placement' => 'label',
	'hide_on_screen' => '',
	'active' => true,
	'description' => '',
	'show_in_rest' => 1,
) );
} );

Version Information:

  • WordPress Version: 6.5.2
  • PHP Version: 8.1.23
  • ACF Version: 6.2.9 (Pro)
  • Browser: Chrome Version 124.0.6367.60
  • Also repro in Safari Version 17.4.1 (19618.1.15.11.14) so doesn't seem browser specific

Additional context
I'm unsure when this broken (update to ACF or WP core) but was definitely recently working, as of at least last major WP version and a few updates of ACF back. This is producible using the WP 2024 theme with no plugins except ACF installed.

Contributor guide

No contributing guide indexed for this repository

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.

Research direction

Reproduce the issue in the Gutenberg editor with an ACF WYSIWYG field positioned in a sidebar metabox, using the provided field configuration and the reported WordPress and ACF versions. Switch from the Page tab to Block and back, then verify that the visual editor remains usable and its content remains visible.

Written by the indexing model from the issue text.

Assessment

Tech stack
php, wordpress
Domain
frontend
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.