Remove duplicate hidden post from Query Loop block

[Utsav-Ladani]

What?

Closes #58889

Remove duplicate hidden post from Query Loop block in block editor to keep same post order as frontend. Check #58889 for more details.

Why?

Address the CSS selector issue and ensure consistent UI across both the Block Editor and the Frontend.

How?

Conditionally rendering block or preview based on active block context instead of always rendering preview.

Testing Instructions

1. Add the Query Loop block.
2. Inspect the loop list in Chrome DevTools. It should contain a number of items that matches the number of visible posts.
3. The Frontend and the Block Editor should display the same UI.
4. Ensure that the UI doesn't flicker when selecting a post with a position greater than 1. (Refer Query loop block: Wide alignment not working correctly on the editor #33248).

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Unlinked Accounts

The following contributors have not linked their GitHub and WordPress.org accounts: @caseymilne.

Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Unlinked contributors: caseymilne.

Co-authored-by: Utsav-Ladani <utsavladani@git.wordpress.org>
Co-authored-by: SirLouen <sirlouen@git.wordpress.org>
Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>
Co-authored-by: andrewserong <andrewserong@git.wordpress.org>
Co-authored-by: ntsekouras <ntsekouras@git.wordpress.org>
Co-authored-by: jordesign <jordesign@git.wordpress.org>

At least one ghost was discovered. ghosts represent deleted GitHub user accounts.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[SirLouen]

@Utsav-Ladani have you researched which was the original purpose of that isHidden property?

[Mamaduka]

have you researched which was the original purpose of that isHidden property?

This is important. I would recommend doing the same every time you want to remove something from the codebase. Context is key when it comes to large, old projects.

cc @andrewserong, @ntsekouras, I think you both worked on this area a while back.

[andrewserong]

Thanks for the ping!

Things might have changed as the original code to add the duplication was added quite a long time ago, but it was added to ensure that there's a seamless and non-flickery behaviour when users click between the different instances of items within the query loop in the editor. It was most visible on loops that involved background colors or lots of blocks, or things like that where the flickering is more obvious.

Anecdotally, with this PR checked out, I can see the flicker again when clicking between instances of a query loop (i.e. clicking between the first and second posts within the editor canvas). The flicker is intrusive, but unfortunately also very brief so in a video demoing it, it doesn't quite capture it properly. Hopefully this video captures it a little:

2025-12-02.15.02.32.mp4

[ntsekouras]

Yeah, this code is about the flickering that occurs when we change the active block context and we can't just remove it. You could explore a possible different way for this, but I have no suggestions of a better way to achieve this.

[Utsav-Ladani]

Thanks @andrewserong for catching the issue.

This flicker is happening when used a group block with top-bottom padding. Earlier, I tested this bug with templates which don't have padding, so didn't catch the issue. However, I noticed same issue with trunk branch as well when selecting a block place at position >1.

The reason behind this flicker is that the block rendered twice – first w/ undefined styles and then w/ top-bottom padding styles. So it appears as flicker because of immediate block height change.

@ntsekouras I backtracked this behavior and found that a component named BlockProps is causing this issue. Check following code. Here it's using useEffect to set the wrapperProps and the block padding is part of it. Since it's using useEffect, it first renders a block with undefined styles, and then set block padding during re-render.

gutenberg/packages/block-editor/src/hooks/utils.js

Lines 572 to 598 in 48a6e8a

	function BlockProps( {
	index,
	useBlockProps: hook,
	setAllWrapperProps,
	...props
	} ) {
	const wrapperProps = hook( props );
	const setWrapperProps = ( next ) =>
	setAllWrapperProps( ( prev ) => {
	const nextAll = [ ...prev ];
	nextAll[ index ] = next;
	return nextAll;
	} );
	// Setting state after every render is fine because this component is
	// pure and will only re-render when needed props change.
	useEffect( () => {
	// We could shallow compare the props, but since this component only
	// changes when needed attributes change, the benefit is probably small.
	setWrapperProps( wrapperProps );
	return () => {
	setWrapperProps( undefined );
	};
	} );
	return null;
	}

I tried using useLayoutEffect and flicker is gone, but I don't have much context around the BlockProps component. Could you please help me to understand it?

CC: @SirLouen @Mamaduka

[SirLouen]

@Utsav-Ladani we need to think on a better workaround than using useLayoutEffect to sort this out.

[Utsav-Ladani]

@SirLouen I have an another solution which seems to break the Rules of React by calling hooks inside the loop.

However, we are always using fixed number of features, so there will be no situation when those hooks are called in different order, so indirectly we are not breaking any Rules of React.

I pushed my solution to this PR in case you wanna test.

[SirLouen]

@SirLouen I have an another solution which seems to break the Rules of React by calling hooks inside the loop.

To be sincere, I don't have a clear opinion on this idea.
I would like to hear someone else. I would like to hear from @ellatrix, as she did most of this section back in the day.

[Utsav-Ladani]

Hey @ellatrix, any insight on the above approach?