` on the custom admin page. ```language-jsx domReady( function () { const root = createRoot( document.getElementById( 'getdave-sbe-block-editor' ) ); const settings = window.getdaveSbeSettings || {}; registerCoreBlocks(); root.render( ); } ); ``` It is possible to render the editor from PHP without creating an unnecessary JS global. Check out the [Edit Site](https://href.li/?https://github.com/WordPress/gutenberg/blob/c6821d7e64a54eb322583a35daedc6c192ece850/lib/edit-site-page.php#L135) package in the Gutenberg plugin for an example of this. ## 󠀁[Reviewing the component](https://developer.wordpress.org/block-editor/how-to-guides/platform/custom-block-editor/?output_format=md#reviewing-the-editor-component)󠁿 Let’s take a closer look at the `` component that was used in the code above and lives in `src/editor.js` of the [companion plugin](https://github.com/getdave/standalone-block-editor). Despite its name, this is not the actual core of the block editor. Rather, it is a _wrapper_ component that will contain the components that form the custom editor’s main body. ### 󠀁[Dependencies](https://developer.wordpress.org/block-editor/how-to-guides/platform/custom-block-editor/?output_format=md#dependencies)󠁿 The first thing to do inside `` is to pull in some dependencies. ```language-jsx // File: src/editor.js import Notices from 'components/notices'; import Header from 'components/header'; import Sidebar from 'components/sidebar'; import BlockEditor from 'components/block-editor'; ``` The most important of these are the internal components `BlockEditor` and `Sidebar`, which will be covered shortly. The remaining components consist mostly of static elements that form the editor’s layout and surrounding user interface (UI). These elements include the header and notice areas, among others. ### 󠀁[Editor render](https://developer.wordpress.org/block-editor/how-to-guides/platform/custom-block-editor/?output_format=md#editor-render)󠁿 With these components available, you can define the `` component. ```language-jsx // File: src/editor.js function Editor( { settings } ) { return (

); } ``` In this process, the core of the editor’s layout is being scaffolded, along with a few specialized [context providers](https://react.dev/reference/react/createContext#provider) that make specific functionality available throughout the component hierarchy. Let’s examine these in more detail: * `` – Enables the use of [dropzones for drag and drop functionality](https://github.com/WordPress/gutenberg/tree/e38dbe958c04d8089695eb686d4f5caff2707505/packages/components/src/drop-zone) * `` – Provides a “snack bar” Notice that will be rendered if any messages are dispatched to the `core/notices` store * `

` – Renders the static title “Standalone Block Editor” at the top of the editor UI * `` – The custom block editor component ### 󠀁[Keyboard navigation](https://developer.wordpress.org/block-editor/how-to-guides/platform/custom-block-editor/?output_format=md#keyboard-navigation)󠁿 With this basic component structure in place, the only remaining thing left to do is wrap everything in the [`navigateRegions` HOC](https://github.com/WordPress/gutenberg/tree/e38dbe958c04d8089695eb686d4f5caff2707505/packages/components/src/higher-order/navigate-regions) to provide keyboard navigation between the different “regions” in the layout. ```language-jsx // File: src/editor.js export default navigateRegions( Editor ); ``` ## 󠀁[The custom ](https://developer.wordpress.org/block-editor/how-to-guides/platform/custom-block-editor/?output_format=md#the-custom-blockeditor)󠁿 Now the core layouts and components are in place. It’s time to explore the custom implementation of the block editor itself. The component for this is called ``, and this is where the magic happens. Opening `src/components/block-editor/index.js` reveals that it’s the most complex component encountered thus far. A lot going on, so start by focusing on what is being rendered by the `` component: ```javascript // File: src/components/block-editor/index.js return (

); ``` The key components are `` and ``. Let’s examine these. ### 󠀁[Understanding the component](https://developer.wordpress.org/block-editor/how-to-guides/platform/custom-block-editor/?output_format=md#understanding-the-blockeditorprovider-component)󠁿 [``](https://github.com/WordPress/gutenberg/tree/e38dbe958c04d8089695eb686d4f5caff2707505/packages/block-editor/src/components/provider) is one of the most important components in the hierarchy. It establishes a new block editing context for a new block editor. As a result, it is _fundamental_ to the entire goal of this project. The children of `` comprise the UI for the block editor. These components then have access to data (via `Context`), enabling them to _render_ and _manage_ the blocks and their behaviors within the editor. ```language-jsx // File: src/components/block-editor/index.js ``` #### 󠀁[BlockEditor props](https://developer.wordpress.org/block-editor/how-to-guides/platform/custom-block-editor/?output_format=md#blockeditor-props)󠁿 You can see that `` accepts an array of (parsed) block objects as its `value` prop and, when there’s a change detected within the editor, calls the `onChange` and/or `onInput` handler prop (passing the new Blocks as an argument). Internally it does this by subscribing to the provided `registry` (via the [`withRegistryProvider` HOC](https://github.com/WordPress/gutenberg/blob/e38dbe958c04d8089695eb686d4f5caff2707505/packages/block-editor/src/components/provider/index.js#L158)), listening to block change events, determining whether the block changing was persistent, and then calling the appropriate `onChange|Input` handler accordingly. For the purposes of this simple project, these features allow you to: * Store the array of current blocks in state as `blocks`. * Update the `blocks` state in memory on `onInput` by calling the hook setter ` updateBlocks(blocks)`. * Handle basic persistence of blocks into `localStorage` using `onChange`. This is [fired when block updates are considered “committed”](https://github.com/WordPress/gutenberg/tree/HEAD/packages/block-editor/src/components/provider#onchange). It’s also worth recalling that the component accepts a `settings` property. This is where you will add the editor settings inlined earlier as JSON within `init.php`. You can use these settings to configure features such as custom colors, available image sizes, and [much more](https://github.com/WordPress/gutenberg/tree/4c472c3443513d070a50ba1e96f3a476861447b3/packages/block-editor#SETTINGS_DEFAULTS). ### 󠀁[Understanding the component](https://developer.wordpress.org/block-editor/how-to-guides/platform/custom-block-editor/?output_format=md#understanding-the-blocklist-component)󠁿 Alongside `` the next most interesting component is [``](https://github.com/WordPress/gutenberg/blob/e38dbe958c04d8089695eb686d4f5caff2707505/packages/block-editor/src/components/block-list/index.js). This is one of the most important components as it’s role is to **render a list of blocks into the editor**. It does this in part thanks to being placed as a child of ``, which affords it full access to all information about the state of the current blocks in the editor. #### 󠀁[How does BlockList work?](https://developer.wordpress.org/block-editor/how-to-guides/platform/custom-block-editor/?output_format=md#how-does-blocklist-work)󠁿 Under the hood, `` relies on several other lower-level components in order to render the list of blocks. The hierarchy of these components can be _approximated_ as follows: ```language-jsx // Pseudo code for example purposes only. /* renders a list of blocks from the rootClientId. */ /* renders a single block from the BlockList. */ /* renders the standard editable area of a block. */ /* renders the block UI as defined by its `edit()` implementation. */ ``` Here is roughly how this works together to render the list of blocks: * `` loops over all the block `clientIds` and renders each via [``](https://github.com/WordPress/gutenberg/blob/e38dbe958c04d8089695eb686d4f5caff2707505/packages/block-editor/src/components/block-list/block.js). * ``, in turn, renders the individual block using its own subcomponent [``](https://github.com/WordPress/gutenberg/blob/def076809d25e2ad680beda8b9205ab9dea45a0f/packages/block-editor/src/components/block-edit/index.js). * Finally, the [block itself](https://github.com/WordPress/gutenberg/blob/def076809d25e2ad680beda8b9205ab9dea45a0f/packages/block-editor/src/components/block-edit/edit.js) is rendered using the `Component` placeholder component. The `@wordpress/block-editor` package components are among the most complex and involved. Understanding them is crucial if you want to grasp how the editor functions at a fundamental level. Studying these components is strongly advised. ## 󠀁[Reviewing the sidebar](https://developer.wordpress.org/block-editor/how-to-guides/platform/custom-block-editor/?output_format=md#reviewing-the-sidebar)󠁿 Also within the render of the ``, is the `` component. ```language-jsx // File: src/components/block-editor/index.js return (

/* <-- SIDEBAR */

); ``` This is used, in part, to display advanced block settings via the `` component. ```language-jsx ``` However, the keen-eyed readers amongst you will have already noted the presence of a `` component within the `` (`src/editor.js`) component’s layout: ```language-jsx // File: src/editor.js

// <-- What's this? ``` Opening the `src/components/sidebar/index.js` file, you can see that this is, in fact, the component rendered within `` above. However, the implementation utilises Slot/Fill to expose a `Fill` (``), which is subsequently imported and rendered inside of the `` component (see above). With this in place, you then can render `` as a child of the ` Sidebar.InspectorFill`. This has the result of allowing you to keep `` within the React context of `` whilst allowing it to be rendered into the DOM in a separate location (i.e. in the ``). This might seem overly complex, but it is required in order for `` to have access to information about the current block. Without Slot/Fill, this setup would be extremely difficult to achieve. And with that you have covered the render of you custom ``. [``](https://github.com/WordPress/gutenberg/blob/def076809d25e2ad680beda8b9205ab9dea45a0f/packages/block-editor/src/components/block-inspector/index.js) itself actually renders a `Slot` for [``](https://github.com/WordPress/gutenberg/tree/HEAD/packages/block-editor/src/components/inspector-controls). This is what allows you [render](https://github.com/WordPress/gutenberg/blob/def076809d25e2ad680beda8b9205ab9dea45a0f/packages/block-library/src/paragraph/edit.js#L127) a `` component inside the `edit()` definition for your block and have it display within the editor’s sidebar. Exploring this component in more detail is recommended. ## 󠀁[Block Persistence](https://developer.wordpress.org/block-editor/how-to-guides/platform/custom-block-editor/?output_format=md#block-persistence)󠁿 You have come a long way on your journey to create a custom block editor. But there is one major area left to touch upon – block persistence. In other words, having your blocks saved and available _between_ page refreshes. ![WordPress custom block editor interface with various content blocks and editing options](https://i0.wp.com/developer.wordpress.org/files/2023/07/custom-block-editor- persistance.gif?ssl=1 "Screencapture showing blocks being restored between page refreshes.") As this is only an _experiment_, this guide has opted to utilize the browser’s ` localStorage` API to handle saving block data. In a real-world scenario, you would likely choose a more reliable and robust system (e.g. a database). That said, let’s take a closer look at how to handle save blocks. ### 󠀁[Storing blocks in state](https://developer.wordpress.org/block-editor/how-to-guides/platform/custom-block-editor/?output_format=md#storing-blocks-in-state)󠁿 Looking at the `src/components/block-editor/index.js` file, you will notice that some state has been created to store the blocks as an array: ```language-jsx // File: src/components/block-editor/index.js const [ blocks, updateBlocks ] = useState( [] ); ``` As mentioned earlier, `blocks` is passed to the “controlled” component `` as its `value` prop. This “hydrates” it with an initial set of blocks. Similarly, the `updateBlocks` setter is hooked up to the `onInput` callback on ``, which ensures that the block state is kept in sync with changes made to blocks within the editor. ### 󠀁[Saving block data](https://developer.wordpress.org/block-editor/how-to-guides/platform/custom-block-editor/?output_format=md#saving-block-data)󠁿 If you now turn your attention to the `onChange` handler, you will notice it is hooked up to a function `persistBlocks()` which is defined as follows: ```javascript // File: src/components/block-editor/index.js function persistBlocks( newBlocks ) { updateBlocks( newBlocks ); window.localStorage.setItem( 'getdavesbeBlocks', serialize( newBlocks ) ); } ``` This function accepts an array of “committed” block changes and calls the state setter `updateBlocks`. It also stores the blocks within LocalStorage under the key` getdavesbeBlocks`. In order to achieve this, the block data is serialized into [Gutenberg “Block Grammar”](https://developer.wordpress.org/block-editor/principles/key-concepts/#blocks) format, meaning it can be safely stored as a string. If you open DeveloperTools and inspect the LocalStorage you will see serialized block data stored and updated as changes occur within the editor. Below is an example of the format: ```

An experiment with a standalone Block Editor in the WordPress admin

This is an experiment to discover how easy (or otherwise) it is to create a standalone instance of the Block Editor in the WordPress admin.

``` ### 󠀁[Retrieving previous block data](https://developer.wordpress.org/block-editor/how-to-guides/platform/custom-block-editor/?output_format=md#retrieving-previous-block-data)󠁿 Having persistence in place is all well and good, but it’s only useful if that data is retrieved and _restored_ within the editor upon each full page reload. Accessing data is a side effect, so you must use the `useEffect` hook to handle this. ```language-jsx // File: src/components/block-editor/index.js useEffect( () => { const storedBlocks = window.localStorage.getItem( 'getdavesbeBlocks' ); if ( storedBlocks && storedBlocks.length ) { updateBlocks( () => parse( storedBlocks ) ); createInfoNotice( 'Blocks loaded', { type: 'snackbar', isDismissible: true, } ); } }, [] ); ``` This handler: * Grabs the serialized block data from local storage. * Converts the serialized blocks back to JavaScript objects using the `parse()` utility. * Calls the state setter `updateBlocks` causing the `blocks` value to be updated in state to reflect the blocks retrieved from LocalStorage. As a result of these operations, the controlled `` component is updated with the blocks restored from LocalStorage, causing the editor to show these blocks. Finally, you will want to generate a notice – which will display in the `` component as a “snackbar” notice – to indicate that the blocks have been restored. ## 󠀁[Wrapping up](https://developer.wordpress.org/block-editor/how-to-guides/platform/custom-block-editor/?output_format=md#wrapping-up)󠁿 Congratulations for completing this guide. You should now have a better understanding of how the block editor works under the hood. The full code for the custom block editor you have just built is [available on GitHub](https://github.com/getdave/standalone-block-editor). Download and try it out for yourself. Experiment, then and take things even further. First published March 9, 2021 Last updated August 27, 2026 Edit article [ Improve it on GitHub: Building a custom block editor ](https://github.com/WordPress/gutenberg/edit/trunk/docs/how-to-guides/platform/custom-block-editor.md) [ Previous: Development Platform](https://developer.wordpress.org/block-editor/how-to-guides/platform/) [ Next: Create your First App with Gutenberg Data](https://developer.wordpress.org/block-editor/how-to-guides/data-basics/)