Migration for a Block Type - is there an API to create Block Types

[gebeer]

Hi @bernhard,

I created a new block type `Questions` through the GUI. All files and template `rockpagebuilderblock-questions` were created in that process.

When I deployed that to our staging server, the template for that block was not created.

So I had to add that template `rockpagebuilderblock-questions` to my RockMigrations to make the block work on staging. Is this normal behavior?

Is there an API method that I could use instead of the template migration? Couldn't find it in the docs.

Fields for that block are managed through the migrate method in site/RockPageBuilder/blocks/Questions.php. So the template migration is somewhat redundant. 

[bernhard]

  On 4/9/2025 at 12:35 PM, gebeer said:

So I had to add that template `rockpagebuilderblock-questions` to my RockMigrations to make the block work on staging. Is this normal behavior?

Expand  

Hey @gebeer this is not normal. On development you click on the plus to create a new block. The module will then create the files for your new block (eg /site/templates/RockPageBuilder/blocks/Whatever/Whatever.php and the existence of that file will make RockPageBuilder create all necessary templates for that block via RockMigrations on the next page load.

When deploying to production the existence of that file should be enough to create the template for your block.

[bernhard]

  On 4/9/2025 at 12:35 PM, gebeer said:

Fields for that block are managed through the migrate method in site/RockPageBuilder/blocks/Questions.php. So the template migration is somewhat redundant. 

Expand  

This makes me wonder... Maybe you have some kind of migration there that messes things up... Maybe something kicks in too early and then the regular process does not fire.

[bernhard]

Ok sorry for triple-posting, but I don't want that you miss that: What I'm usually doing is to pull the production state via "rockshell db:pull production" before I commit anything and push it to production. That way you should have the exact same state on local as you have after deploying to production. You have the DB state of production and the file state of development, just like you'd have if you push all new files to production.

So in theory that should make sure that all migrations etc. run exactly the same as after a deployment to remote!

[gebeer]

Thanks for all the info. I guess then that it was a hickup on the server. Nothing unusual in the migrations for that block.

      'templates' => [
        $this->getTplName() => [
          'fields' => [
            'title' => [
              'label' => 'Headline',
            ],
            'questions' => [], // page ref field
          ],
        ],

And this was the first time that this happened.

[bernhard]

  On 4/9/2025 at 12:35 PM, gebeer said:

When I deployed that to our staging server, the template for that block was not created.

So I had to add that template `rockpagebuilderblock-questions` to my RockMigrations to make the block work on staging. Is this normal behavior?

Expand  

Is your problem now solved? Did you try to run migrations again? Either with a modules refresh or via CLI? I think that should have solved it.

  On 4/9/2025 at 1:36 PM, gebeer said:

Thanks for all the info. I guess then that it was a hickup on the server. Nothing unusual in the migrations for that block.

Expand  

That does not really comfort me 🙈 But it's also extremely hard to say what could be the reason for what you've seen...

[gebeer]

  On 4/9/2025 at 1:40 PM, bernhard said:

Is your problem now solved? Did you try to run migrations again? Either with a modules refresh or via CLI? I think that should have solved it.

Expand  

I ran the migrations again through modules refresh on the server after deploying. But the template was not created. That was in the instance when I did the deployment for the first time. I haven't tried to reconstruct the situation by reverting to the previous DB stage and run migration again. Don't have the budget for that in that client project, unfortunately.

  On 4/9/2025 at 1:40 PM, bernhard said:

That does not really comfort me

Expand  

Sorry, if this is not comforting you. But sometimes we have to act under budget/time constrains. Though if this occurs again, I will further investigate.