Timeline for Extending block configuration schema
Current License: CC BY-SA 3.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 25, 2018 at 2:19 | answer | added | Jaypan | timeline score: 0 | |
| Apr 17, 2018 at 20:25 | comment | added | Jaypan | 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. | |
| Apr 17, 2018 at 20:12 | comment | added | Berdir | 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 | |
| Apr 17, 2018 at 19:12 | history | edited | Jaypan | CC BY-SA 3.0 |
added 71 characters in body
|
| Apr 17, 2018 at 18:42 | history | edited | Jaypan | CC BY-SA 3.0 |
Updating post
|
| Apr 17, 2018 at 16:24 | answer | added | Mario Steinitz | timeline score: 1 | |
| Apr 17, 2018 at 15:16 | history | edited | Jaypan | CC BY-SA 3.0 |
Spelling mistake
|
| Apr 17, 2018 at 10:00 | history | asked | Jaypan | CC BY-SA 3.0 |