is_admin() being ignored when inside the block editor

[maddisondesigns]

Description

I have a function that is using the the_title filter to insert <span></span> tags around any braces () within the page title. This is used simply so any text in braces can be styled a little different (i.e. reduce the font size).

This is the function:

/**
 * Add a span around braces () within page titles so they can be styled differently
 */
function mytheme_check_titles_for_braces( $title, $id = null ) {
	if( is_admin() ) {
		return $title;
	}

	if( strstr($title, "(") === false ) {
		return $title;
	}
	
	$title = str_replace( '(', '<span>(', $title );
	$title = str_replace( ')', ')</span>', $title );

	return $title;
}
add_filter( 'the_title', 'mytheme_check_titles_for_braces', 10, 2 );

If you're in the Dashboard (i.e. is_admin()), this function should just return the proper page title. If there's no opening brace ( in the title it assumes there's no braces and just returns the proper page title.

i.e. This function should only return the page title with a span tag, on the front-end.

When you're in the Block Editor, the Parent Page dropdown is returning the title with a span which would indicate that the the_title filter is being used, but is_admin() is being completely ignored (since it's returning span tags in the title).

Step-by-step reproduction instructions

• Add the above Filter to your theme's functions.php file
• Add a new page that includes braces in the page title e.g. "My Test Page (this is some text in braces)"
• Save the Page
• Create new Page and select the above Test page as the Parent Page and see the page title showing the braces

Screenshots, screen recording, code snippet

No response

Environment info

WP 6.2.2
Core (no Plugin)

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

[Mamaduka]

The block editor uses REST API to retrieve and save data. Therefore, you'll need to update the condition to check for REST requests.

See https://core.trac.wordpress.org/ticket/47394 and #11138.

[maddisondesigns]

@Mamaduka So, you're saying that you've broken a core WP Function and still haven't fixed it?? Why??

The Block Editor is part of the WordPress Admin, and therefore checking is_admin() should work. Please reopen this issue. You either either need to fix Gutenberg or fix the core is_admin() function. It's totally irrelevant whether Gutenberg uses the REST API to retrieve and save data, or not. It's not acceptable to simply break functions that have been in existence and used by WordPress developers for years.

[maddisondesigns]

Adding in this (suggested) simple check

global $current_screen;

if ( ( $current_screen instanceof WP_Screen ) && $current_screen->is_block_editor() ) {
	return $title;
};

inside my above filter function, doesn't work.

And I can't use the current_screen hook to check, because that doesn't run on the front-end, and I specifically need this filter to execute on the front-end.

The only check that does seem to work is if I add the following, taken from this comment:

if ( defined( 'REST_REQUEST' ) && REST_REQUEST ) {
	return $title;
}

It's not acceptable that is_admin() no longer works across the whole of the WP Admin

[Mamaduka]

The is_admin() determines if you're on the admin page. The REST API isn't part of the admin pages, so settings is_admin to true will be incorrect.

The is_admin behavior you're expecting was never true for the REST API, and it shipped in WP core before the block editor.

[maddisondesigns]

It's totally irrelevant whether this has been an issue since before the Block Editor or not. is_admin is supposed to return whether you're on an Admin screen or not, so it needs to be fixed so that it takes into account REST API calls in the Block Editor. When you're on a page like mywebsite.com/wp-admin/post.php?post=1234&action=edit, as an example, you're in the WordPress Admin regardless of the technology used to render that page. There's only two states, you're either on the front-end or you're in the WP Admin, there's no in between. It doesn't matter whether you're using the REST API or not, there's still only two states, front-end or back-end.

[spacedmonkey]

Sadly, I believe this issue can not be fixed. This behaviour has existed in core for a long time. Changing it would be seen as a breaking change.

I agree with @Mamaduka that REST API is not the admin. With a different context, that the is_admin should not return true. If we do this, it would very likely break other things.

[maddisondesigns]

@spacedmonkey That's extremely disappointing. Yes, the REST API can be used in the back-end and the front-end, but the Block Editor is NOT a front-end editor, regardless of whether you're trying to style it to look more like the front-end. You're still in the back-end/WP Admin, so saying that just because Gutenberg uses the REST API, that it's not not in WP Admin, is just plainly incorrect. As you can obviously see in my sample editor page url in my previous comment, it literally has 'wp-admin' in the URL for editing any block editor page. The technology used to render the Block Editor pages is totally irrelevant, and if you're in the WP Admin editing pages in the Block Editor, then is_admin should return true.

[spacedmonkey]

You could do something like this.

/**
 * Add a span around braces () within page titles so they can be styled differently
 */
function mytheme_check_titles_for_braces( $title, $id = null ) {
	if( is_admin() || (defined( 'REST_REQUEST' ) && REST_REQUEST && 'edit' === $_GET['context'])) {
		return $title;
	}

	if( strstr($title, "(") === false ) {
		return $title;
	}
	
	$title = str_replace( '(', '<span>(', $title );
	$title = str_replace( ')', ')</span>', $title );

	return $title;
}
add_filter( 'the_title', 'mytheme_check_titles_for_braces', 10, 2 );

That should work.

[maddisondesigns]

@spacedmonkey Thanks for that. That's close to what I ended up using. I just didn't have the test for 'edit' === $_GET['context'] so I've added that in now as well. Thanks.

[spacedmonkey]

Checking the context is needed there. The edit context is only done for authenticated requests in the admin.