PHP exception when placing block

Added links from #2 as project's related issues. thanks @ransomweaver for the links.

Unfortunately though I get 3 warnings, each time I try to place a "Field as Block" block.

These are from the watchdog logs. (Please refer to attached text files for the messages.)

#1
Location http://localhost/admin/structure/block/add/fieldblock%3Anode/ucbad?_wrap...
Referrer http://localhost/admin/structure/block
Message warning_1.txt

#2
Location http://localhost/admin/structure/block/add/fieldblock%3Anode/ucbad?_wrap...
Referrer http://localhost/admin/structure/block
Message warning_2.txt

#3
Location http://localhost/admin/structure/block/add/fieldblock%3Anode/ucbad?_wrap...
Referrer http://localhost/admin/structure/block
Message warning_3.txt

The errors in #7 are unrelated.
The problem there is that you are using the translated label of the formatter as the plugin ID.

diff --git a/src/Plugin/Block/FieldBlock.php b/src/Plugin/Block/FieldBlock.php
index a225157..3951c61 100644
--- a/src/Plugin/Block/FieldBlock.php
+++ b/src/Plugin/Block/FieldBlock.php
@@ -190,7 +190,7 @@ public function blockForm($form, FormStateInterface $form_state) {
       }
       else {
         if (empty($formatter_id)) {
-          $formatter_id = reset($formatter_options);
+          $formatter_id = key($formatter_options);
         }
         $form['formatter']['id'] = [
           '#title' => $this->t('Formatter'),

That should fix the other bug.

#3 works fine in my case.

Patch in #3 solves the issue and as Tim mentioned in #9, the errors in #7 are unrelated to this bug. RTBC.

@Tim, I didn't understand from a quick read of #2798261: Using $form_state->getValue() in BlockBase's blockForm throws "subform and parent form must contain the #parents property" exception whether this should be fixed here or if that core issue will obviate this?

That issue hasn't come to a consensus yet on what exactly will happen.

I would propose instead of that patch, you do something like this at the top of blockForm():

if ($form_state instanceof SubformStateInterface) {
  $form_state = $form_state->getCompleteFormState();
}

That way if it's switched back to not being a subform, you won't get another exception.

#3 solved the issue for me

UPDATE:
Actually, when I applied #3 and the patch in https://www.drupal.org/node/2798261 it started working. Applying the patch from https://www.drupal.org/node/2537732 made everything in admin go all WSOD, however. Reversed that one, and all is well.

*******

I wish #3 were working for me, but I am still getting "RuntimeException: The subform and parent form must contain the #parents property, which must be an array..." in my log messages despite a successful patch application. Has anyone else still run into problems?
D8.2.3
AdaptiveTheme 8.x-1.0-rc2
Field as Block 8.x-2.0-alpha1

Thank you!

NW for #13

#3 solved the issue for me, too. Thanks!

#3 works for me.

This adds the suggested code from #13. The form is still pretty wonky on my project (using it on a custom field formatter, so who knows where the real issue is...), but I wanted to post this is the hopes of moving things forward.

I can confirm that #19 works for me.

I should also point out the form wonkiness I mentioned in #19 was due to my custom field formatter, not this module. Things look just fine using any of core's field formatters.

+++ b/src/Plugin/Block/FieldBlock.php
@@ -155,6 +155,12 @@ class FieldBlock extends BlockBase implements ContainerFactoryPluginInterface {
+    if ($form_state instanceof SubformStateInterface) {
+      $form_state = $form_state->getCompleteFormState();
+    }

@@ -178,9 +184,9 @@ class FieldBlock extends BlockBase implements ContainerFactoryPluginInterface {
-    $field_name = $form_state->getValue(['settings', 'field_name'], $this->configuration['field_name']);
+    $field_name = $form_state->getCompleteFormState()->getValue(['settings', 'field_name'], $this->configuration['field_name']);
...
+    $formatter_id = $form_state->getCompleteFormState()->getValue(['settings', 'formatter', 'id'], $this->configuration['formatter_id']);

You shouldn't need to call getCompleteFormState in both places. In fact, that should cause the opposite problem. Unless it's because you don't have use Drupal\Core\Form\SubformStateInterface; at the top of the class, and the check is always failing...

That's the opposite of what I meant, sorry. Just include the first if() statement

#19 worked for us as well.

ransomweaver's patch (#3) resolves the reported error on my Drupal 8.2.7 website (using Field Block 8.x-2.x-dev) and allows me to place my block(s). Thank you!

#3 rocks! Thanks!

Faced a similar issue. #3 works for me as well.

#23 worked in my case. Thanks!

I believe this is what @tim.plunkett wants to see.

Yess i think so.

Yes! Thank you.

patch from #30 worked for me.

#30 worked for me. Looks like ready for commit to dev

Patch on #30 works for me! Please, commit and create a new release!

I can confirm #30 is fixing the issue here.

thanks.

#30 worked for me when I encountered this issue on a site running 8.4.0. Thanks so much!

Just to clarify that patch on #30 also worked for me, running 8.4.3 ..

The important thing is that I stumbled upon this when following the video tutorial
'Create A Call To Action Block Using The Field As Block Module' by Ivan Zugec, also mentioned in the module's page.

video link for tutorial is here: https://www.youtube.com/watch?v=Q-F0ZFcfYps

I 'm saying this, because being a beginner, I can understand how other beginners will follow that tutorial and suddenly
when they click on 'place block' nothing will happen (not even an error message). One has to open in new tab to see
the error, then search error logs, then search the error itself, and that's what made me come here in the first place.

Then one has to figure out how to apply the patch (remember I 'm a beginner also, so I have never done that before)
but this is another story (and more googling around).

Sorry if some of it is irrelevant to put here, I just wanted to add some context, I 'm sure others will sooner or later be
looking for the same solution. Thanks for your time.

+1 to commit #30

#30 worked for me when I encountered this issue on a site running 8.3.7

Thank you and please add this to a new release for the module.

Committed, thanks to all.