WordPress 6.2, the next major release of WordPress core, is scheduled for March 28th.
The new version of WordPress comes with many feature improvements and enhancements, but you may not want to use them.
Here are some code snippets to disable certain features:
1) To disable the new Openverse category from showing in the new media tab in the block editor, you can use this code snippet.
add_filter(
'block_editor_settings_all',
function( $settings ) {
$settings['enableOpenverseMediaCategory'] = false;return $settings;
},
10
);
2) There is a new filter wp_save_post_revision_revisions_before_deletion which can be used to delete all but the oldest post revision on posts.
add_filter(
'wp_save_post_revision_revisions_before_deletion',
function( $revisions, $post_id ) {
$original_revision = get_transient( 'original_revision_for_post_' . $post_id );
if ( $original_revision ) {
// Always remove the oldest revision from the array of revisions to potentially delete.
unset( $revisions[ $original_revision ] );
} else {
// Set the oldest revision in a transient, so we can verify that it is always ignored.
$original_revision = array_key_first( $revisions );
set_transient( 'original_revision_for_post_' . $post_id, $original_revision );
}
return $revisions;
},
10,
2
);
3) A block inspector tabs feature was added to the WordPress 6.2 release but using the filter it can be disabled using a code snippet.
function my_plugin_disable_tabs_by_default( $settings ) {
$settings['blockInspectorTabs'] = array( 'default' => false );
return $settings;
}
add_filter('block_editor_settings_all', 'my_plugin_disable_tabs_by_default');
MainWP has an easy-to-use code snippets extension that can save and execute code snippets on all connected Child Sites.
The field guide is worth reviewing to get an overview of what’s coming in the latest release.
It is always recommended to test major WordPress core updates on a staging site using the beta and release candidate versions.
Before updating the live site, you should always test out major WordPress core releases on a staging site. Here are a few reasons why:
To avoid potential conflicts: A major WordPress release often introduces new features, updates, and changes to the codebase, which can potentially conflict with your website’s existing themes, plugins, or custom code. Testing the update on a staging site helps you identify and resolve any conflicts before the update is made live, preventing any unexpected downtime or errors on your live site.
To ensure compatibility: A staging site allows you to test your website’s compatibility with the new WordPress version and any themes and plugins you use. This can help you identify any compatibility issues before the update is made live, allowing you to fix them before any potential problems arise.
To ensure site functionality: A major WordPress release can impact the functionality of your site, and testing it on a staging site can help you identify and fix any issues before going live. This ensures your site functions as intended without negatively affecting your user experience.
To reduce risk: Testing major WordPress core releases on a staging site reduces the risk of something going wrong on your live site. It lets you identify and fix any issues beforehand, preventing downtime, data loss, or other potentially costly problems.
Overall, testing major WordPress core releases on a staging site first is a best practice that can help you ensure your website’s stability, compatibility, and functionality while reducing the risk of any negative impact on your live site.
Useful Links
- https://make.wordpress.org/core/6-2/
- https://make.wordpress.org/core/2023/03/09/wordpress-6-2-field-guide/
- https://make.wordpress.org/core/2023/03/07/miscellaneous-developer-changes-in-wordpress-6-2/
- https://make.wordpress.org/core/2023/03/07/miscellaneous-editor-changes-in-wordpress-6-2/
- https://make.wordpress.org/core/tag/dev-notes-6-2/
- https://make.wordpress.org/core/handbook/testing/beta-testing/
