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 Directory: Installed blocks show up in the block directory results #24560

Closed
ryelle opened this issue Aug 13, 2020 · 6 comments · Fixed by #28304
Closed

Block Directory: Installed blocks show up in the block directory results #24560

ryelle opened this issue Aug 13, 2020 · 6 comments · Fixed by #28304
Assignees
Labels
[Feature] Block Directory Related to the Block Directory, a repository of block plugins [Status] In Progress Tracking issues with work in progress

Comments

@ryelle
Copy link
Contributor

ryelle commented Aug 13, 2020

Describe the bug
Blocks found in the block directory that are already installed are not treated differently than uninstalled blocks. If you search for a term that does not match the local block, but does match the criteria for the block directory, the installed block will appear as an option to install.

If the user clicks "Add Block", this technically works, but does show an error in console, trying to request a page that doesn't exist (ex: http://trunk.wordpress.test/wp-admin/undefined). I'm guessing that has to do with the code to load new assets into the page.

To reproduce
Steps to reproduce the behavior:

  1. Install & activate the "waves" block plugin
  2. Edit a post, open the block inserter
  3. Search for "gradients"
  4. Waves and Starscape are both returned, but there's no indication that Waves is already installed

Expected behavior
Either the block in the regular block list should be shown, or the block directory entry should indicate that this is already installed. Or maybe nothing should change in the UI, and only the "add block" action should change?

Another approach could be finding out why "gradients" matches waves on wp.org, but not in the editor, and bringing that into line.

Screenshots
Waves is already installed, but it shows up to add here:

Screen Shot 2020-08-13 at 4 21 51 PM

@ryelle ryelle added the [Feature] Block Directory Related to the Block Directory, a repository of block plugins label Aug 13, 2020
@MichaelArestad
Copy link
Contributor

Either the block in the regular block list should be shown, or the block directory entry should indicate that this is already installed. Or maybe nothing should change in the UI, and only the "add block" action should change?

I would expect the regular block should be shown. The block directory should not show up at all.

An exception to this could be down the road when a user can intentionally initiate a search of the block directory. Then, I would expect installed blocks would show something to indicate it's already installed. Like you mention, that could be as simple as changing the "Add block" button to "Insert." That will definitely need some design iteation.

Another approach could be finding out why "gradients" matches waves on wp.org, but not in the editor, and bringing that into line.

I think that's also a good problem to solve early on if possible.

@tellyworth
Copy link
Contributor

Like you mention, that could be as simple as changing the "Add block" button to "Insert."

This seems like a great first step and easy to implement.

An exception to this could be down the road when a user can intentionally initiate a search of the block directory.

Are there some small steps we can make towards this?

@dd32
Copy link
Member

dd32 commented Aug 13, 2020

Another approach could be finding out why "gradients" matches waves on wp.org, but not in the editor, and bringing that into line.

I believe gradients is matched in search as it's mentioned in the Readme Short Description & Readme Screenshots (Neither of which is present in Gutenberg).

Having the Install button swap for Insert is a reasonable middle ground I feel, we could also clear the search cache after installing, but that would result in the gradients search a second time only returning other blocks and no mention of the block we just installed.

Although I haven't tested it right now, searching for Waves should trigger the expected behaviour (which is how I always tested this block, and never thought of looking for gradients)

@StevenDufresne
Copy link
Contributor

An exception to this could be down the road when a user can intentionally initiate a search of the block directory.

Are there some small steps we can make towards this?

I think #22149 is looking into solving that problem. The next step is probably to get a prototype going.

@MichaelArestad
Copy link
Contributor

Are there some small steps we can make towards this?

@tellyworth Possibly. I'm just starting to explore the options.

@StevenDufresne
Copy link
Contributor

The one challenge I see is that if the block doesn't add the keyword to its keyword list, that specific block will behave differently from other installed block directory blocks forever. We may want to consider updating the inserter algorithm to contain more information about the block to widen the net.

Algorithm:

export const searchItems = ( items = [], searchInput = '', config = {} ) => {

@ryelle ryelle self-assigned this Jan 15, 2021
@github-actions github-actions bot added the [Status] In Progress Tracking issues with work in progress label Jan 18, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Block Directory Related to the Block Directory, a repository of block plugins [Status] In Progress Tracking issues with work in progress
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants