The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: getdave <get_dave@git.wordpress.org>
Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>
Co-authored-by: scruffian <scruffian@git.wordpress.org>
Co-authored-by: jeryj <jeryj@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

Size Change: +175 B (+0.01%)

Total Size: 1.91 MB

_{compressed-size-action}

The content-only editing can be used without the write mode. Do we want this change to affect blocks inside containers when with templateLock: 'contentOnly'? @jeryj and I discovered the same problem in the recent PR - #70946.

Hardcoding "essential" formats seems limiting for extenders. What if they provide custom formats that are essential for their editorial teams?

Maybe we should consider letting formats declare themself as essential for write mode.

Screenshot

@Mamaduka Thanks for flagging. It's been a while.

So is Write Mode equivalent to isNavigationMode && blockEditingMode === 'contentOnly'?

Indeed, it's been a while.

So is Write Mode equivalent to isNavigationMode && blockEditingMode === 'contentOnly'?

As far as I know, that's the way to derive writing mode state; the feature is still behind the experimental flag.

Maybe we should consider letting formats declare themself as essential for write mode.

Yes. Let me explore that approach.

Maybe we should consider letting formats declare themself as essential for write mode.

I agree with this in principle. I do have concerns over it being abused. If I'm a plugin author trying to promote my tooling, why would I not define it as essential? It will promote my product and also save me questions about why they can't find the tool if they're in Write mode and don't understand Write vs Design.

At the same time, I agree we should allow this to be extended. I'm not sure how to approach it, but I'd like to do it in a way that we can explore moving forwards without being locked into a decision if possible :)

Hardcoding "essential" formats seems limiting for extenders. What if they provide custom formats that are essential for their editorial teams?

Maybe I expanded the conversation too far beyond just formats. I'm trying to think from a high level how to let tools opt-in to showing in write mode. At the moment, it seems like it has to be done within the JS which feels really ad-hoc. This may be a terrible idea - but could we add a flag to some base-level components like ToolbarItem, ToolbarButton, etc for isContentEssential={ false } or similar that forces an opt-in behavior to display your toolbar item in write mode?

I agree with this in principle. I do have concerns over it being abused. If I'm a plugin author trying to promote my tooling, why would I not define it as essential?

IMO, all public APIs can be abused; the best we can do here is to tuck them in a dropdown (similar to the current system).

P.S. It is still possible for custom format libraries to render items in the write mode toolbar if they know how SlotFills work.

Maybe we should consider letting formats declare themself as essential for write mode.

@Mamaduka @jeryj I went ahead and implemented one route for this. I didn't want to remove formats entirely or stop their registration because that's not the goal of Write Mode. All we want to do is not provide the UI in write mode.

I found the best way to do that was to wrap the format's Edit definition with a HoC that will only render in Write Mode if the format is registered with __unstableEssential (feel free to suggest alternative names).

I provided early escape hatches and also ensured it doesn't filter the component if the experiment isn't active.

I updated the description and you can follow the testing instructions there to get a feel for how this works.

The result is the same as per the original implementation, but just with the benefit that extenders can choose to mark their formats as essential to force them to show in Write Mode (under the dropdown).

What if packages/block-editor/src/components/rich-text/with-write-mode-filter.js or similar was utilized within the <BlockToolbar /> component instead? Then any Block Toolbar button or item could add the _unstableEssential (or whatever we end up calling it).

@getdave, what do you think about handling all related filtering inside the useFormatTypes? It already has similar logic for interactive formats. A small bonus point is that it won't create a store subscription for each format when a block is selected.

@jeryj, that might be more on a higher level, but it would be hard to control what BlockToolbar renders, since slots usually don't have that info.

diff --git a/packages/block-editor/src/components/rich-text/format-edit.js b/packages/block-editor/src/components/rich-text/format-edit.js
index 20d13c1d3f..a70b9f8f77 100644
--- a/packages/block-editor/src/components/rich-text/format-edit.js
+++ b/packages/block-editor/src/components/rich-text/format-edit.js
@@ -8,7 +8,6 @@ import { useContext, useMemo } from '@wordpress/element';
  * Internal dependencies
  */
 import BlockContext from '../block-context';
-import withWriteModeFilter from './with-write-mode-filter';
 
 const DEFAULT_BLOCK_CONTEXT = {};
 
@@ -38,9 +37,6 @@ function Edit( { onChange, onFocus, value, forwardedRef, settings } ) {
 		return null;
 	}
 
-	// Apply the write mode filter HOC
-	const FilteredEditFunction = withWriteModeFilter( EditFunction, settings );
-
 	const activeFormat = getActiveFormat( value, name );
 	const isActive = activeFormat !== undefined;
 	const activeObject = getActiveObject( value );
@@ -48,7 +44,7 @@ function Edit( { onChange, onFocus, value, forwardedRef, settings } ) {
 		activeObject !== undefined && activeObject.type === name;
 
 	return (
-		<FilteredEditFunction
+		<EditFunction
 			key={ name }
 			isActive={ isActive }
 			activeAttributes={ isActive ? activeFormat.attributes || {} : {} }
diff --git a/packages/block-editor/src/components/rich-text/index.js b/packages/block-editor/src/components/rich-text/index.js
index 768ffbb0cd..bd831558f7 100644
--- a/packages/block-editor/src/components/rich-text/index.js
+++ b/packages/block-editor/src/components/rich-text/index.js
@@ -132,8 +132,12 @@ export function RichTextWrapper(
 			return { isSelected: false };
 		}
 
-		const { getSelectionStart, getSelectionEnd } =
-			select( blockEditorStore );
+		const {
+			getSelectionStart,
+			getSelectionEnd,
+			getBlockEditingMode,
+			isNavigationMode,
+		} = select( blockEditorStore );
 		const selectionStart = getSelectionStart();
 		const selectionEnd = getSelectionEnd();
 
@@ -154,15 +158,21 @@ export function RichTextWrapper(
 			selectionStart: isSelected ? selectionStart.offset : undefined,
 			selectionEnd: isSelected ? selectionEnd.offset : undefined,
 			isSelected,
+			isWriteMode:
+				isNavigationMode() &&
+				getBlockEditingMode( clientId ) === 'contentOnly',
 		};
 	};
-	const { selectionStart, selectionEnd, isSelected } = useSelect( selector, [
-		clientId,
-		identifier,
-		instanceId,
-		originalIsSelected,
-		isBlockSelected,
-	] );
+	const { selectionStart, selectionEnd, isSelected, isWriteMode } = useSelect(
+		selector,
+		[
+			clientId,
+			identifier,
+			instanceId,
+			originalIsSelected,
+			isBlockSelected,
+		]
+	);
 
 	const { disableBoundBlock, bindingsPlaceholder, bindingsLabel } = useSelect(
 		( select ) => {
@@ -323,8 +333,9 @@ export function RichTextWrapper(
 	} = useFormatTypes( {
 		clientId,
 		identifier,
-		withoutInteractiveFormatting,
 		allowedFormats: adjustedAllowedFormats,
+		withoutInteractiveFormatting,
+		disableNoneEssentialFormatting: isWriteMode,
 	} );
 
 	function addEditorOnlyFormats( value ) {
diff --git a/packages/block-editor/src/components/rich-text/use-format-types.js b/packages/block-editor/src/components/rich-text/use-format-types.js
index 0bbebbf262..fcb58a852c 100644
--- a/packages/block-editor/src/components/rich-text/use-format-types.js
+++ b/packages/block-editor/src/components/rich-text/use-format-types.js
@@ -56,35 +56,48 @@ function getPrefixedSelectKeys( selected, prefix ) {
  * This hook provides RichText with the `formatTypes` and its derived props from
  * experimental format type settings.
  *
- * @param {Object}  $0                              Options
- * @param {string}  $0.clientId                     Block client ID.
- * @param {string}  $0.identifier                   Block attribute.
- * @param {boolean} $0.withoutInteractiveFormatting Whether to clean the interactive formatting or not.
- * @param {Array}   $0.allowedFormats               Allowed formats
+ * @param {Object}  options                                Options
+ * @param {string}  options.clientId                       Block client ID.
+ * @param {string}  options.identifier                     Block attribute.
+ * @param {Array}   options.allowedFormats                 Allowed formats
+ * @param {boolean} options.withoutInteractiveFormatting   Whether to clean the interactive formatting or not.
+ * @param {boolean} options.disableNoneEssentialFormatting Whether to disable none-essential formatting or not.
  */
 export function useFormatTypes( {
 	clientId,
 	identifier,
-	withoutInteractiveFormatting,
 	allowedFormats,
+	withoutInteractiveFormatting,
+	disableNoneEssentialFormatting = false,
 } ) {
 	const allFormatTypes = useSelect( formatTypesSelector, [] );
 	const formatTypes = useMemo( () => {
-		return allFormatTypes.filter( ( { name, interactive, tagName } ) => {
-			if ( allowedFormats && ! allowedFormats.includes( name ) ) {
-				return false;
-			}
+		return allFormatTypes.filter(
+			( { name, interactive, tagName, __unstableEssential } ) => {
+				if ( allowedFormats && ! allowedFormats.includes( name ) ) {
+					return false;
+				}
 
-			if (
-				withoutInteractiveFormatting &&
-				( interactive || interactiveContentTags.has( tagName ) )
-			) {
-				return false;
-			}
+				if ( disableNoneEssentialFormatting && ! __unstableEssential ) {
+					return false;
+				}
+
+				if (
+					withoutInteractiveFormatting &&
+					( interactive || interactiveContentTags.has( tagName ) )
+				) {
+					return false;
+				}
 
-			return true;
-		} );
-	}, [ allFormatTypes, allowedFormats, withoutInteractiveFormatting ] );
+				return true;
+			}
+		);
+	}, [
+		allFormatTypes,
+		allowedFormats,
+		disableNoneEssentialFormatting,
+		withoutInteractiveFormatting,
+	] );
 	const keyedSelected = useSelect(
 		( select ) =>
 			formatTypes.reduce( ( accumulator, type ) => {

...what do you think about handling all related filtering inside the useFormatTypes?

I looked at this yesterday and dismissed it, but looking again it seems ideal. I'll make some adjustments.

WP 6.9 note - Stabilization Needed

The essential property should be stabilized as a public API to allow plugin developers to create formats that are visible in Write Mode.

This would enable plugins to provide essential formatting options that integrate seamlessly with the Write Mode experience.

Note that this PR implements the feature as private via a Symbol.

@Mamaduka @scruffian @jeryj @talldan I've been thinking about PRs like this one which alter the UI based on a combo of

• "is write mode"
• "is block contentOnly"

I'm thinking that actually we don't need the "is write mode" check at all as blocks marked as contentOnly shiould have consistent behaiour regardless of the wider editor mode.

To me "write mode" should just dictate the state of blocks (e.g. contentOnly, disabled...etc). The way those blocks actually behave (e.g. restricted UI...etc) in those states is up to them.

I'd value your thoughts on:

• is my thinking correct
• are their any edge cases I haven't considered

If I'm correct then I'll raise PRs to update the recent implementations I've made.

I'm thinking that actually we don't need the "is write mode" check at all as blocks marked as contentOnly shiould have consistent behaiour regardless of the wider editor mode.

You might need to check whether a block is a section as well, as I think they might also be content only. Not 100% sure, just trying to remember.