-
Notifications
You must be signed in to change notification settings - Fork 298
[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
Comments
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. |
It's still an issue when I test in Safari on MacOS when using https://wasm.wordpress.net/wordpress-browser.html: |
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 );
} |
Turns out |
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. |
This is happening again as reported by @fabiankaegy. Probably it's a |
Fixed in 7a9b864 |
## 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?).
@gziolo reported the following behavior:
The text was updated successfully, but these errors were encountered: