Contact Form Block: Disallow removing Submit/Contact Us Button (or add a way to add it back if removed)

[zdenys]

It's possible to remove the Submit/Contact Us Button inside the Contact form Block. And once that is done, there is no way to add it back as it's not part of the Blocks the Form can have.

I noticed this after #15286 was implemented, so pinging @apeatling in case it's something that can be fixed.

Steps to reproduce the issue

1. Add Contact Form Block
2. Click on Submit/Contact Us button to select it and then three-dots and Remove
3. Try to click + and see no Button Block in the list of items that can be added

What I expected

• No way to remove the Submit/Contact Us button (maybe remove the entry Remove in the three-dots menu)
  
  Link: https://d.pr/i/opYVpC

OR

• Add specifically Submit/Contact Us button to the list of Blocks that can be added inside the Contact Form block.
  
  Link: https://d.pr/i/PBMchY

What happened instead

Submit/Contact Us Button Block can be removed as any other block but with no possibility to add it back (unless you edit the code directly by adding <!-- wp:jetpack/button {"element":"button","text":"Contact Us"} /--> within <!-- wp:jetpack/contact-form --> <!-- /wp:jetpack/contact-form -->)

#user-report https://wordpress.com/it/forums/topic/testo-pulsante-invia/

[tbradsha]

Had this happen in 3266094-zen. Added it back by copying/pasting via Code Editor from a new Form block.

[retrofox]

In case we'd like to avoid removing the Submit/Contact Us button, we could try the template lock mechanism.

[apeatling]

Unfortunately that's not on a per block basis so locking would mean not being able to edit any of the fields.

[ianstewart]

Unfortunately that's not on a per block basis

Is there a core Gutenberg issue for extending that to a per block level?

[ianstewart]

Or is it possible to register a variation of a button block for cases like this that prevents deletion?

[apeatling]

No unfortunately not, because it's not a specific button issue. It's more a limitation of innerBlocks. It needs an extension to the API in core for this to work.

[ianstewart]

I could see other blocks and plugins and perhaps even themes + patterns making use of that. For example, someone wanting to make a suite of patterns or custom blocks that act like patterns for authors on a large site, while protecting certain blocks from being deleted.

[apeatling]

From that perspective outside of the context of inner blocks then on a per block level might make sense. Assuming it's within a specific container.

[zdenys]

Another case encountered in 4056291-zd-woothemes

User accidentally removed the Submit button in the editor. It is still displayed on the front end, but it's not doing any action.

To fix it, I had to add a new Form Block, switch to the Code Editor, copy the code of the Submit button <!-- wp:jetpack/button {"element":"button","text":"Submit"} /--> and then paste it in the user's form code, before the closing tag.

Ideally, we should not allow the Submit button to be accidentally removed in the Editor since there is no easy and intuitive way for adding it back for the users, without contacting support or having advanced knowledge of the Code Editor and various Blocks' code.

[AtrumGeost]

Got another report here:

4305930-zd-woothemes

The workaround mentioned above worked.

[jeherve]

This was also reported in Automattic/wp-calypso#62816

[vykes-mac]

@Automattic/jetpack-crew Looking at this issue I'm recording two possible solutions I see for more feedback

1. The first is to make the jetpack/button used in the forms insertable and also set multiple:false in the support attributes. This will allow users to insert a new button only if they remove the first button since `multiple:false allow only 1 instance of the button to be present.

The issue I realise with this issue is that the newly added button doesn't submit the form instead it's created with target="#", perhaps someone can elaborate on this.

2. Is to prevent the user from deleting the button by keeping a copy of the list of blocks and reset the editor to those blocks if the user attempt to remove the button. sample code below :

const getBlockList = () => wp.data.select('core/block-editor').getBlocks();
let blockList = getBlockList();
wp.data.subscribe(() => {
	const newBlockList = getBlockList();
	const form = newBlockList.find(block => block.name = 'jetpack/contact-form');
	if (
	  form &&
	  form.innerBlocks.every( block => block.name !== 'jetpack/button' )
	) {
	  wp.data.dispatch( 'core/block-editor' ).resetBlocks( blockList );
	}
	blockList = newBlockList;
});

I'm not certain what kinda effect this might have on performance , also the remove button option is still there but does nothing from the users perspective, this might be confusing to the user.

[jeherve]

2 Is to prevent the user from deleting the button

This would seem like a better option, since you always need a submit button with a form. Not perfect though, as you point out.

I wonder if this may be something worth bringing up to the Gutenberg team. Maybe having the option to have mandatory inner blocks that cannot be removed from a template would be interesting for other block developers?