Gutenberg: Enable Contact Form block by default / Block Discoverability

[kevinwhoffman]

Steps to reproduce the issue

1. Install Jetpack v6.8.1
2. Add define( 'JETPACK_DEV_DEBUG', true ); to wp-config.php.
3. Add new post.
4. Open the block inserter and scroll to Jetpack. Note the Form block is not available.
5. Visit [yourjetpack.blog]/wp-admin/admin.php?page=jetpack_modules. Note that the Contact Form module is not enabled despite documentation saying that it should be activated by default.
   6.Enable the Contact Form module. At this point the Form block becomes available in the editor.

What I expected

I expected the Form block to be available in the Gutenberg block inserter and in slash commands by default.

What happened instead

Instead I had to search through every setting to look for a way to enable the Form block. When I did not find a setting, I eventually found the Debug link in the footer where I then followed the link to enable the Contact Form module, which in turn enabled the Form block.

Screenshots
Screenshot of the block inserter immediately after plugin activation, showing that the Form block is missing:

Primary issue

#32401

[dereksmart]

Can't comment on the block UX for disabled modules, but I can provide some insight on a couple things.

despite documentation saying that it should be activated by default

Does the site have any other Contact Form plugins active? There is logic in Jetpack that skips the auto-activation of some modules if they have "conflicting plugins".

I had to search through every setting to look for a way to enable the Form block

Something you can do in the future is use the search field on the Jetpack settings page. It's that magnifying glass icon. You can also link to the search term directly by appending ?term=contact%20form to the settings URL, like: /wp-admin/admin.php?page=jetpack#/settings?term=contact%20form

[kevinwhoffman]

Does the site have any other Contact Form plugins active?

This was a fresh install of WordPress 5.0 and Jetpack 6.8.1 in a local dev environment. There were no other plugins installed.

Something you can do in the future is use the search field on the Jetpack settings page. It's that magnifying glass icon.

The search bar doesn't help because it doesn't provide a control or link necessary to enable the module. It simply shows an information icon that links to documentation.

The overall Settings UI is quite confusing because some features are enabled in the Jetpack Dashboard, others in Jetpack Settings, and others still that can only be enabled via the Debug link in the footer. A new user can't be expected to know the URL scheme necessary to access the modules page directly.

[dereksmart]

This was a fresh install of WordPress 5.0 and Jetpack 6.8.1

Got it, possible that dev_debug constant alone doesn’t auto-activate modules. It normally happens during the connection process.

It simply shows an information icon that links to documentation

That’s the view when the module is already active. You should see a toggle for the ones that are inactive.

Really do appreciate the feedback about the settings UX. Always room for improvements and we’re continually trying to make the experience better.

[kevinwhoffman]

I thought it might be the case that the form is activated during the connection process, which is why I mentioned using the dev constant.

That’s the view when the module is already active. You should see a toggle for the ones that are inactive.

You're right. The activate button was in the search results when the contact form was deactivated. However I'd expect that if the activate button is there in one case that a deactivate button would there in the reverse, especially because other settings do allow you to toggle settings in the search results.

Anyways really nice work with the Form block. I'm glad to be able to dig into the code now and see how it works. Feel free to close if you think the behavior is working as expected, since I'm unsure of whether the Form block should be enabled by default in dev mode specifically.

[jeherve]

possible that dev_debug constant alone doesn’t auto-activate modules. It normally happens during the connection process.

Yep, in Jetpack's Development mode all modules are deactivated by default; you have to go and enable them on your own if you want to test something with them. That's most likely what caused the confusion here.

Feel free to close if you think the behavior is working as expected, since I'm unsure of whether the Form block should be enabled by default in dev mode specifically.

We'll leave your issue opened, thank you. It fits into a larger discussion we've been having about block discoverability, and how we can make it easier for one to know what blocks are available, even when the feature itself has not been activated yet.

[jeherve]

Also in p8oabR-DS-p2#comment-5223