2

I'm using the Configuration Inspector module module, and I'm finding a missing schema error.

The configuration is for block.block.pminbox.settings.thread_count

The block itself is a plugin, created in my module. I've tried:

  • Adding the settings to the block annonation
  • Creating block.block.pminbox and adding settings as a mapping with thread_count as a property of that mapping
  • Creating block.block.pminbox.settings and adding thread_count in there
  • Adding the config to mymodule.schema.yml

Here is where I am at as of now. Submit handler for class extending BlockBase:

  public function blockSubmit($form, FormStateInterface $form_state) {
    $this->configuration['thread_count'] = (int) $form_state->getValue('thread_count');
  }

mymodule.schema.yml:

block.settings.pminbox:
  type: block_settings
  label: 'Private message inbox block settings'
  mapping:
    thread_count:
      type: integer
      label: 'Thread count'

The rest of the schema in this file is being picked up, however, I'm still getting a 'schema undefined' error from the configuration inspector for this block.

2
  • The point of having schema is that you don't have to worry about casting, the config system will take care of that for you. And if you get schema undefined then it's not about having the wrong type. Note that the key after block.setings.pminbox is the plugin ID, not the block config entity ID (as you can have N arbitrary named config entities). Are you sure your block plugin id is correct? Also, I assume the schema file is in config/schema. would be helpful if you could post a bit more of the relevant code
    – Berdir
    Commented Apr 17, 2018 at 20:12
  • I am definitely using the block plugin ID (pminbox). I've confirmed it in code, it's also the name of the exported file in my config directory, and what is listed on the configuration inspector page. I tried using the config entity ID after reading your post, just to confirm, and that throws an error. The config file is in config/schema, and the rest of the config in that file is properly being read. I'm happy to post some more code, but I'm not sure which would be relevant at this point.
    – Jaypan
    Commented Apr 17, 2018 at 20:25

2 Answers 2

1

It would really help to knowing how your data is saved (e.g. providing a snippet from your BlockBase::blockSubmit() implementation that shows this value), or what exactly you tried adding to your yml files.

However, in theory a working example that assumes, you are saving the value like this:

PmInboxBlock.php

/**
 * @Block(
 *   id = "pminbox",
 *   admin_label = @Translation("PmInbox"),
 *   category = @Translation("PmInbox"),
 * )
 */
class PmInboxBlock extends BlockBase {

  // ... Your Form definition here ...

  /**
   * {@inheritdoc}
   */
  public function blockSubmit($form, FormStateInterface $form_state) {
    $this->configuration['thread_count'] = $form_state->getValue('thread_count');
  }

}

Then you provide the schema definition in a schema file named after your module:

mymodule.schema.yml

block.settings.pminbox:
  type: block_settings
  label: 'PmInbox Block'
  mapping:
    thread_count:
      type: string
      label: 'Thread count'
6
  • Thanks, I appreciate the reply. I've updated the original post, however I'm still seeing the error.
    – Jaypan
    Commented Apr 17, 2018 at 18:43
  • @Jaypan: I suppose, you cleared the caches after adding the schema file? Commented Apr 17, 2018 at 22:13
  • I did :) [more characters]
    – Jaypan
    Commented Apr 18, 2018 at 1:22
  • I just triedre-installing the module, but still seeing the same issue.
    – Jaypan
    Commented Apr 18, 2018 at 1:51
  • That's really strange. We support a lot of modules with custom blocks using the above approach. And of course also check the schema, as we're heavily making use of configuration management. It ALWAYS worked. Please let me know, if you found your issue. Commented Apr 18, 2018 at 4:05
0

I was on the right path, thanks to Mario's answer. The problem was I was looking at the wrong ID for the block. When looking at the config file for the block (block.block.pminbox), there are two IDs. The first is the block ID (pm_inbox), and the second is in the settings array (settings.id), which is the plugin ID of the block. The value for settings.id (the plugin ID for the block) is the value to be used here (pm_inbox_block):

block.settings.pm_inbox_block:
  type: block_settings
  label: 'Settings for the private message inbox block'
  mapping:
    thread_count:
      type: integer
      label: 'The number of threads shown when block is loaded'

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.