Provide access to a Section or SectionComponent from within a $form_state

Here's a first attempt.

+++ b/core/modules/layout_builder/src/Form/ConfigureBlockFormBase.php
@@ -242,4 +242,30 @@ protected function getPluginForm(BlockPluginInterface $block) {
+    if (!$section_delta) {
+      $section_delta = $this->delta;
+    }
+    if (!$component_uuid) {
+      $component_uuid = $this->uuid;
+    }
+    return $this->sectionStorage->getSection($section_delta)->getComponent($component_uuid);

Ohhh I don't know about this change. In this case, I think there should be a getCurrentSection() and getCurrentComponent() that use the internal $this->delta/$this->uuid, and take no parameters. And any other use case can use the getSectionStorage() method if they want another value. The way it is now feels confusing

Here's a test.
Also fixed some nits with the docs.

1. +++ b/core/modules/layout_builder/src/Form/ConfigureBlockFormBase.php
   @@ -27,7 +28,7 @@
   +abstract class ConfigureBlockFormBase extends FormBase implements BaseFormIdInterface {
   
   @@ -136,6 +137,13 @@ public static function create(ContainerInterface $container) {
   +  public function getBaseFormId() {
   +    return 'layout_builder_configure_block';
   +  }
   

   I've included this to make it easier for alters, instead of having to check for layout_builder_add_block||layout_builder_update_block

2. +++ b/core/modules/layout_builder/src/Form/ConfigureBlockFormBase.php
   @@ -242,4 +250,34 @@ protected function getPluginForm(BlockPluginInterface $block) {
   +  public function getSectionStorage() {
   ...
   +  public function getCurrentSection() {
   ...
   +  public function getCurrentComponent() {
   
   +++ b/core/modules/layout_builder/tests/modules/layout_builder_test/layout_builder_test.module
   @@ -58,3 +59,24 @@ function layout_builder_test_node_view(array &$build, EntityInterface $entity, E
   +  /** @var \Drupal\layout_builder\Form\ConfigureBlockFormBase $form_object */
   +  $form_object = $form_state->getFormObject();
   

   Feels a bit odd putting these on a class and not an interface, but as is the case with all form classes they are always retrieved from $form_state->getFormObject() which will only ever guarantee a FormInterface, so any other methods will have to be assumed or checked for anyway.

This looks good, I was able to apply this to 8.7.x and tested that form alters have access to this from $form_state->getFormObject()->...

Is this going to be a common task? I'm wondering whether it would worth adding a layout_builder.api.php file with documentation for hook_form_layout_builder_configure_block_alter() - yes I know that we essentially re-documenting hook_form_BASE_FORM_ID_alter() but it seems maybe worth it. Not sure - hence leaving at rtbc.

Is that a thing we do for any other form alters? I've not seen it.
And no, I don't think this will necessarily be *that* common, but common enough for anyone extending LB, or the functionality of something like block plugins.

We've almost completely stopped referring to dynamic hooks separately, for example hook_node_load() docs use @mplements hook_ENTITY_TYPE_load(), so I don't think we should add something specific here.

Committed 9ca03e7 and pushed to 8.7.x. Thanks!

@catch, should this have been committed to 8.8.x as well?

It is weird that it doesn't show in the interface but this is commited to 8.8.x