Skip to content
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

Block Inserter: Markdown and SyntaxHighlighting first visible blocks #46981

Closed
noahtallen opened this issue Oct 30, 2020 · 5 comments
Closed
Labels
Blocks Editor blocks, aka Gutenberg blocks, plugins, and extensions [Feature] Post/Page Editor The editor for editing posts and pages. [Pri] Normal Schedule for the next available opportuinity. [Type] Enhancement

Comments

@noahtallen
Copy link
Contributor

noahtallen commented Oct 30, 2020

“Markdown” and “SyntaxHighlighting” are showing at the front in the text group.

Ideas:

  • Core blocks should come first unless we really really want to.
@noahtallen noahtallen added [Type] Enhancement [Pri] Normal Schedule for the next available opportuinity. [Goal] Gutenberg Working towards full integration with Gutenberg labels Oct 30, 2020
@simison
Copy link
Member

simison commented Feb 9, 2021

Feedback: https://twitter.com/berkun/status/1358950705394929664

Might be something to do with how Jetpack registers blocks in non-standard way? cc @jeherve @kraftbj if you have this also on Jetpack backlogs?

@jeherve
Copy link
Member

jeherve commented Feb 9, 2021

I don't believe it's related to Jetpack, it seems to happen with all blocks. Note how the third-party blocks are all ahead of core blocks in the screenshots below:

image

image

I believe the problem is currently tracked here:

WordPress/gutenberg#26651

@cathymcbride cathymcbride added Blocks Editor blocks, aka Gutenberg blocks, plugins, and extensions [Feature] Post/Page Editor The editor for editing posts and pages. and removed [Goal] Gutenberg Working towards full integration with Gutenberg labels Feb 9, 2021
@Addison-Stavlo
Copy link
Contributor

It seems like this behavior is pretty standard. Any way I test it locally it seems 3rd party blocks appear before core blocks in the sidebar inserter. And I don't see any block registration settings that would effect whether or not they appear before or after core blocks in their category. It may just be simply due to timing of block registration.

So I'm not sure if this issue is actually an issue and more of 'working as expected' (at this point in time at least? - asking for any clarity https://wordpress.slack.com/archives/C02QB2JS7/p1612979789462600). But if there are concerns that core blocks should really appear first maybe we should open an issue in Gutenberg to discuss?


RE the twitter feedback @simison linked : https://twitter.com/berkun/status/1358950705394929664

It seems there @mtias is talking about the contextual quick inserter, while the issue we are discussing is specific to the sidebar inserter.

@Addison-Stavlo
Copy link
Contributor

Addison-Stavlo commented Feb 10, 2021

It may just be simply due to timing of block registration.

It looks like with plugins we generally register scripts/blocks on the init hook. While core blocks are not registered until the specific editors load and their initializeEditor functions run (ex https://github.com/WordPress/gutenberg/blob/f94414c86562bfd09c810f2f523fef66b8f81a5b/packages/edit-post/src/index.js#L94). Thus the 3rd party blocks are registered earlier than core blocks, and core blocks appear further down the registered list. The lists are then filtered by category, but 3rd party blocks will still remain at the top of those categories. 🤔

@Addison-Stavlo
Copy link
Contributor

with WordPress/gutenberg#28945 merged, this issue will be resolved once the new Gutenberg versions land on dotcom.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Blocks Editor blocks, aka Gutenberg blocks, plugins, and extensions [Feature] Post/Page Editor The editor for editing posts and pages. [Pri] Normal Schedule for the next available opportuinity. [Type] Enhancement
Projects
None yet
Development

No branches or pull requests

5 participants