Warning: Type of PR label mismatch

To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.

• Type-related labels to choose from: [Type] Automated Testing, [Type] Breaking Change, [Type] Bug, [Type] Build Tooling, [Type] Code Quality, [Type] Copy, [Type] Developer Documentation, [Type] Enhancement, [Type] Experimental, [Type] Feature, [Type] New API, [Type] Task, [Type] Technical Prototype, [Type] Performance, [Type] Project Management, [Type] Regression, [Type] Security, [Type] WP Core Ticket, Backport from WordPress Core, Gutenberg Plugin.
• Labels found: .

Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task.

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: buzztone <buzztone@git.wordpress.org>
Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>
Co-authored-by: t-hamano <wildworks@git.wordpress.org>
Co-authored-by: alexstandiford <alexstandiford@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @buzztone! In case you missed it, we'd love to have you join us in our Slack community.

If you want to learn more about WordPress development in general, check out the Core Handbook full of helpful information.

Maybe instead of autogenerating form IDs, we give users advanced control and let them specify this value.

My review of existing form plugins showed that all the plugins generate a unique form id for each form - see Form Plugin Analysis Results. This unique form id is used for several purposes which require targeting of individual forms on a post or page.

I'll look if any of existing form plugins also give users an advanced control to let them modify the autogenerated form ID. If there is a strong need for this functionality, it will likely have emerged in several of the existing form plugins.

@buzztone, other plugins might do it, but from an HTML spec perspective, it's not required to generate an ID for every form. I think it's better to let users decide if they want to assign an ID to a form or not.

How would we identify the form for the hook? It's possible to have multiple forms on a single page, right? It's also possible to (intend to) have the same form across multiple pieces of content. In those cases, leaning on the post ID isn't enough.

I think a unique ID for each form would be needed, and additionally:

Most form plugins ask user for a unique name (and slug), I suppose this could be added in the block (such as template-part name modal)

Originally posted by @Humanify-nl in #44186

@Humanify-nl are you able help here by adding why you feel it's important to add "a unique ID for each form".

I don't know yet... There would have to be some identifier for the forms, I didn't get that far in my proof of concept

No problem 😄. Just thinking through the challenges.

I can see the necessity of a form ID, but where would that be stored?

Originally posted by @alexstandiford in #44186

@alexstandiford are you able help here by explaining why you "see the necessity of a form ID".

Why unique form ids are helpful

Adding a unique ID attribute to the form tag is a very common and generally recommended practice in HTML. While a form can function without an ID, including one helps unlock several capabilities.

Form submission handling: When handling multiple forms on a page, unique IDs help distinguish which form triggered a submission event.

Form relationships: A form ID helps maintain proper relationships between form elements and ensures each form instance is uniquely identifiable in the DOM.

JavaScript DOM manipulation and targeting: Adding a unique form ID makes it easy to target in JavaScript, using methods like document.getElementById('yourFormId').

Accessibility: Screen readers and assistive technologies can use form IDs to associate form controls with their labels and to navigate between forms.

CSS Styling: A unique form ID allows users to apply unique styles to a particular form that shouldn’t affect any other forms.

Analytics and tracking: Unique form IDs make it easier to track form interactions and completions in analytics tools.

@buzztone Thanks for the PR!

To be honest, I'm reluctant to automatically add ID. Users who really need an ID are free to choose their own ID.

Additionally, note that if we update the save function, we'll need to add a block deprecation.

In my context in #44186 - I was making some assumptions about the approach, it seems (it was a while ago so I'm trying to remember). I was prescribing the solution, so it might not be that helpful, but here's the context:

The problem I was actually trying to solve was how does this form get extended? If I am a developer who wants to make this form do something, how do I do that? I believe my expectation was that a form would need to be somehow identifiable to do that, but now I'm not so sure.

I think a forms system that's extendable and handles what happens on-submit can probably be handled in the context of the block editor, and the form's information (submission strategy, what happens on-submit, etc) can likely be added directly as metadata in the block itself. If someone wants to re-use a form, it would likely be able to be put directly in a pattern.

If it were handled in that manner, there wouldn't be any need for an identifier from my perspective, specifically, since the form houses all of the logic it needs to actually run.

@alexstandiford Thank you for your detailed explanation!

The problem I was actually trying to solve was how does this form get extended? If I am a developer who wants to make this form do something, how do I do that? I believe my expectation was that a form would need to be somehow identifiable to do that, but now I'm not so sure.

I think this is an important point.

Unfortunately, the Form block is still experimental, and I don't think there is a clear direction yet on how to evolve it. I suggest waiting until it's clear whether we really need unique form IDs.

Unfortunately, the Form block is still experimental, and I don't think there is a clear direction yet on how to evolve it. I suggest waiting until it's clear whether we really need unique form IDs.

I'd suggest closing this PR and the issue until this is clear. What do you think?

I'd suggest closing this PR and the issue until this is clear. What do you think?

@t-hamano I don't understand what purpose closing this PR achieves. I am aware that you & @Mamaduka think that automatically added form IDs are not required & users who really need an ID are free to choose their own ID.

I have earlier provided well documented reasons Why unique form ids are helpful & are commonly used in forms on WordPress sites. I'd be very interested to hear if you think the reasons I've presented are inaccurate, unimportant or invalid.

Importantly, when starting work on this PR, I did examine how a large number of popular existing WordPress form plugins used form IDs. I found they all used automatically generated form IDs in a generally similar format to what I've presented in my PR.

Clearly your & @Mamaduka opinion on form IDs is very different from all of these WordPress form plugins. Do you consider that their common usage of automatically generated form IDs is misguided or unjustified?

I'd suggest, on the contrary, their consistent usage of automatically generated form IDs, demonstrates that there was & is a clear need for this functionality on the many millions of WordPress forms served by these plugins i.e. it's there in their plugins because they found it was needed by end users.

To discourage you & @Mamaduka from closing this PR, I'm now contacting & asking the authors of all the form plugins I originally examined to comment here on why they use automatically added form IDs on their WordPress form plugins.

I'm not disagreeing with you. There must be a reason why plugins assign unique IDs to forms.

My main concern is why we would force an ID to be generated when users are free to assign their own IDs to the core form block. As far as I know, there is currently no functionality in the form block that requires a unique ID.

Furthermore, once a feature is added to the core, we are responsible for maintaining backward compatibility in principle.
Therefore, compared to plugins, adding new features to the core requires careful discussion and decision-making.

My main concern is why we would force an ID to be generated when users are free to assign their own IDs to the core form block. As far as I know, there is currently no functionality in the form block that requires a unique ID.

Yeah, I'm inclined to agree with this. I think when I was originally suggesting IDs for blocks, sync'd patterns didn't exist. And technically a sync'd pattern does have an ID, so by proxy I think that solves the problem here. Not 100% sure on that, but it seems like it would be sufficient.

My main concern is why we would force an ID to be generated when users are free to assign their own IDs to the core form block.

I think there are clear reasons why it's better to automatically generate a form ID on each & every form, rather than force inexperienced WordPress users to manually add a unique ID when & if they understand it's required.

Nevertheless I'd still really like to hear from existing form plugins authors why they've chosen to automatically generate a form ID for every form, rather than provide a facility for their users to occasionally, manually assign an ID to a form.

As far as I know, there is currently no functionality in the form block that requires a unique ID.

This functionally was not added in the initial PR for the experimental Form Block, but form IDs were raised in comments on that PR. I included & linked to these comments in the Add unique form id to form block #70071 issue associated with this PR to give others participating here some background on why I chose work on this issue.

I saw this issue as a relatively easy & non-controversial issue to help learn how the experimental Form Block was currently implemented & start contributing to the ongoing development of the Form Block Experiment.

Furthermore, once a feature is added to the core, we are responsible for maintaining backward compatibility in principle.
Therefore, compared to plugins, adding new features to the core requires careful discussion and decision-making.

I understand both the responsibility & ongoing challenge for maintaining backward compatibility. In this case however, I think it's important to embrace the value of the experimental flag chosen by aristath for this work.

I personally think there is only a 50/50 chance of the Form Block experiment making it eventually into WordPress core. But it's nevertheless a valuable & useful experiment.

I also believe it's necessary that the experiment runs within the Gutenberg plugin. Working directly within the Block Editor, via the Gutenberg plugin, provides a unique opportunity that creating yet another WordPress form plugin could not provide.

In a broad sense, the project seeks to add creation & editing of basic WordPress forms to the Block Editor. What has previously been entirely WordPress plugin territory, gains an alternative option for all WordPress users i.e. to finally build this extremely common requirement on most WordPress websites, directly within the WordPress Core Block Editor.

But it clearly needs to experimental - trying things, sometimes getting it wrong & importantly receiving feedback from both developers & end users. We initially need the opportunity to do things wrong & then change our minds (based on user feedback) without creating any consequences for WordPress core.

At a later stage, if the experiment moves to actually being considered for core, we of course then need to move towards maintaining backward compatibility.