Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Documentation: Add block submission guidelines. #23545
Documentation: Add block submission guidelines. #23545
Changes from 9 commits
8e0b3f0
dba7465
4d267fa
815f43d
e2b5a06
0a3ed50
6661c0a
bb9631d
f70084f
717d26c
c14048c
488745c
34203f1
cb7e2e6
dd80b7e
b1f8072
5bbfa00
4e8e184
844db57
2657763
c429c19
f056819
b0e47b7
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think about renaming this section to "Provide data to the block directory"? Something about "Analyze your plugin" makes it sound automated, rather than curating data and describing your block(s)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here are some of my suggestions.
Share your Block
Contents:
Does this mean explain what your plugin does? Explain how you made your plugin?
I would skip the use of the word awesome as it has really no meaning/purpose in a tutorial.
The user needs to figure out for themselves if their plugin is awesome and then have a need/want to share it with others.
@ryelle Kelly
Curating data I really do not understand what that means.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should take a clearer position on block names (specifically names not titles). Especially the namespace part. Unsurprisingly there's not much consistency in the plugin directory.
At a quick glance, I see people using namespaces that are:
card-block/main
,pdf-viewer-block/standard
)blockasaurus/blockasaurus
)a8c/waves
)cgb/block-importdoc-block
)None of these are wrong because we haven't given anyone clear guidance as to what they should use. I don't have a strong opinion, but I do thing the first two dot points above are sub-optimal. Using a very generic suffix like
blah/main
orblah/standard
seems unhelpful. So does repetition likeblah/blah
.Maybe we should recommend developers pick a namespace to use across all of their blocks, like in the last two dot points?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am tempted to suggest the last 2 are suboptimal because company names and initials are more likely to be repeated where as the block's folder name must be unique. Are there any issues if we suggest the namespace must match the plugin directory folder?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I definitely think we should avoid
cgb
or other starter-content prefixes, since those are much more likely to collide.The plugin slug will be unique in order to be uploaded to the directory, so that makes sense as a namespace to me. But I also think company name or username are fine too, and it can be left to the company/person to make sure they're not uploading multiple blocks with the same name. Initials are probably more likely to collide between people though, so I'd say discourage that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another thing we should consider is that there is a desire to surface the block's name:
#16521
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Surfacing the block's name, to me, suggests that the unique plugin slug is the best route.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So is this decided, we'll require the plugin slug to be used as a prefix? Should that be added into the guidelines, or is it enough to add a check to the Block Checker?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"Name your block based on what it does"
It would be good with some example use cases to give a more detailed approach to how someone should approach the naming of their block. Have more detailed guidelines to a naming scheme as you are talking about above here.
The guidelines also need to show examples of naming, describing, keywords and choosing the right category.
That can mean use a Create a Block documentation they should follow in getting these things right. (At present I do not know if the Create a Block documentation gives this needed information.)
Bottom line is that we can not assume a person will understand but we need to give clear guidelines to how things should be done.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is very helpful to have additional examples.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here it would be good to just mention that it is good to include a prefix. (Regarding the conversation above this might be changed to remember to include a prefix.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The above is not clear for me.
I would skip the first sentence, and instead add something like the below.
You can read more about marketing your block in the plugin guidelines. The Block Directory will provide metrics to let users know helpful your block is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think without that first sentence it would be hard to understand the context. I think It may be better to remove it instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Each block in your plugin needs to have a corresponding
block.json
file. This file provides important information about your block to the Block Directory.What important information? Go straight to the point and give the details without it saying the word important. The files stores such and such information. Give a detailed overview of what the json file stores.
Kinda like.
The
block.json
file stores the location of your block's files as well as contextual information like the:name
,description
,keywords
andcategory
. In addition is also stores.....?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Block plugins submitted to the Block Directory can contain multiple (typo) blocks only if they are children of a single parent/ancestor.
Rephrasing.
Block plugins submitted to the Block Directory should have one main block, but it can contain multiple child blocks.
For example, a list block can contain list-item child blocks. Child blocks must set the
parent
property in theirblock.json
file.