Block Structure
Gutenberg Block in the context of our WordPress framework is, simply put, a set of files that “live” in the folder that has the name of the block (kebab-cased if it consists of multiple words).
MVC approach and Laravel inspiration
If you ever worked with any MVC-oriented web framework, such as Laravel, you will quickly connect the dots and get going.
Our folder consists of 10 files, some of them being optional depending on the configuration that we need. We have 6 files that are required and 4 optional ones.
- model.json (required)
- controller.php (required)
- EditMain.js (required)
- EditSidebar.js (optional)
- view.latte (optional)
- View.js (required)
- frontend.scss (optional)
- frontend.js (optional)
- _editor.scss (optional)
- example.jpg (required)
1. model.json
This file is the single most important that builds a block. It is a JSON schema file that serves the purpose of defining what fields (field types) we will be using in the particular block, plus a few more additional configuration options.
2. controller.php
Ties together the schema file (model.json) and the PHP-rendered view file (view.latte). In most cases, it can be left as is by default, but we can abstract and place the logic in this file as well.
3. EditMain.js
Builds the “front-end” on the admin side. It shows all the editable fields. By default, it can be left as is, as the fields are automatically generated based on the schema file (model.json), but we can also customize it (niche scenarios).
4. EditSidebar.js
Builds the “front-end” on the admin side, in the sidebar area. It shows all the editable sidebar fields. By default, it can be left as is, as the fields are automatically generated based on the schema file (model.json), but we can also customize it (niche scenarios).
5. view.latte
View layer of the block – PHP rendered (We can use either view.latte or View.js to render a block, but more about that later) In this file, we are creating the front-end part of the block (what is shown to the user), and we are using the latte templating engine to avoid writing concatenated strings and make the readability better and coding more streamlined and easy.
6. View.js
View layer of the block – JS rendered. Because of how Gutenberg is built, this file should always be present, be it default (returning null, where we handle rendering with PHP), or when we want to render the front-end via JS. We suggest modifying it only when it’s absolutely not possible to achieve something with the PHP-rendered version of the block (which is the preferred way of rendering blocks in our framework.).
7. frontend.scss
Responsible for the CSS of the block used on the front end. Will only be enqueued if at least one instance of the block is present on the front end.
8. frontend.js
Responsible for the JS of the block used on the front end. Will only be enqueued if at least one instance of the block is present on the front end.
9. _editor.scss
By default, our blocks have a standardized and uniform appearance inside the editor. But, should you need to adjust something for a custom block, and change the block’s appearance in the editor, you would do that in this file.
10. example.jpg
Screenshot of how the block is rendered on the front-end, to make it easier to search/navigate/add blocks in the admin area.