Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Safari] Post editor only shows the code editing mode #6

Closed
adamziel opened this issue Sep 22, 2022 · 8 comments
Closed

[Safari] Post editor only shows the code editing mode #6

adamziel opened this issue Sep 22, 2022 · 8 comments
Labels
[Type] Bug An existing feature does not function as intended

Comments

@adamziel
Copy link
Collaborator

@gziolo reported the following behavior:

For some reason when I load the post editor, it shows only code editing mode. I can’t enable the visual mode.

Screen Shot 2022-09-21 at 11 27 33

@adamziel
Copy link
Collaborator Author

I can't reproduce on the latest trunk anymore so I'm closing this one. @gziolo feel free to reopen if you're still experiencing this issue.

@gziolo
Copy link
Member

gziolo commented Oct 14, 2022

It's still an issue when I test in Safari on MacOS when using https://wasm.wordpress.net/wordpress-browser.html:

Screen Shot 2022-10-14 at 11 02 15

@adamziel adamziel reopened this Oct 14, 2022
@gziolo
Copy link
Member

gziolo commented Oct 15, 2022

To be clear. Everything works correctly in Chrome on MacOS:

Screen Shot 2022-10-15 at 09 03 31

@adamziel adamziel changed the title Post editor only shows the code editing mode [Safari] Post editor only shows the code editing mode Oct 15, 2022
@adamziel
Copy link
Collaborator Author

adamziel commented Oct 16, 2022

For some reason, WordPress sets the following settings in Safari:

wp.editPost.initializeEditor( 'editor', "post", 5, {
    // ...
    "richEditingEnabled": false, // in PHP: user_can_richedit()
    "disablePostFormats": true // in PHP: ! current_theme_supports( 'post-formats' )
} );

Adding the following filter fixes it:

add_filter( 'block_editor_settings', function ( $settings, $post ) {
	$settings['richEditingEnabled'] = true;
	$settings['codeEditingEnabled'] = true;
	$settings['disablePostFormats'] = false;
		
	return $settings;
}, 10, 2);

But I'd like to understand the root cause instead of solving it with a filter.

Edit: It's probably the following code paths:

function user_can_richedit() {
	// ...
	if ( $is_safari ) {
		$wp_rich_edit = ! wp_is_mobile() || ( preg_match( '!AppleWebKit/(\d+)!', $_SERVER['HTTP_USER_AGENT'], $match ) && (int) $match[1] >= 534 );
	}
}
if ( $is_safari && stripos( $_SERVER['HTTP_USER_AGENT'], 'mobile' ) !== false ) {
	$is_iphone = true;
}

function wp_is_mobile() {
	if ( empty( $_SERVER['HTTP_USER_AGENT'] ) ) {
		$is_mobile = false;
	} elseif ( strpos( $_SERVER['HTTP_USER_AGENT'], 'Mobile' ) !== false || strpos( $_SERVER['HTTP_USER_AGENT'],
			'Android' ) !== false || strpos( $_SERVER['HTTP_USER_AGENT'], 'Silk/' ) !== false || strpos( $_SERVER['HTTP_USER_AGENT'],
			'Kindle' ) !== false || strpos( $_SERVER['HTTP_USER_AGENT'], 'BlackBerry' ) !== false || strpos( $_SERVER['HTTP_USER_AGENT'],
			'Opera Mini' ) !== false || strpos( $_SERVER['HTTP_USER_AGENT'], 'Opera Mobi' ) !== false ) {
		$is_mobile = true;
	} else {
		$is_mobile = false;
	}

	return apply_filters( 'wp_is_mobile', $is_mobile );
}

@adamziel
Copy link
Collaborator Author

Turns out $_SERVER['HTTP_USER_AGENT'] wasn't set before dispatching the PHP request. Fixed in f8e1322

@gziolo
Copy link
Member

gziolo commented Oct 16, 2022

Awesome. It’s a bit surprising that the logic depends so much on the detected browser, but it should now work correctly in all cases.

@adamziel
Copy link
Collaborator Author

adamziel commented Feb 6, 2023

This is happening again as reported by @fabiankaegy. Probably it's a $_SERVER['HTTP_USER_AGENT'] regression related to switching from dispatching request with PHP code to a dedicated SAPI.

@adamziel adamziel reopened this Feb 6, 2023
@artemiomorales artemiomorales added the [Type] Bug An existing feature does not function as intended label Feb 24, 2023
@adamziel
Copy link
Collaborator Author

Fixed in 7a9b864

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Type] Bug An existing feature does not function as intended
Projects
None yet
Development

No branches or pull requests

3 participants