Appender "+" stops working after update to WP 6.8

[MannyAdumbire]

Description

The "+" block appender button no longer shows up on a custom block, after updating to WordPress 6.8.
Reverting the core update restores the ability to add navigation links.

I tested adding 'core/paragraph', to the allowedBlocks returned in BlockEdit's inner blocks - this restores the appender button on mouse hover, BUT clicking on the button still does nothing.

No other blocks appear to have been affected, except this custom block.

Any insights or suggestions on how to manually restore the ability to add navigation links will be much appreciated!

Step-by-step reproduction instructions

1. Add the attached block(below) to your theme running on WP 6.8 or higher.
2. Add a subpages menu block to a page
3. Within the subpages menu, try to add navigation links.

subpages-menu-block.zip

Screenshots, screen recording, code snippet

No response

Environment info

The issue happens in WordPress 6.8
It does not happen in WordPress 6.7.2

in index.js:

import { registerBlockType } from '@wordpress/blocks';
import { InnerBlocks } from '@wordpress/block-editor';

import { BlockEdit } from './edit';
import metadata from './block.json';

registerBlockType(metadata, {
	edit: BlockEdit,
	save: () => <InnerBlocks.Content />,
});

in edit.js:

export const BlockEdit = (props) => {
	const { setAttributes, clientId, context, name } = props;
	const { postId, postType } = context;
	const blockProps = useBlockProps();
	const innerBlocksProps = useInnerBlocksProps(
		{},
		{
			allowedBlocks: ['core/navigation-link', 'core/navigation-submenu'],
		},
	);

	const { blockCount } = useSelect((select) => {
		const { getBlockCount } = select('core/editor');

		return {
			blockCount: getBlockCount(clientId),
		};
	}, []);

	const currentEditedMeta = useSelect(
		(select) => select('core/editor').getEditedPostAttribute('meta'),
		[],
	);

	const postParentId = useSelect(
		(select) => select('core/editor').getEditedPostAttribute('parent'),
		[],
	);

	const inheritFromParent = postParentId ? currentEditedMeta.inherit_from_parent : false;

	useEffect(() => {
		if (!IsRevision()) {
			setAttributes({ currentPostId: postId });
		}
	}, [postId, setAttributes]);

	return (
  <div {...blockProps}>
    <InnerBlocks
      tagName="ul"
      allowedBlocks={[
        'core/paragraph',
        'core/navigation-link',
        'core/navigation-submenu'
      ]}
      defaultBlock={['core/navigation-link', {}]}
      directInsert
    />
  </div>
);
};

in block.json:

	"$schema": "https://schemas.wp.org/trunk/block.json",
	"apiVersion": 3,
	"name": "org/subpages-menu",
	"title": "Subpages menu",
	"category": "theme",
	"icon": "menu",
	"description": "Display a subpages menu that can be shared with child pages. On RCILs, this also displays the logo.",
	"attributes": {
    "currentPostId": {
      "type": "integer"
    },
    "postParentId": {
      "type": "integer",
      "default": 0
    },
    "inheritFromParent": {
      "type": "boolean",
      "default": false
    },
    "isServerPreview": {
      "type": "boolean",
      "default": false
    }
  },
  "usesContext": [
    "postId",
    "postType"
  ],
	"supports": {
		"html": false,
    "multiple": false
	},
	"textdomain": "org-theme",
	"editorScript": "file:./index.js",
	"editorStyle": "file:./editor-style.css",
	"viewScript": "file:./subpages-menu.js",
	"style": "file:./style.css",
	"render": "file:./markup.php"
}

Please confirm that you have searched existing issues in the repo.

• Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

• Yes

Please confirm which theme type you used for testing.

• Block
• Classic
• Hybrid (e.g. classic with theme.json)
• Not sure

[DarkMatter-999]

I am able to reproduce the bug from the code mentioned.

As mentioned the '+' button works on version: 6.7.2

Screen.Recording.2025-06-03.at.3.21.42.PM.mov

On version: 6.8.1 only the paragraph block is added and not the navigations

Screen.Recording.2025-06-03.at.3.23.27.PM.mov

[karthikeya-io]

This happens because of the parent attribute in block.json. In version 6.7.2, I had some blocks with incorrect parent attributes that used to work fine. Starting from version 6.8, if a child block has a parent attribute, it can only be added to the specified parent blocks.

For example, core/navigation-link and core/navigation-submenu have core/navigation defined as their parent in block.json. Therefore, you're unable to add these blocks to your custom block.

A temporary fix would be something like this, I hope this works:

add_filter(
	'block_type_metadata_settings',
	function ( $settings, $metadata ) {

		if ( 'core/navigation-link' !== $settings['name'] ) {
			return $settings;
		}

		$parents = isset( $settings['parent'] ) && is_array( $settings['parent'] )
			? $settings['parent']
			: array();

		if ( ! in_array( 'org/subpages-menu', $parents, true ) ) {
			$parents[]          = 'org/subpages-menu';
			$settings['parent'] = $parents;
		}

		return $settings;
	},
	10,
	2
);

[MannyAdumbire]

@DarkMatter-999 thanks for the confirmed test and recordings. :)

@karthikeya-io The enforced parent attribute was exactly the issue I was having. Thanks for your suggestions and code fix - adding nav links to the block is working again!

I'm curious where in WP core codebase would this change was made, or if there is a related Trac or GH ticket for strict parent attributes checks?

[karthikeya-io]

I see there were several PRs/changes that modified the inserter in 6.8 to improve its performance and working. But I believe this specific behaviour was introduced in PR #65700.

As I understand it, up to version 6.7, a block could be inserted as a child if it was listed in the parent block’s allowedBlocks property, even if the child’s parent property didn’t match. But starting in 6.8, the inserter also checks the child block’s parent attribute when inserting it.

I think the following parts of the code enforce the parent attribute:

gutenberg/packages/block-editor/src/store/selectors.js

Line 1628 in faa2c90

if ( parents.length > 0 ) {

gutenberg/packages/block-editor/src/store/selectors.js

Line 1669 in faa2c90

if ( ! isBlockVisibleInTheInserter( state, blockName, rootClientId ) ) {

[Mamaduka]

Inserting a block into an unsupported parent can lead to unexpected behavior. I understand that some might have relied on this "feature" in the past, but we shouldn't consider an accidental bug as a feature.

@oandregal, @youknowriad, what do you think?

[t-hamano]

Inserting a block into an unsupported parent can lead to unexpected behavior. I understand that some might have relied on this "feature" in the past, but we shouldn't consider an accidental bug as a feature.

I agree with this. Consumers who really want to insert blocks into unsupported parents can use workarounds like this comment.

[tcmulder]

Note that the appender will now also not appear given the following code—Is this no longer recommended?

const Edit = (props) => {
	const { className } = props;
	const blockProps = useBlockProps({
		className: classnames('some-class', className),
	});
	const innerBlocksProps = useInnerBlocksProps(blockProps, {
		template: [['core/paragraph']],
	});
	return (
		<div {...innerBlocksProps}>
			{innerBlocksProps.children}
		</div>
	);
};
export default Edit;

This follows the example in the docs that say:

This hook can also pass objects returned from the useBlockProps hook to the useInnerBlocksProps hook. This reduces the number of elements we need to create.

I've used this on many of my blocks because it eliminates the inner div, giving me just one clean wrapper div with children inside it, and previously had no downside.

As a workaround, I've started doing:

import { InnerBlocks } from '@wordpress/block-editor';
const Edit = (props) => {
	const { className } = props;
	const blockProps = useBlockProps({
		className: classnames('some-class', className),
	});
	const innerBlocksProps = useInnerBlocksProps({}, {
		template: [['core/paragraph']],
		renderAppender: InnerBlocks.ButtonBlockAppender, // < this is new
	});
	return (
		<div {...innerBlocksProps}>
			{innerBlocksProps.children}
		</div>
	);
};
export default Edit;

This works functionally, but stylistically it's a little weird since ButtonBlockAppender is big and styled quite differently than the normal small appender button.

Edit: Actually, I can use InnerBlocks.DefaultBlockAppender for the normal appender. Still not certain if this is recommended any longer to eliminate the redundant div.

[t-hamano]

@tcmulder

This works functionally, but stylistically it's a little weird since ButtonBlockAppender is big and styled quite differently than the normal small appender button.

If you want to use a smaller appender, use undefined.

For example, the Column block dynamically changes the appender type depending on whether it has a child block or not.

gutenberg/packages/block-library/src/column/edit.js

Lines 127 to 129 in 362e12d

	renderAppender: hasChildBlocks
	? undefined
	: InnerBlocks.ButtonBlockAppender,