Size Change: +188 kB (+2.45%)

Total Size: 7.88 MB

_{compressed-size-action}

Flaky tests detected in 9d87e8d.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/23586296106
📝 Reported issues:

• [Flaky Test] Should render and migrate legacy openSubmenusOnClick blocks #75559 in /test/e2e/specs/editor/blocks/navigation-frontend-interactivity.spec.js
• [Flaky Test] post title and content are editable and blocks can be inserted #76524 in /test/e2e/specs/editor/various/post-content-focus-mode.spec.js

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: carolinan <poena@git.wordpress.org>
Co-authored-by: sirreal <jonsurrell@git.wordpress.org>
Co-authored-by: westonruter <westonruter@git.wordpress.org>

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

I need everyone who has information about decisions about enabling syntax highligting to add that to the issue, alternatively create a new issue with all the information, it is not possible for other contributors to know what has been discussed if the contexts are in other repositories or in private.

How the script is introduced to Gutenberg, has little effect on how the existing code editors are updated to use it. What I mean is, the component may be moved, but its actual functionality won't change.

There's a feature channel in Core Slack that you may wish to join.

⚠️ The syntax highlighting cannot be turned off by the user.⚠️

Couldn't this be controlled by the Syntax highlighting option (syntax_highlighting) in the user profile?

I think we should start an effort in Gutenberg to upgrade CodeMirror from v5 to v6. We'll use Gutenberg to update the existing surfaces in core which use v5 to use v6 instead. To go along with that, we can introduce CodeMirror in more places, like here in the HTML block. Then in WordPress 7.1 (🤞🏻) we can have v6 replace v5 in core.

I'll share some ideas I had about the code editor and what it might look like more broadly:

• A public code editor module is added
• codemirror v6 is used privately in that module. Private codemirror modules are used internally, the exact module layout is unclear.
• For private modules to be possible, we'd need to add scopes to the module system.
• The block-editor (for code view), block-library (for html/css/js and for code block), and other parts of wp-admin (theme/plugin editors) can rely on the code editor module.

⚠️ The syntax highlighting cannot be turned off by the user.⚠️

Couldn't this be controlled by the Syntax highlighting option (syntax_highlighting) in the user profile?

Yes but the setting is not available in the block editor yet, it needs to be coded.

I'll share some ideas I had about the code editor and what it might look like more broadly:

• A public code editor module is added
• codemirror v6 is used privately in that module. Private codemirror modules are used internally, the exact module layout is unclear.
• For private modules to be possible, we'd need to add scopes to the module system.
• The block-editor (for code view), block-library (for html/css/js and for code block), and other parts of wp-admin (theme/plugin editors) can rely on the code editor module.

I think it is beyond my capabilities.

I think this is the one where I have the least knowledge

For private modules to be possible, we'd need to add scopes to the module system.

But can we add these to a new issue with clear tasks (checklist) and maybe close the old one to not muddy it.
Also, drifting, but I am assuming:

• We are not planning to lint the code
• We need a different tool for the front (visitor facing) code block

• We are not planning to lint the code

Linting seems like something we can still do, no? The current Custom HTML widget integration in core does linting at least for tags not allowed by Kses. Any linting that would flag invalid HTML would be helpful and should be straightforward to add.

• We need a different tool for the front (visitor facing) code block

I know that @sirreal has worked on this already, but my understanding is that CodeMirror can be used for this as well. The syntax-highlighted HTML can be rendered to the block in the save function (in some way) or else added as block attributes which can override the static block markup in a dynamic block. The tricky thing is how to deal with markup added to the Code block, like bolded, highlighted, or linked text.

Linting is not included in the scope of the original issue, so I didn't include that package.
Again this is why the intent and tasks needs to be documented.