Skip to content

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

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

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

adamziel pushed a commit that referenced this issue May 30, 2025
## Motivation for the change, related issues

**This is a WIP draft at the moment. Looking for feedback on the
direction I'm taking here.**

The new SQLite driver requires the `DB_NAME` constant to be set. This is
to be able to store the correct database name in the information schema.
However, some WordPress site backups and exports don't include the
constant in `wp-config.php`. This happens with hosts that inject the
database configuration in a different way.

Even though we could probably emulate it dynamically in the SQLite
driver, this may be non-trivial, e.g., in cases someone joins on the
`information_schema.tables` table, etc.

Making sure that the constant is defined seems to be easier, and should
also improve the compatibility with any plugins that rely on the
`DB_NAME` constant to be set.

---

This was discovered when importing a site backup without the `DB_NAME`
constant in Studio:

```
Fatal error: Uncaught Error: Undefined constant "DB_NAME" in /var/www/html/wp-content/mu-plugins/sqlite-database-integration/wp-includes/sqlite/db.php:64 Stack trace: #0 /var/www/html/wp-content/db.php(37): require_once() #1 /var/www/html/wp-includes/load.php(683): require_once('/var/www/html/w...') #2 /var/www/html/wp-settings.php(133): require_wp_db() #3 /var/www/html/wp-config.php(85): require_once('/var/www/html/w...') #4 /var/www/html/wp-load.php(50): require_once('/var/www/html/w...') #5 /var/www/html/wp-blog-header.php(13): require_once('/var/www/html/w...') #6 /var/www/html/index.php(17): require('/var/www/html/w...') #7 {main} thrown in /var/www/html/wp-content/mu-plugins/sqlite-database-integration/wp-includes/sqlite/db.php on line 64
```

Related:
- Automattic/sqlite-database-integration#40
- Automattic/sqlite-database-integration#44

## Implementation details

## Testing Instructions (or ideally a Blueprint)
1. Boot Playground (`npm run dev`).
2. Export the site into a ZIP.
3. Remove the `DB_NAME` constant definition from the ZIP.
4. Import the site without the `DB_NAME` constant set.
5. Verify that a `DB_NAME` constant was injected (TODO: describe how).
6. Export the site ZIP and have the `DB_NAME` constant defined in
`wp-config.php` (TODO: is this required?).
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